Mondorescue manually restoring from an afio.bz2 file
For several years now, I’ve used Mondorescue as a backup solution for those customers with a Linux server. It makes for a nice, easily scriptable backup that can go ahead and burn to disc, *(or tape or another pc….) My preferred way of doing this has been a full mondorescue backup to dvd (usually one or two discs) and a couple “incremental” backups each week. The client site handles swapping the discs as needed *(I’ve got reminder emails scripted) and they rotate through two sets of discs. Since mostly, these backups are kept onsite, once a month I burn a copy to move offsite.
It’s rarely been used, but mondorescue in this circumstance can be a great help. “Oops, I deleted ______ file that I was working on.” Or, “I made a mistake and deleted a bunch of entries from the …..mdb by mistake….” So, for those instances, it’s just been a matter of firing up mondorescue from the commandline, navigating to the file in question on the most recent backup that had the file in a good state and restoring. Very simple.
One of the reasons, I’ve chosen optical discs though is because my concern over tape drives was always…. “what if I have a problem with the tape drive and can’t easily find a replacement… it’s the only tape drive in the building, how do I restore then?” That along with the whole linear vs. random access issue, AND having seen more backup tapes than I care to remember just plain stop working has led me down the path of optical disc backups. I hadn’t really considered the “What if I can’t restore using mondorescue” question until now.
I had just that opportunity lately. A file had gone missing from a shared folder (several users have access) before Christmas, meaning the off-site backup was the only disc to still have the file (actually an entire folder) in question. There were problems though, getting mondorescue to read the disc. (In fact, this machine constantly complained of access errors to this and other optical discs. It seems to write ok, but cannot read consistently.) I was able to identify where mondo had archived the file in question. Here’s how I tracked it down….
A mondorescue backup disc has a number of folders, the one I’m most interested in is “archives”. This is where all the system files get archived. Now, you’ll see a number of files…. xattr_list.0.gz filelist.0 0.afio.bz2 acl_list.0.gz ……….. the numbers go as high as however many “slices” of data from your backup there are. Each #.afio.bz2 contains several files (unless they’re very large, in which case one may be split if I understand correctly.) … here’s what I did…
grep /path/to/missing/folder filelist*
This basically searches all of the filelist folders for the folder that was missing, you could search other ways as well… but this told me that what I was looking for was in filelist.529 – I assumed that probably corresponded to 529.afio.bz2, acl_list.529.gz and xattr_list.529.gz *(this last two may not be used in every setup…. in this particular case, they were empty…) I was able to browse files and grep the filelist* files from the machine in question, but had to move the disc to another machine to retrieve/copy any bz2 files off….. So, not knowing any better, I copied the 529.afio.bz2 to disc and tried bunzip2 529.afio.bz2…. only to find…. bunzip2: 529.afio.bz2 is not a bzip2 file.
/Me smacks forehead…/
Of course, I need to use afio (after all this is one of the tools mondoarchive uses to compress things…. so I type afio at the command line to see what options we get….
afio -i is to “install” an archive… that looks like what we need, but… this is a backup, what if there are newer files in it? How can we precisely get what we need out? the -i switch accepts -n after it to protect newer files AND -y [PATTERN] to only extract files matching a specific pattern…
So…..
afio -i -n -y path/to/our/missing/folder/or/file 529.afio.bz2
might be enough (you can possibly use afio -t to list the table of contents and test out your pattern matching with afio -t 529.afio.bz2 | grep [pattern] )
I ran it and it seemed to do nothing. I looked for the folder, it wasn’t there. Then I consulted the man page again…. files will be installed relative to the current working directory … ah… so, once more and this time from /
afio -i -n -y path/to/our/missing/folder/or/file /path/to/529.afio.bz2
and voila, our files have been manually extracted from a mondorescue apio archive file.
I know, this isn’t news for many people, but I’m pleased that I was able to manually “surgically” retrieve content from a backup made with mondorescue. I’d always had in the back of my mind the “what if” of trying to restore from a partially bad disc that the gui would choke on and fail, or trying to restore from a partial backup set, that also might be problematic (since the mondorescue gui seems to want to read all discs from a backup set before letting you mark for restoring…)
The only thing left is to start looking into the machine’s disc read problems.
But… it looks like the files have a .z ending bzip2 ??? Followup coming soon….
Ok – so, it’s possible to do compression to afio with the -Z switch. The default is gzip, but testing seems to show that these are bzip2 archives (makes sense, that’s one of mondorescue’s requirements…) So, you can substitute bzip2 for gzip using the -P switch… here’s what got us there…
afio -i -n -y path/to/your/missing/file/or/folder/* -Z -P bzip2 /path/to/529.afio.bz2