Comments on: Consistent backup with Linux Logical Volume Manager (LVM) snapshots

By: Kaicheng Zhang

Kaicheng Zhang — Tue, 10 Aug 2010 09:42:02 +0000

The article helps me a lot.
But I think the
lvremove /dev/ops/databases
should be
lvremove /dev/ops/dbbackup
since we need to cleanup the snapshot and let the origin volume still work.

By: Mike

Mike — Tue, 06 Jul 2010 22:53:39 +0000

Hi, did not read all the comments, but I did find an error.

You can not “quit;” after doing the “flush tables with read lock;” The second you quit “unlock_tables” is called and thus not holding the lock while you make the lvm snapshot.

That is all.

By: Chris

Chris — Wed, 10 Feb 2010 06:03:50 +0000

The steps in this article won’t lock your tables. The example shows you locking the tables and then quitting the mysql utility. I’m not sure if this used to work differently (I doubt it), but in MySQL 5, quitting the mysql utility drops the connection and unlocks the tables. This is easy to test for yourself by trying to write to them.
Instead, you can get a correct snapshot like this:
mysql> FLUSH TABLES WITH READ LOCK;
mysql> system lvcreate –snapshot –-size=1000M –name=backup /dev/vg01/mysql;
mysql> UNLOCK TABLES;
mysql> quit

Also, the official documentation (http://dev.mysql.com/doc/refman/5.1/en/backup-methods.html) doesn’t mention any need for the FLUSH LOGS statement before taking your snapshot. Searching around the net I am finding some people saying to use it and others not, and nobody explains their reasoning…

By: Brad

Brad — Sun, 13 Apr 2008 08:05:19 +0000

I realize this is a very old post and so it’s possible my comment will never be seen… but I figure it’s worth a try.

I am using this technique to back up a mysql database that is currently relatively small 1.5gb on disk. Everything is working great… except once I have the snapshot mounted, and I try to do something like TAR the results for a backup… the tar is taking about 25 minutes the FIRST TIME… immediately after the snapshot was created. Any subsequent attempts to TAR will happen in about 45seconds.

Is this expected behavior? I am guesing it has something to do with how the snapshot is actually filling in the disk image on the first read… or something, and so the TAR is actually causing a create.

I’ve tried mounting read only to see if that speeds things up… but it doesn’t seem to.

Thoughts?

By: Thomas

Thomas — Thu, 03 Jan 2008 17:50:07 +0000

From my own testing and according to other’s people articles you need to FLUSH TABLES WITH READ LOCK; on MySQL prior to making the snapshot, and release the lock right after the snapshot command have completed.

Note that normally, MySQL can recover from any interruption as long as its fsync() calls secure the data (That means the storage subsystems must not cache writes unless the memory is backed up by a battery, this is usually called WRITE-TROUGH caching on RAID subsystems). That was part of my testing too and I had nodes of a busy MySQL database of a few hundread GBs being power-cycled hundreads of times without a glitch. A single power-cycle on the same database with a WRITE-BACK cache destroyed the database (obviously a testing copy).

This is a limitation of LVM and I experienced issues with both LVM1 and LVM2, both RO and RW (LVM2 only) snapshots. Entreprise-grade hardware raids with snapshot features shouldn’t suffer from this issue.

By: Anand Gupta

Anand Gupta — Tue, 21 Aug 2007 19:15:48 +0000

I have heard about lvm2 snapshots not being stable, and lot of people loosing data over it. What are your thoughts on that ?

By: durian

durian — Tue, 06 Jun 2006 02:43:36 +0000

Looks very similar to:

http://tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html

By: Naan Yaar

Naan Yaar — Mon, 05 Jun 2006 17:53:39 +0000

To echo what Gordon Messmer says above, LVM snapshots will not obviate the need to make applications that use the filesystem quiescent before making the snapshot. Otherwise, there would be no guarantee that the application that writes to the filesystem has consistent, workable data that it can recover from at the instant in which the snapshot was created.

By: Gordon Messmer

Gordon Messmer — Mon, 05 Jun 2006 14:48:32 +0000

It should probably be pointed out that you still need to take the database offline while you make the snapshot. Snapshots don’t eliminate the need for downtime to get consistent backups, they just make it very short (a few seconds, instead of the full backup time).

I’ve worked with a number of people who read articles like this one, and came away with that misconception.

By: LinuxTitli

LinuxTitli — Sat, 03 Jun 2006 05:20:43 +0000

J.B. Nicholson-Owens,

Thanks for pointing out this issue.

Appreciate your post.

By: J.B. Nicholson-Owens

J.B. Nicholson-Owens — Fri, 02 Jun 2006 23:02:26 +0000

By the way, “commercial or GPL” backup programs are not opposites. You don’t mean commercial here, you mean non-GPL’d backup programs or possibly you mean proprietary versus free software backup programs.

Many business redistribute GPL-covered software as part of business activity, hence GPL-covered software is commercial. Since GPL-covered software is commercial software, GPL-covered software is not the opposite of commercial software, GPL-covered software is a proper subset of commercial software.

See http://www.gnu.org/philosophy/words-to-avoid.html#Commercial and http://www.gnu.org/philosophy/selling.html for more on this common confusion of terms.