3 ms·
One important feature they didn't mention: if you have a decently powerful backup server hosting all of your data, it may be relatively easy in case of an emerg
by wazoox 15y ago
One important feature they didn't mention: if you have a decently powerful backup server hosting all of your data, it may be relatively easy in case of an emergency to use it to serve production data directly. For instance, you could start a mysql instance with the backup data directly from the backup server, if your production server (or datacenter) is fried.
There is no easy way to achieve that from S3 or tarsnap.
- cperciva 15y agoMirroring is not backup. If you keep your "backup" server in sync with your live server so that you can promote it to production quickly, it's also going to be in sync with any loss which occurs through sysadmin error or deliberate attack. Ideally you should have both a mirror on standby and a backup server with multiple earlier copies of your data.
- sbov 15y agoWhat they said doesn't necessarily have anything to do with mirroring. When we take a backup of MySQL to our backup server, we also create a my.cnf file configured to use said backup. As in, we have multiple config files, each created at time of backup, specifically referencing that individual backup. Each can be easily used to start MySQL up using that X day old backup. Then I can shut it down, and start it up again using a completely different backup just by specifying that backup's my.cnf file, all without modifying either backup. This is also nice because it makes it simple to make sure your backup actually works.