10-07-2014 02:25 PM
I have a NetBackup 5220 appliance, which was upgraded to version 2.6 several months ago.
I was trying to run a manual garbage collection today, following the usual instructions.
Problem is, when I get to step 5, and try to run crcollect, is says the executable is missing.
This worked for me before. Did someone move the executable?
s-17812:/usr/openv/pdde/pdcr/bin # ls -la
total 156
drwxr-xr-x 3 root bin 4096 Aug 13 14:01 .
drwxr-xr-x 5 root bin 4096 Aug 13 14:01 ..
drwxr-xr-x 2 root bin 4096 Aug 13 14:01 .bin
-rwxr-xr-x 1 root bin 241 May 30 11:37 adler32
-rwxr-xr-x 1 root bin 241 May 30 11:37 ca_test
-rwxr-xr-x 1 root bin 247 May 30 11:37 cacontrol
-r-xr-xr-x 1 root bin 2606 May 30 11:37 cdrinit.sh
-rwxr-xr-x 1 root bin 247 May 30 11:37 crcontrol
-rwxr-xr-x 1 root bin 250 May 30 11:37 crdoreader
-rwxr-xr-x 1 root bin 232 May 30 11:37 crfp
-rwxr-xr-x 1 root bin 235 May 30 11:37 crget
-rwxr-xr-x 1 root bin 238 May 30 11:37 crstat
-rwxr-xr-x 1 root bin 241 May 30 11:37 crstats
-rwxr-xr-x 1 root bin 244 May 30 11:37 dcpcrypt
-rwxr-xr-x 1 root bin 238 May 30 11:37 dcscan
-rwxr-xr-x 1 root bin 259 May 30 11:37 dedupecatutil
-r-xr-xr-x 1 root bin 4853 May 30 11:37 dr_createlist.sh
-rwxr-xr-x 1 root bin 241 May 30 11:37 filedel
-rwxr-xr-x 1 root bin 241 May 30 11:37 fileget
-rwxr-xr-x 1 root bin 241 May 30 11:37 fileput
-rwxr-xr-x 1 root bin 235 May 30 11:37 genpo
-rwxr-xr-x 1 root bin 229 May 30 11:37 md5
-rwxr-xr-x 1 root bin 241 May 30 11:37 nstpack
-rwxr-xr-x 1 root bin 238 May 30 11:37 pdconf
-rwxr-xr-x 1 root bin 238 May 30 11:37 pddeDR
-rwxr-xr-x 1 root bin 241 May 30 11:37 pddecfg
-rwxr-xr-x 1 root bin 250 May 30 11:37 pdstresscr
-rwxr-xr-x 1 root bin 238 May 30 11:37 prdate
-rwxr-xr-x 1 root bin 247 May 30 11:37 refdbutil
-rwxr-xr-x 1 root bin 481 May 30 11:37 spad
-rwxr-xr-x 1 root bin 235 May 30 11:37 spadb
-rwxr-xr-x 1 root bin 241 May 30 11:37 spauser
-rwxr-xr-x 1 root bin 247 May 30 11:37 splogscan
-rwxr-xr-x 1 root bin 489 May 30 11:37 spoold
-rwxr-xr-x 1 root bin 232 May 30 11:37 stat
-rwxr-xr-x 1 root bin 238 May 30 11:37 stconv
-rwxr-xr-x 1 root bin 235 May 30 11:37 wsget
-rwxr-xr-x 1 root bin 235 May 30 11:37 wslog
Solved! Go to Solution.
10-08-2014 10:12 AM
In regards to the technote, hen you click on "show all" under Prodcut(s) you'll see that the technote is only for the following:
"
Some commands have been deprecated in 2.6 and are no longer needed. This is due to a large MSDP design change.
10-08-2014 10:54 AM
Based on an unrelated bpstsinfo issue (which would be used if you were trying to remove images quickly that were orhpaned) http://www.symantec.com/docs/TECH216533 , the data integrity process does work to remove data that is no longer required.
To paraphrase:
"...the normal internal MSDP Data Integrity process... ...(which happens in the background)... ...determines that the data associated with these PO's is no longer required and to remove it"
Of course, per that document, relies on the fact that the PO has been removed either automatically or via manual (read support) process.
If it did not get removed, this is when we would run into orphaned images.
The process for checking for orphan images is an internal tool and requires a support call. (Which would then result in the bpstsinfo and require manual PO removal on images determined to be orphaned.)
10-08-2014 10:12 AM
In regards to the technote, hen you click on "show all" under Prodcut(s) you'll see that the technote is only for the following:
"
Some commands have been deprecated in 2.6 and are no longer needed. This is due to a large MSDP design change.
10-08-2014 10:40 AM
Fair enough, but then, is there some replacement methodology or process for cleaning stuff up that I missed?
Or am I just to assume that the jobs I expired have automatically been cleaned up?
Thanks
-Paul
10-08-2014 10:54 AM
Based on an unrelated bpstsinfo issue (which would be used if you were trying to remove images quickly that were orhpaned) http://www.symantec.com/docs/TECH216533 , the data integrity process does work to remove data that is no longer required.
To paraphrase:
"...the normal internal MSDP Data Integrity process... ...(which happens in the background)... ...determines that the data associated with these PO's is no longer required and to remove it"
Of course, per that document, relies on the fact that the PO has been removed either automatically or via manual (read support) process.
If it did not get removed, this is when we would run into orphaned images.
The process for checking for orphan images is an internal tool and requires a support call. (Which would then result in the bpstsinfo and require manual PO removal on images determined to be orphaned.)
10-08-2014 11:49 AM
Okay, I suppose that all makes sense.
Thanks