We recently had an issue at a customer where a whole pile of BackupExec disk-based archive media seemed to be \u201cbad\u201d.\u00a0 By bad I mean cataloguing the media would fail part way through the process.\u00a0 We needed to find a way to try and recover files so we started playing around and we found a way.<\/p>\n
Let me set the scenario \u2026<\/p>\n
We usually set BackupExec up to send it\u2019s 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.\u00a0 In order to get regular backups offsite we have the QNAP backup to local USB disks and those go offsite.\u00a0 This means that we get a \u201cpoint in time\u201d snapshot of what is \u201conline\u201d inside BackupExec at the time the backup is taken from the QNAP.\u00a0 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.<\/p>\n
We first tried to mount up the USB drive in BackupExec by simply \u201cadding\u201d the drive into BackupExec as disk-based storage\u00a0 after first renaming the two.cfg files (we didn\u2019t want them corrupted in any way).\u00a0 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.\u00a0 We then told BackupExec to catalogue the disk and it hummed away and failed with a \u201cdata discrepancy error\u201d.\u00a0 We tried the same process with a couple of other of the USB drives and we hit the same problem.\u00a0 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.\u00a0 What to do????<\/p>\n
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.\u00a0 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.\u00a0 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.<\/p>\n
To make a long story short it all worked.\u00a0 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 \u201cappeared\u201d in BackupExec and we were able to run a restore from it!<\/p>\n
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\u2019t alert us to the corruption).\u00a0 But we also now know that we can \u201cpick out\u201d specific media files from our archive devices and successfully restore from those files using the process detailed above.\u00a0 It ain\u2019t \u201cpretty\u201d and if you don\u2019t know what media is used for a particular backup then this process won\u2019t help.\u00a0 But, if the stars align for you, then you\u2019re golden!<\/p>\n","protected":false},"excerpt":{"rendered":"