Sean Wallbridge
We recently had an issue at a customer where a whole pile of BackupExec disk-based archive media seemed to be “bad”. By bad I mean cataloguing the media would fail part way through the process. We needed to find a way to try and recover files so we started playing around and we found a way.
Let me set the scenario …
We usually set BackupExec up to send it’s output to a QNAP NAS device, we do this so that BackupExec does not have to deal with changing media; you just give it a bunch of online disk space and let it do its thing. In order to get regular backups offsite we have the QNAP backup to local USB disks and those go offsite. This means that we get a “point in time” snapshot of what is “online” inside BackupExec at the time the backup is taken from the QNAP. So, the data that goes on to the USB disk includes ALL BackupExec data including the two .cfg files that BackupExec creates on its disk-based media.
We first tried to mount up the USB drive in BackupExec by simply “adding” the drive into BackupExec as disk-based storage after first renaming the two.cfg files (we didn’t want them corrupted in any way). This had the effect of BackupExec adding a couple of top level folders to the drive as well as BackupExec recreated the two .cfg files. We then told BackupExec to catalogue the disk and it hummed away and failed with a “data discrepancy error”. We tried the same process with a couple of other of the USB drives and we hit the same problem. Some more digging revealed to us that BackupExec appeared to be combing through the files in the order of the backup jobs that were covered by the files (we had 8 discrete jobs created) and the error appeared to be happening in files associated with job number 3; we needed files from job number 8. What to do????
Louis (my colleague) had the brilliant idea to look at the BackupExec reports for the job and day in question to find out what media was actually used. Keep in mind that BackupExec creates a number of .bkf files and each file is named (numbered) and the report lists the bkf files used. We surmised that we might be able to copy those files to another media device then go through the whole loop again with that device and just those files and maybe, just maybe, we could recover the data files required.
To make a long story short it all worked. We took the new media and mounted it in BackupExec as a disk-based storage device and then catalogued the disk. The backup data magically “appeared” in BackupExec and we were able to run a restore from it!
We now know that there is some sort of corruption within the QNAP within some of the BackupExec data and that got copied out to the USB drive and, of course, we will have to deal with that (and it is worrisome that BackupExec didn’t alert us to the corruption). But we also now know that we can “pick out” specific media files from our archive devices and successfully restore from those files using the process detailed above. It ain’t “pretty” and if you don’t know what media is used for a particular backup then this process won’t help. But, if the stars align for you, then you’re golden!