Sean Wallbridge
We’ve had a reminder this week of some oddities in BackupExec.
Our standard backup configuration for customers that use BackupExec is to have BackupExec send its output to a NAS device (generally a QNAP) and then the datastore on the QNAP is dumped out to a USB disk for offsite storage on a regular basis. The dump (or backup) to the USB disk is performed by the NAS device and has nothing whatsoever to do with BackpExec itself. There is nothing particularly weird about this kind of setup, BackupExec sees a very large set of media (the NAS) and it makes life very easy when you need to pull back files from recent backups as there is no need to go rummaging for the proper media as there can be weeks, sometimes even months of backups stored on the NAS.
The oddity that I mentioned earlier comes into play when you decide that you have to recover files (or even a system) from data stored on the USB drives (the copied BackupExec data). As the USB disk was not directly generated by BackupExec you cannot directly mount it up in the production BackupExec system to recover files. For whatever reason, probably an issue tied to the internal BackupExec database, BackupExec will not properly catalogue or mount the USB drive. To be very clear, there is no issue with the data stored inside the BKF files on the USB disk, the issue is with how BackupExec recognizes and organizes the data.
The solution to this problem is to create a “clean install” of BackupExec on another system (this is where Hyper-V or VMware can be your friend!) and then import and catalogue the USB disk on that system. In this case you are treating the USB disk as “foreign media” in the new BackupExec install. As this install has zero history it will happily catalogue and import the media and will then let you recover files without issue. And as BackupExec treats all media in pretty much the same fashion, this trick should work with almost any type of copied media – disk, tape, whatever.
Totally silly, I grant you, but it does work. I’m sure my colleague Stephanie Kahlam will be blogging about this at some point but this is the gist of the problem.