RE: [MLUG] backup

["Matthew Ross" <EMAIL:PROTECTED>]

<snipped the long version of RTFM>

> There are a great many ways to backup mysql databases - 
> enough to fill whole
> chapters of books. Before you use someone else's solution, 
> make sure you've
> read the manual and are aware of the security implications of whatever
> strategy you finally adopt.

It isn't only security, but availability. If this is used 24/7, certain methods simply won't work. I prefer to block out the rest of the world, run my backup, and then let everything back in again when finished, but my clients are almost entirely in the US, so 2am is usually not a problem. If it has to be available 24/7, one method might be to break your database down into small groupings, and schedule their backup staggered throughout the day via a query. Anyone care to argue weather its better to use mysql dump or to use queries to break off bite-sized pieces to back up. IIRC, mysql dump doesn't really stop the service, just freezes it for a period of time.

> Our solution is to use a bash script that copies the contents 
> of all our
> mySQL databases to a local file. We then tar and gzip the file before
> placing it in our backup folder that resides on a RAID array. 
> That folder is
> then rsync'd to another machine each evening and from there 
> will be copied
> to tape and archived.

My most recent backup experience with mysql was two-fold, the official backup was done via mysql dump and then a tape backup during a scheduled downtime every night. An unofficial backup was done an hour later, using a perl script to copy the data to a MS SQL database (where MS Access users could get to it without comprimising the main db server with windows connectivity).

_______________________________________________
members mailing list
EMAIL:PROTECTED
http://mlug.missouri.edu/mailman/listinfo/members