I don't use veeam but I broke one or two of my lab vms with zimbra while doing snapshots (everything works fine until I recover the snapshot and MySQL wasn't able to start). I usually took snapshot without stopping sevices and without any kind of quiescing.
It's not a thing of big/small enviroment. If transactions are being made to the innodb and no precaution is taken with your dbs, that snapshot/backup will be as good as nothing.
My sugestion: stop/start zm services and if veeam gives you the option, do quiesce snapshots for the backup. It will take much longer then no-quiescing snapshots. You could also search for documentation regarding MySQL/openldap/etc backups with veeam...I only spoted problems with MySQL but you never know.
Enviado desde mi Nexus 4 mediante Tapatalk
Subscribing to thread.
We just picked up Veeam v7 and use 8.x NE. Primary store is about 300GB, HSM is 350GB. We're currently using zmbackup for nightly fulls...
Id like to explore the possibility of using Veeam for a full vm snapshot and do away with the zmbackup jobs all together. I would set the veeam job to quiesce through vmtools as there is no application aware quiesce for linux(that im aware of) through the vmware stack.
ill post results here in a couple days
r3zon8, I wouldn't give up on zmbackup completely, especially since you already paid for the NE. No single backup solution is 100% safe and reliable (although Veeam is known to be pretty good).
Maybe you could use Veeam nightly and zmbackup only on saturday nights. If you can afford to, you could stop zimbra services before the backup and restart them after. Might take less time to backup and it would be safer (no open databases, no files changing during backup, etc).
Thanks for the tip.
The more i think about it Im sure i would still like to have/keep a zmbackup full on disk somewhere if i can afford the disk. I think the decision will come down to how reliable and consistent the veeam job is. I do like how the veeam job buys me the dedupe and compression. its still up the air at the moment but i will definitely post back here when ive added the veeam job with feedback and notes.
i was surprised not to see more threads on the subject. but im sure that could be because zmbackup is the preferred method.
Zmbackup might be the preferred method for the Network Edition, but that's not available in the free edition. Besides, zmbackup only backs up Zimbra, right? Does it backup the installed zimbra packages? I'm pretty sure it doesn't back up the underlying OS. In case the whole box dies and you have to restore on a different one, you're left with installing OS, configuring&updating OS, installing Zimbra and then restoring the backup. If you have backed up the whole VM with Veeam, all those are done in one step. Saves a lot of time in disaster recovery situations.
Veeam is a great product, probably the best backup for VMs, though I'm sure a few phdVirtual fans would disagree :) zmbackup/zmrestore does its job as well, and I would continue to use the built-in tool as your daily backup for Zimbra data. Ask yourself if you've performed a full restore yet. Did any one product work perfectly? If you've been involved with a real-life DR with Zimbra, you probably know the answer to that.
When you said the system image you are referring to the actual vmdk disk image? Can I ask what's the size of your image? I once needed to migrate VMs from one host to another. I needed a quick way of doing it and scp didn't cut it. I researched on the web and found Veeam but even then copying 25 - 50GB VMs took forever. In the end I just gave up and ended up reinstalling everything from scratch on the new box. I'm sure I must have misused Veem but how exactly can you backup a whole 50GB VM image without taking eons?
Originally Posted by danielfarrelly
50GB * (1,024MB/GB) * (8bits/byte) * (1s/100Mb) = 4,096s = 1.14hr over a 100Mbps link. That's theoretical also only.
We recently deployed Veeam B&R v7, in replacement of eVault.
Ours is backing up quite happily. The underlying application (Zimbra) should have no affect on your VM level backups, as long as you have enabled some sort of quiescence. Veeam does this by default. We have not enabled the application level quiescence, however.
I recommend a combo-meal of zmbackup and entire VM backup. It depends on your restore situation...
* User comes over and says they accidentally blew away tons of mail... just fire up zmbackup to bring back that one user's mailbox from last night's backups.
* OS will not boot; everything is hosed... in comes Veeam for full VM restore on the fly.
You should absolutely not rely on restoring a particular account's blob files, as this can be extremely messy. Continue running zmbackup, and for sanity, back up the backups (with Veeam or Bacula!) That way, just in the rare scenario in which your full VM restore bombs, you can still grab the Zimbra backup for nice and clean restore once you rebuild the box.
Exchange has lots of third party tools to enable much more granular restore, but for us Zimbra users, this is what we got.
Kudos to answers above as well.
Quiescing over a Linux VM is not as simple as with a Windows VM which uses a volume shadow copy provider. To snapshot a VM with a relational database like MySQL, the memory and disc quiescing that is performed at a virtualization level (the one that Veeam uses) is not enough "sometimes". This is why, for consistent MySQL over Linux snapshots you have these two options:
1) Stop the service
2) Put the mysql instance in read-only mode during the snapshot
This not only applies to backups, but also any other technology that uses snapshot as its underlaying feature, like "VM level replication" does.
The tricky part with this, is that this snapshot WILL WORK correctly if no Input operation was taking effect at the time of "taking" or "restoring" the snapshot. This is why putting the db in read-only mode is other possibility and it's less traumatic than a complete stop of the service.
People trusting their backups in such technology, is taking a risk in not having a 100% consistent backup...as I said before, depending on the existence of inputs to the db during the snapshot, those could be consistent or inconsisten backups.