Why do you need to stop Zimbra for LVM snapshot backup?

[james2012]

Having to shut down Zimbra to make a backup is not ideal. I have been unable to find a good/detailed explanation as to why you need to stop Zimbra to make LVM snapshots for backup. I thought the whole point of LVM snapshots were to make consistent backups of running systems?

-s, --snapshot
Create a snapshot logical volume (or snapshot) for an existing, so called original logical volume (or origin). Snapshots provide a ’frozen
image’ of the contents of the origin while the origin can still be updated. They enable consistent backups and online recovery of
removed/overwritten data/files.

[y@w]

Hi James, welcome to the forums.

The quick answer on this is because you are working with a couple of database servers running (LDAP and MySQL) and they may not recover to a usable state if you restore to a snapshot without stopping them first. The other thing that can happen is a user can remove/move/add an item while the backup is running and it may be written to the backed-up database but not the backed up database (or vice versa). Stopping the services before doing a filesystem snapshot is really the only way you will get a good, easily restorable copy every time.

[ArcaneMagus]

y@w the whole point of an LVM snapshot is that it is near instant (takes a few ms at most, and I believe all I/O is halted during the snapshot) so it is impossible for a user to move a file during a backup being run on an LVM snapshot

However... there is still the issue of the databases, which have varying degree's of recoverability from a live snapshot. The last that I looked into this the storage system used for the MySQL database was fairly resilient to live snapshots, but I think the LDAP might not.

Another issue (which I think y@w might have been hinting at) is you might run into a situation where a change has been written to one part of the system (I.E. the MySQL DB), but not another part of the system (I.E. the mail store).


So to sum it up... yes an LVM snapshot is a near instant copy of the file system, but the usability of that snapshot is highly questionable if taken on a live Zimbra system. The fastest backup you can get on the open source edition (using a single server) is to shutdown zimbra, take the snapshot, start zimbra, and then take your backup from that snapshot.

[y@w]

y@w the whole point of an LVM snapshot is that it is near instant (takes a few ms at most, and I believe all I/O is halted during the snapshot) so it is impossible for a user to move a file during a backup being run on an LVM snapshot

Yeah, you're right. I was thinking of just copying the files, not a snapshot. The second part of my answer (not intentionally my emphasis) doesn't make sense in this context

In theory it can be done live, but not very conveniently. The reason is that your database servers (MySQL, openldap) will have data in memory to be written to disk that's not written to disk yet. If you don't capture that data to disk, it won't be backed up in the filesystem snapshot.

MySQL is fairly resilient this way (think: pull power plug on server), though I don't do this for fun. There's plenty of documentation out there on backing up MySQL via a snapshot while live (Using LVM for MySQL Backup and Replication Setup | MySQL Performance Blog), but the answer is not just "take the snapshot".

With openldap, I don't even try restoring via the live data files if it doesn't start. Perhaps others will know why, I just haven't looked into it. A slapcat/slapadd is almost always necessary.

You could do a snapshot of a virtual machine and have it be fully recoverable, granted that you also make a snapshot of the memory.

The only real way to figure this out though, would be to try it for yourself. I'd run a restore (well, several) of a snapshot and see what is restorable and what is not. You're the one that has to be there crossing fingers hoping that the thing restores successfully at 3 AM (or 10 AM on Wednesday if you're really unlucky ((knocks on wood)) ).