Obviously we cannot use bpimagelist for the expired copies, so is there a copy of the images somewhere else - e.g. another copy on tape? Or another copy that was replicated to another backup environment?
It can be a time consuming but you can go through all bpdbm log files on the master server and all expired images would have been logged there. The default logging history limit is 28 days so you should be able to get 28 days of data provided the log is setup.
Other can be a very complicated method if at all you have OCA. Let us know if you have Opscenter Analytics and I shall try to help.
First thing to do is... please can you confirm how long your stats/errors/logs are kept for:
bpgetconfig -L | grep -i "keep"
...can you post the output of this command?
The second thing to do is to save a list of backup job logging, before the list rolls/expires:
bperror -t backup -d 01/01/1970 00:00:00 -e 31/12/2016 23:59:59 -s INFO+ >backup-stats-err.txt
...as this file will contain a list of all record of backups, the job ids, the image names, and the sizes.
The third thing to do is to save a list of existing backup image IDs:
bpimagelist -idonly -d 01/01/1970 00:00:00 >backup-stats-ima.txt
...as we can use this to check whether a backup image still exists or not.
Fourthly, do you have a Windows workstation or Windows server to hand? As I may be able to give you a reporting type script which can process the output of the two commands above, and generate a report of backup job numbers, the backup size, and whether the backup image still exists or not.
Even if you do not have a Windows workstation or server, you may be able to find someone helpful to convert the scripts that I could post, into ksh/bash.
My question to you - What is the reason for your query?
You will understand that NBU removes ALL references to expired images from the image db?
And that image expiration will initiate nbdelete on the media server to physically delete the image off disk?
So - if image has already expired, there is no way we can tell...
If backup disk is MSDP or another dedupe appliance, the cleanup process is a bit more complex, but all references in NBU is still removed.
Best if you tell us the reason for your query.
You can check manually, using the two files above, along the lines of:
...find backup image names, and the job that they belong to:
# grep -i "using the media server" backup-stats-err.txt 1436989095 1 33412 4 master01 114 113 0 client01 bptm Using the media server to write NetBackup data for backup client01_1436988145 to master01 1436989339 1 33412 4 master01 115 113 0 client01 bptm Using the media server to write NetBackup data for backup client01_1436989112 to master01
...in the output above we see two child jobs (114 and 115), both child jobs of parent job 113, and to the right shows the name of the backup image...
...now, using the job ID of the first image ID above (i.e. Job ID: 114), search the same file for how much was scanned by MSDP (you may need to change the search string for different storage unit types) for the child job:
# egrep -i "114.*scanned:" backup-stats-err.txt 1436989095 1 33412 4 master01 114 113 0 client01 bptm StorageServer=PureDisk:master01; Report=PDDO Stats for (master01): scanned: 9322641 KB, CR sent: 134399 KB, CR sent over FC: 0 KB, dedup: 98.6%, cache disabled 1436989109 1 33412 4 master01 114 113 0 client01 bptm StorageServer=PureDisk:master01; Report=PDDO Stats for (master01): scanned: 2969 KB, CR sent: 434 KB, CR sent over FC: 0 KB, dedup: 85.4%, cache disabled
...which shows there the backup image actually generated two 'sets' of data which were processed by MSDP, totalling 9325610 KB...
...now, check to see whether the backup image existed at the time the listing was taken:
# grep -i "client01_1436988145" backup-stats-ima.txt Time: 15/07/2015 20:22:25 ID: client01_1436988145 FULL (0)
...which shows that the listing does contain an image of that name, and therefore does exist at the time the listing was taken....
...and to see if the image still exists, right now, do:
# bpimagelist -idonly -backupid client01_1436988145