In the last two articles, we have laid the groundwork for getting our backups in place. By now you should have your site selected, your server built and your router and firewall(s) configured. Now let’s talk about the last big preparatory item before we get to the backup itself.
So what is this last step I refer to …. snapshot! If you don’t take the time to snapshot your data source and dump a copy of the data onto your new box, you may find yourself with a backup that runs for days or even weeks. To save yourself a huge headache snapshot your data source and dump a copy of that data onto the backup server using some kind of USB device. If you have a small amount of data then a thumb drive will do the trick. If you have a large amount of data then use a hard-drive instead.
Damn the Torpedoes: One note of caution here about disk formats. If your source server is a Mac, as mine is, you are going to have filesystem issues with your external USB device on one of your machines. The solution is to ensure that your external device is formatted as FAT32. There is a very good chance that it is, but make sure. Once you have validated this, trudge on through to the next step.
Making the Snapshot: Plug your device into your source machine. Assuming you are running a modern version of Linux, BSD or OS/X the kernal will see the plug-in event and may even automatically mount the device. If the device does not automatically mount then mount it manually. Once complete let’s use rsync to make our snapshot:
rsync -av /source/volume/ /target/volume/
GNU and All That Jazz: Just another note of caution. OS/X does not use the same version of command line tools that ship with most GNU/Linux distros. If you are using a non-GNU Unix-like OS (e.g FreeBSD or OS/X) as your source then be aware that the arguments passed to rsync can differ.
Restoring the Snapshot: Now let’s plug the USB device into our new Linux box. If you’re using Ubuntu Server, it will see the plug-in event but will not automatically mount the device. Use dmesg to view the kernel buffer and determine the device name, create a mount point, mount the device and then copy our data.
cd ~ mkdir usbdrive sudo mount /dev/xxx /user/xxxxx/usbdrive/ -t vfat -o iocharset=utf8,umask=000,shortname=winnt sudo rsync -av –partial ~/usbdrive/ ~/backup/
Take note of the mount command I’ve used. Even though FAT filesystems are typically case insensitive, I’m telling my system to pay attention to case. If we don’t mount the filesystem this way we will, unnecessarily, copy unchanged mixed-case files from our source to our target when we first run our backup script.
Trust Me: Unless you plan to run your backups by hand, which is not a good idea, then you will need to “convince” your backup server to automatically trust your source server. We do this by generating a key on our source and then telling the target to trust that key. Here’s how we do it:
ssh-keygen -t rsa
This will prompt for a passphrase. Just press the enter key. It will then generate an identification (private key) and a public key. Do not ever share the private key with anyone! ssh-keygen shows where it saved the public key. This is by default ~/.ssh/id_rsa.pub. Now copy the contents of id_rsa.pub to ~/.ssh/authorized_keys on the target.
In my next, and final entry on this series, we will create the backup script and learn how to automate its execution so we are always up-to-date and safe from data loss.
Happy computing!
~GT~