On 03/23/2012 05:19 PM, Bob Hoffman wrote:
Hello all, I am down to my last hurdle of my project, backups. I am thinking of three different ways to go and wanted to ask for input on what you think is the better choice. Not asking for 'how to' but more of 'what is best in your experience'
The scenario... centos server acting as a virtual host. Virtual machines are webservers and dns servers. All on one machine, all running centos 6. Virtual machines are kvm, sitting in lvm storage.
What I want to do.. auto backups of the virtual machines to be stored on the virtual host's extra drives for later download to my home computer.
Many backup solutions and programs seem centered on a network of computers with file sharing. I do not have this and don't think I want to go that way on my host.
My three thoughts, not sure which one to pursue... (involves certain folders, /home/ (which includes maildir), /var/www/, /mysqlhotcopys and bin files, and maybe a few more. I can rebuild the comp pretty quick and then restore, or maybe just do one big backup of each server, then work on the folders as a solution)
1- Amanda. I do not know much about it or how it would deal with mysql databases, but it look promising. I do not have a NFS in place on any of the installs.
2- rsnyc - some kind of rsync going from the host to each machine, putting it on the host's backup drives. Adding a mysql hotcopy of some kind on the VMs, along with bin files, saved to a special folder that will then be part of the rsync. Once a week full of both rsync and mysqlcopy, then incremental daily.
I think backuppc, syncing over rsync directly to the VM makes sense here.
3- Use kpartx ? and access the lvm the VM is on to rsync internally on the host, ditto above with the mysql copy/bin setup.
You can't safely mount the VM's partitions without shutting down the VM. You might get away with it with an LVM snapshot taken inside the host, but that assumes that it's safe to access the LVM datastructure from outside the VM while the VM is running and it may not be.
Number 3 seems like it is the securest way, but obviously not much info out there on it. Number 2 seems like the 'old way' and will require some real work to get it right number 1 looks good, but do not really know anything about it.
For the database you have many options. I would suggest at least weekly do this: 1) shutdown the mysql database server 2) take a snapshot of the partition with the mysql database server 3) restart your mysql server (the whole shutdown/snapshot/restart take less than 15 seconds) 4) Do a full backup of that snapshot, using backuppc, tar, dump or whatever you choose
In order to do this, you must of course setup the database on an LV partition (MY LV partition is simply an ext4 or ext 3 partition, mounted on /var/lib/mysql). Make sure there is adequate space on your snapshot LV partition for any data that might get written to the database before the snapshot gets backuped and deleted.
If your database is small you can do daily backups of the entire database like this. Otherwise you can use tools like mysqldump and mysqlhotcopy, but you should make sure you have a pretty good understanding of these tools and that you are backing things up properly with them.
Some people run replication between two database servers and then shutdown the secondary server and back it up.
There are also backup tools like duplicity and storebackup which I have recently learned about that are supposed to be able to do incremental backups of binary files, where you could actually do a restore of the database from your full backup and then somehow apply an update to the database files from incrementals. I have not yet tested this method. There again, I would still shutdown/snapshot/restart the mysql server to ensure database integrity during the backup.
Whatever you choose, I suggest you perform test restores and if you choose database level backups, make sure you understand what you are doing and that you are saving the backup in a way that you are able to recover it.
If you data is important consider doing backing up in two different formats to 2 different media types.
I think simply doing at least a weekly full backup of the entire /var/lib/mysql directory (via snapshot or server shutdown) is the least prone to user error.
Be aware that things like changes in database format, etc can make old backups difficult or impossible to restore. Many people, myself included, ran into some problems when mysql changed the way it handled character set encodings and it was not so straightforward to restore mysqldump backups made with an older version of mysql, using the latest version of mysql. Many options had to be specified and some people still had to write scripts to manually go through and make some conversions. I ran into these problems while upgrading a mediawiki database that was running under a very old version of mysql for a client.
So if having long term access to old backups is important, you must check for compatibility between newer/older versions of mysql and either do conversion/refresh of your data, or make sure you still have functional copies of the tools necessary to restore older versions.
Nataraj
Which way would you go, or do you have a different way you like better? _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos