Re: best-practices backups

[Brent Baisley]

For databases I usually just make a backup for each day of the month. 
After all, disk space is cheap. So if a month has 31 days, I have 31 
backups. That gives you about 30 days to discover any corruption that 
may have occurred in a database. A crashed database is obvious, but 
corruption usually takes a little while to be noticed, so you want to 
make sure you can go back far enough to get good data. It's probably a 
bit overkill, but it's automated so it's no extra work for me. This is 
on top of the tape backups done for all systems with rotating off site 
tapes.
To avoid extended down time, I also "restore" the latest backup on 
another machine. Then if the main computer crashes, I just change a DNS 
setting (or an IP address if you don't manage your own DNS) to redirect 
everything to the backup server. This is all done with a fairly simple 
shell script.

On Feb 5, 2004, at 5:55 PM, Michael Collins wrote:

Is there any "best-practices" wisdom on what is the most preferable 
method of backing up moderately (~10-20,000 record) MySQL 4 databases? 
A mysql dump to store records as text, the format provided by the 
BACKUP sql command, or some other method? I am not asking about 
replication, rotating backups, or remote storage, and I am not 
concerned about the size of the backup files.  Replication might be 
the best scenario for some sites but this case is not high finance.

--
Brent Baisley
Systems Architect
Landover Associates, Inc.
Search & Advisory Services for Advanced Technology Environments
p: 212.759.6400/800.759.0577
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]