| 1:51 pm on Mar 31, 2004 (gmt 0)|
If you shut down the database before tarring it you'll be all right.
| 7:28 pm on Apr 1, 2004 (gmt 0)|
You can also use mysqlhotcopy - it's a perl script that does something similar while your database is running. It basicly flushes tables and locks them for the current process.
| 3:00 am on Apr 3, 2004 (gmt 0)|
rsync also works well for backing up the database files. Run rsync to back everything up, then lock down the database and run rsync once more to get everything current.
| 8:59 am on Apr 3, 2004 (gmt 0)|
> ...then lock down
I'm not sure how good rsync is at diffing binary files but I wouldn't count on this speeding things up.
| 10:41 am on Feb 18, 2007 (gmt 0)|
Old thread, but this is a current topic for me and you can never talk too much about backing stuff up, so I'm bumping it.
|I'm not sure how good rsync is at diffing binary files |
|I wouldn't count on this speeding things up. |
Between 100 and 400 times faster.
wrote 4394533 bytes read 104210 bytes 101095.35 bytes/sec
total size is 628733048 speedup is 139.76
Finished at Sun Feb 18 07:44:33 GMT 2007
I'm doing a read lock flush, then rsync to a spare server.
Fastest backup system I've ever had for MySQL, and a lot less messy and more reliable than syncronisation which I've also played with (under MySQL 4.* anyway).
[edited by: trillianjedi at 11:49 am (utc) on Feb. 18, 2007]
| 11:10 am on Feb 18, 2007 (gmt 0)|
Rsync is possible the only option when you're database is really big. Once had to back up an 80+ gig mysql db and rsync was the only option that seamed to work.
Started process, went to sleep, woke up to backup completed.