Conor Schaefer on 17 Jul 2012 08:04:14 -0700

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Server Backup best practices...

On Tue, Jul 17, 2012 at 10:37 AM, Paul Walker <> wrote:
I need to do a server backup on a large production server with a 500GB drive, and maybe 10+GB of sql. Everything has been migrated to a new host over a month ago and I just want to get a canonical backup of the old server before wiping it. I'm thinking to just pull the whole thing down to a local drive with rsync.Â

The database stuff is a little less clear. Typically mysqldump (`or mysql [...] > filename.sql`) will choke before completing a dump. I'm not actually sure where the mysql data resides in the file system. Is a copy of the entire remote hard drive sufficient here?Â

I believe it's not good practice to trust anything that mysql has written to disk that isn't a fresh dump. Any backup script should perform a dump and back that up. No advice on coaxing better performance out of mysql, sorry.

I'll probably put the backups in a truecrypt volume.Â

Use duplicity. Dead-simple encrypted (via GPG keys) backup that makes great use of the rsync algorithm for minimizing transmission. Files are encrypted locally (i.e. on the server being backed up) and then transmitted to the backup server, where they're stored encrypted.

Any other tips here? I don't want to leave any of the old data floating around, or overlook anything...

Don't forget that duplicity provides simple snapshotting of backups, so you can restore a given file from its backup, say, three days ago.



Philadelphia Linux Users Group     --    Â
Announcements -
General Discussion Â-- Â

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --