VerifyAndRestoreBackups

Verifying and Restoring Backups

Backups are no use unless you can restore them. The bbackupquery utility does this and more.

You don't provide any login information to it, as it just picks up the data it needs from /etc/box/bbackupd.conf. You should run it as root so it can find everything it needs.

Full documentation can be found in bin/bbackupquery/documentation.txt in the distribution archive. It follows the model of a command line sftp client quite closely.

On systems where GNU readline is available (by default) it uses that for command line history and editing. Otherwise it falls back to very basic UNIX text entry.

Verifying Backups

Since this is a development system, you'll be keen to verify that your backups are correct. This is easy.

/usr/local/bin/bbackupquery "compare -a" quit

It will report all the differences between the store and the files on disc. It will download everything, so may take a while. You should expect to see some differences on a typical compare, because files which have recently changed are unlikely to have been uploaded yet. Consider checking the timestamps on the files, or keeping a record of these messages and comparing them with a future verification.

If you would like to do a "quick" check which just downloads file checksums and compares against that, then do:

/usr/local/bin/bbackupquery "compare -aq" quit

However, this does not check that the file attributes are correct, and since the checksums are generated on the client they may not reflect the data on the server if there is a problem - the server cannot check the encrypted contents. View this as a good indication, rather than a definite check that your backup verifies correctly.

You may wish to run either one as a cron job while testing this system.

Restoring from Backups

You will need the keys file created when you configured the server. Without it, you cannot restore the files; this is the downside of encrypted backups. However, by keeping the small keys file safe, you indirectly keep your entire backup safe.

The first step is to recreate the configuration of the backup client. It's probably best to have stored the /etc/box directory with your keys. But if you're recreating it, all you really need is to have got the login infomation correct (ie the certs and keys).

Don't run bbackupd yet! It will mark all your files as deleted if you do, which is not hugely bad in terms of losing data, just a major inconvenience. (This assumes that you are working from a blank slate. If you want to restore some files to a different location, it's fine to restore while bbackupd is running, just do it outside a backed up directory to make sure it doesn't start uploading the restored files.)

Type:

/usr/local/bin/bbackupquery

to run it in interactive mode.

Type:

list 

to see a list of the locations stored on the server.

For each location you want to restore, type restore name-on-server local-dir-name. The directory specified by local-dir-name must not exist yet.

One example of a way, on Ubuntu (Debian) anyway, to restore a directory is to (from any directory) type:

sudo /usr/local/bin/bbackupquery "restore BBackupdConfLocationName/mktg /home/<username>/doc/corp/mktg" quit

Note the absence of trailing slashes.

If the restore is interrupted for any reason, repeat the above steps, but add the -r flag to the restore command to tell it to resume.

List Flags

These are the flags output by the list command:

• f = file
• d = directory
• X = deleted
• o = old version
• R = remove from server as soon as marked deleted or old
• a = has attributes stored in directory record which override attributes in backup file

Other Tricks

bbackupquery can also...

• List files on the server
• Restore arbitary parts of the file system
• Recover deleted files (either if the backup daemon hasn't deleted them from the store, or if they are marked on the store as deleted but not actually gone yet.)
• Recover old versions of files which are still on the server.

Read bin/bbackupquery/documentation.txt for more details.