We are also currently setting up a backup system for the main server here in Lund. I am not really taking part of the practical work. My "responsibility" is more to think out scenarios that would break the backup system.
I think it would be good to discuss this on the mailing list and I hope that others will join in as well. Here is what we think so far: * We have ruled out using the "brute force" way. With that I mean stopping everything and just backing up the database directory with rsync (or something). The reason is that if the database files becomes corrupt it may mean that we have a non-working backup. In our case, the idea of stopping everything is also a big NO. * We are currently investigating of a replication setup, where a master database is connected to a single slave. When it is time for backup we make sure that the slave is properly synchronized with the master. Then, we disable the replication, use mysqldump to create the backup. When everything is done, we turn on the replication again. What is currently worrying us is that a full dump may take a very long time. So it is maybe only possible to do that once a month or something. But, from the documentation on the MySQL site it seems like it should be possible to use the same bin-logs that are used for replication as some kind of "incremental" backups. * When backing up the files, there will always be synchronization issues with the database. File uploads or deletions that take place during the backup will leave the uploads directory in a state that is not consistent with the file information in the database. Therefore a file backup should start as soon as possible AFTER the database backup has started. Using subversion is an interesting idea. It may be tough on disk space in the long run though, since nothing can never be deleted. Of course, you can always remove the repository as a whole and start over again with a fresh one at regular intervals... More input and ideas are welcome. /Nicklas Bob MacCallum wrote: > Hi all, > > Does anyone have any genius solutions for backing up BASE2? We're trying to > get a major production server online and obviously backups would be quite > useful. > > I can do what we already do for BASE1: periodic full mysqldump and rsync of > BASE's filestore to an off-site location. That approach only allows me to > restore to the latest full dump (to keep db and files in sync). > > I wonder if subversion could be used to manage the "userfiles" directory > in BASE2? (i.e. commit new files to svn at the same time as a mysqldump was > done). I suspect this is a heavier workload than svn was designed for. > > A more incremental approach to backing up the db would be useful when we are > in the tens/hundreds of gigs. Maybe a slave mysql server? Could that work > reliably between two distant sites? > > Any ideas? > > cheers, > Bob. > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ The BASE general discussion mailing list basedb-users@lists.sourceforge.net unsubscribe: send a mail with subject "unsubscribe" to [EMAIL PROTECTED]
