Showing results for 
Search instead for 
Did you mean: 

Identify NB images that only have one copy

Level 2

We are migrating to two new Data Domain appliances.  As a result, I have been duplicating my long-term retention images from disk/VTL to the Data Domains.  I keep the two Data Domains in sync so anything written to one gets duplicated (via Netbackup) to the other one.  I want to make sure I didn't miss duplicating any of the images so is there an easy way to identify images that currently only have one copy?

Thanks, Frank


Level 6
Partner Accredited Certified

I can't think of anything off hand that is "easy" but here is a fairly quickl way of doing it ...

Search in the catalig section for everything in the date range you are looking at - highlight it all and drop it into the first page of an excel spread sheet (it normally drops straight in but if not paste into notepad and then export it in.

Now do the same but having selected Copy 2 at the top right and drop those into the next tab

You now have a full list of everything original and everything you have duplicated.

Next copy the first column (backup id) from the first tab into a new tab and then the first column from the second tab into the second column on that third tab so that you have the backup ID's side by side

If they all match (the last entry is the same for both columns match) then you are good - if not look to see where they go out of sync to see which one you have missed

Not great but it really doesn't take very long

Hope this helps


You can exploit the "maximum copy" and the "duplicate" drop down option in the catalog screen to achieve what you want.

The trick goes like this:
1. In the master server host properties, set the global maximum copy to 2. No service restart needed.
You could change it back to whatever value you had when this is done, if it isn't already 2.

2. Go to the catalog screen, change "validate" to "duplicate".

3. Set the criteria/range for the images you are looking for, BUT, select "copy 1" so you are only going to search for the copy 1 of the images.

4. Search and Voila! You will find that all the images that already has a copy 2 would not appear on the list.

To verify step 4. is correct, you can always change the drop down from "duplicate" back to "validate", leave everything and the "copy 1" setting alone. You will find that the images that already has a copy 2 will appear again on this list of copy 1 images.
They appear again because you are now validating the existence of the copy 1s, instead of trying to duplicate from them.
If you try to duplicate from images that already has a copy 2 (by selecting the "duplicate" drop down), the "maximum copy" setting will prevent you from doing so by hiding the images that already has a copy 2 on this list of copy 1 images.

The reason why you have to set maximum copy to 2 is because, if you set it to anything higher, for the images that already have copy 1 and copy 2, Netbackup will allow you to duplicate from the copy 1 to create a copy 3, which it will do so by not hiding the images that already has a copy 2 in step 4., making this trick ineffective.

Hope it makes sense. This is the easiest built-in way of achieving what you want. Give it a try.

Level 6
Employee Accredited

Hope you're on Solaris/ Unix ...

Run these 3 lines, job done ...  I think ...

(This only works if the images are on disk, but I think yours are ...)

basename $(bpimagelist -l -hoursago 48 |grep "FRAG 2" |awk '{print $9}') |awk -F_ '{print $1"_"$2}' |sort >/tmp/copy2_backupid

bpimagelist -hoursago 48 -l |grep IMAGE |awk '{print $6}' |sort  >/tmp/all_backupid


sdiff /tmp/copy2_backupid /tmp/all_backupid |grep \> |awk '{print $2}'
NOTE:  In first line. change '-change hoursago 48' to whatever value you want to 'look back' for.



Level 2

Thank you everyone for the suggestions.  Martin, I am running on AIX.  I'll take a look at these and see which one might work best in my situation.  Again, I appreciate the quick response from all of you.  This is the first time I've posted a question here and it definitely won't be the last!