Home / server / Questions / 479336
Accepted
Malfist
Asked: 2013-02-16 12:58:49 +0800 CST

Backup and Recovery Strategy for a VPS

  • 772

I have several small virtual private servers running ubuntu 11.04. I currently have VirtualMin managing the backups for the server, however, it only backs up the users' home folders and the configuration of various things to do with now Apache or FTP or whatnot is setup to support the individual virtual host.

I would like to do something that is more robust. I would like to be able to, in the event of an emergency, be able to take the most recent backup, move it to a new VPS and unzip/untar it and have the new VPS be essentially clone of the old.

Currently all the backups are stored on Amazon S3, and I'd like to keep it that way. I'd also like to avoid reliance on a specific tool to do the restore (i.e., storage in custom/proprietary binaries).

Essentially, how can I back my server up so that I can unpack a backup into a new server and have them behave the same way. I understand there are special considerations with databases, I've already got a backup strategy for MySQL.

backup

1 Answers

  1. Best Answer

    Backing up with TAR

    The beautiful thing about linux is that everything is a file. Since everything is a file, all you have to do to backup and restore your system is copy all the files back (with a few exceptions mentioned below). Assuming the VPS provisioning sets up the base operating system, you can simply tar and gzip up the entire filesystem and save the tar.gz file somewhere. Restoring is just a matter of untaring it over the existing files, preferably in single user mode.

    A slightly easier way

    I've done the tar way before and it works, but I prefer to setup rdiff-backup and backupninja - which makes it really easy to do incremental backups. This method has a few advantages:

    • You don't have to write your own backup scripts, just configure through a few conf files and a text based menu. You can write your own scripts to do additional features without starting from scratch
    • It makes sure SQL backups are taken just before the filesystem backup, to export to a .sql file which won't get as easily corrupted
    • Incremental backups let you keep more history without taking up much more space. You can restore the entire system or a single file to any day within the last month, for example. Which is important if people don't realize a file has been deleted or damaged right away!
    • Since it uses rsync to transfer the files, it will take MUCH less bandwidth than doing nightly tar files.
    • It's still just a bunch of files - no proprietary file formats or anything. You can restore your files by just copying them if you want (though restoring through rdiff-backup makes it easier)

    What to exclude

    In either case, there are a few directories you might not need to backup or want to restore:

    • /lost+found - this is where files go when your filesystem is damaged and fsck tries to fix things. If things end up here, you probably would rather restore from yesterday's backup anyways.
    • /mnt and /media - depends on what's mounted there, if you mount remote files systems there you probably don't want to back them up with the local system's image
    • /proc - this is a special filesystem for processes - it will be part of your base operating system when you create a new VPS and doesn't need to be restored
    • /sys and /dev - information about drivers and hardware - will be part of the new OS install, and overwriting could break things
    • /tmp - temporary files usually don't need to be backed up, and large files can be created there to take up space in your backups
    • /var/cache/apt - this is where apt stores packages it has downloaded so they can be reinstalled easily. I don't bother backing it up because it can get huge, and everything in there can be downloaded again easily enough

    Just like the apt cache, you might have other directories that contain large easily downloadable again files, so exclude those. No sense paying storage costs in S3 for files you can just download again.

    Test your backups!

    Backups are no good unless you can restore them. Since you are using a VPS, it should be really easy for you to spin up a new virtual machine and restore to that without affecting your main server. Most VPS providers only charge for the hours/days it's actually running, so it would only cost a few dollars to do.

    Write down exactly how to restore your backups, and any problems you overcame when testing them - when the real time comes you will be stressing out and it's good to have notes to guide you through the process.

    Other gotchas

    If you are restoring to a different machine, they may have provided a different IP address. Make sure you change /etc/network/interfaces right after restoring to match your new IP address, otherwise a reboot will lock you out. Also check in any firewall program you are using to see if anything needs to be changed. If this isn't a test and you are restoring to a different server for real, you'll also need to change the IP addresses in your server software configs and DNS servers.

    Restoring this way will only go smoothly if restoring to the same OS version. Restoring to a newer version of Ubuntu for example will break things, sometimes in strange ways you don't notice until weeks or months later. If you have to restore to a different version, you are better off only copying config files and user data, and installing any software through the OS like it was a new setup.

    • 2