Comments on: MySQL database backup file compression: gzip vs bzip2

By: Killer Bees

Killer Bees — Thu, 09 Jul 2009 17:50:03 +0000

Hey Everyone! Yeah using MySQL’s archive storage engine makes things small without the need to dump the .sql all the time. Tradeoff there is that the queries run slowly (Im not sure if it supports indexing)

By: Bill

Bill — Wed, 21 Jan 2009 16:43:38 +0000

Hey. Using MySQL’s archive storage engine can be good for things like logs I believe it uses gzip compression as well.

By: Sunny Walia

Sunny Walia — Thu, 03 Apr 2008 21:00:23 +0000

gzip is definitely faster.

By: kindDBA

kindDBA — Wed, 02 Apr 2008 09:54:34 +0000

which one is the fastest way to compress database backup. I have a backup of 30G and is taking more than an hour to finish compressing

By: MySQL: How do I dump all tables in a database into separate files? | Technology: Learn and Share

Tue, 27 Nov 2007 00:22:56 +0000

[...] MySQL database backup file compress gzip vs bzip2 [...]

By: Samer El Sahn

Samer El Sahn — Thu, 22 Mar 2007 14:28:02 +0000

Dar is a very good backup tool that could deliver diff backups

By: Casey

Casey — Tue, 20 Mar 2007 14:55:40 +0000

Crazytoon: I believe Steven is saying you can use rsync on the actual dumps. So, the basic process would be:

1. Create a new SQL file using MySQLdump
2. Rsync the SQL file to your backup server.

Martin does have good advice for incremental backups. The nice thing about that is when you do a full-backup (once a week?), you can delete the old binary logs to save space.

By: CrazyToon

CrazyToon — Tue, 20 Mar 2007 08:08:37 +0000

Shin: -9 creates a same size compressed file. -s creates 135 meg file. -s is used so bzip doesn’t use too much ram. therefore its not worth using since ram is not an issue here.

Martin: we will be looking at replication in near future. Thanks for binlog comment. another thing for me to try.

By: shinguz

shinguz — Tue, 20 Mar 2007 07:19:30 +0000

Have you tried with bzip2 -9 or -s ???

By: Martin

Martin — Tue, 20 Mar 2007 07:00:26 +0000

For incremental backup I’d suggest using binary logs. Set max_binlog_size to something small and every time a new binlog file is started, copy the last one (I’m not sure if it is safe to copy the currently used binlog file as well).

Even better would be a replication. Then you get a real-time copy of all transactions. That would also use less resources on the DB server, as all further copying and comression (hourly snapshots etc.) can take place on the backup server.

By: CrazyToon

CrazyToon — Tue, 20 Mar 2007 05:42:36 +0000

Steven: what am I rsync’ing? are you talking about rsync’ing the db files themselves? if so, it does make it hard for us to go back to certain date ad pull data out if needed.

dudus: intresting idea. I never heard anybody do this… I will look into it. Thanks!

By: Steven Haryanto

Steven Haryanto — Tue, 20 Mar 2007 05:31:28 +0000

There’s always rsync

I’ve used rdiff-backup in the past, it’s pretty good albeit not very robust (fails with fatal error a lot in situations where it should have just retried or ignored the error). i’m now using rsync combined with some simple homebrewn script.

Unix’s “cp -la” is also useful

By: dudus

dudus — Tue, 20 Mar 2007 03:45:33 +0000

You could keep a backup copy remote and locally. Then everytime you do a new backup you binary diff both and just submit the patch. So onsite you keep only the last one. And off site you keep an old one with several patches.
Then you can apply some of this patches just to clenup once in a while.

Just an idea