Posted on

Good Practice / Bad Practice: Off-site Backups

In today’s gp/bp an open door will be kicked in: take your backups offsite!
I was actually tempted to create a poll to see how many of you do not have proper backups, and how many of you do not take those backups offsite. It is a simple piece of advice and relatively simple to set up. Offsite in this case would ideally be physically offsite: to a different server in a different building in a different location. A start however is to take them to a different server. And don’t make the mistake of thinking a different VPS on the same physical server is good enough. True, that will protect you from operating system failure of the guest, but it will likely not protect you from hardware failure, or operating system failure on the host OS.

Also, take good care of how you are getting your backups offsite. A normal FTP connection might do the job, but it is hardly secure. Ideally, use SFTP or rsync over ssh to stream your backups offsite.
Some people still take their backups offsite by physically moving a cd, dvd or tape from one location to another. It’s a good start, but in this age of cheap broadband, you might want to think about doing this online. A cron-job is much less likely to not run than it is for you to forget to move that tape.

In our good practice / bad practice series, we will provide you with byte/bite sized pieces of advice on what we consider good (or bad) practice in MySQL-land. The topics can be just about anything, so expect random things to come up. Also, the level of advancedness greatly varies. A topic might be a no-brainer for some, a reminder for others and a revelation for a third person. We strive to tender to all of you!

3 thoughts on “Good Practice / Bad Practice: Off-site Backups

  1. Another secure and reliable way to communicate between sites is OpenVPN.

  2. Hi,

    Good advice.

    I think it was AST who said a truck full of tapes running down manhattan has more bandwidth than your fastest network. That was written quite a few years back, but may still be correct. Sure, a few GBs are fine; some dozen also OK. A few hundreds – may be a problem; may take quite long to download/upload again. Taking the tape with you by car may be faster 🙂


  3. “good enough” depends on the data being backed up, and is relative. It may very well be that a copy to different disk on the same server is enough risk prevention, or it may be necessary to have a colo half a world away.

    Risk management here is the key. In the days leading up to Hurricane Katrina and when worrying about Hurricane Wilma, folks in the states realized that having one data center in Miami and another in Houston wasn’t enough coverage for them, because one storm may have knocked them both out.

    At Pythian we have daily scripts that check to make sure the backup was succesful. We also discuss the backup *strategy* including whether there is an offsite copy, every 2 months, for each client. This way everyone is totally informed and there is never a problem of “I didn’t realize we weren’t backing that up!” (it’s also handy to see the snapshots in time of how the backups are growing, and how long the backups take).

    Amazon S3 is a convenient way to store backups; we’ve developed a system to be able to store and retrieve backups based on the backup date (S3 doesn’t use traditional folders, so the retrieval can actually be rather tricky).

Comments are closed.