Community Edt (6.0.6) Smart Backp?

Hello.

I have been reading the wiki articles regarding backup & restore. I've been searching the forums and looked through user published scripts in regards to backups.

All backup strategies inclusive the ones in the wiki basically says; "pack up /opt/zimbra, move it somewhere, in case you need a restore, unpack it". This works. But this is not a smart backup strategy.

What files under /opt/zimbra can I exclude?

Do I need to take backup of binaries which exist within the .deb/.rpm files and will be restored by a clean install before unpacking my config anyhow?

Is there some "minimal" list of files that can be backed up in order to perform a full backup of my contents?

And also, while migrating this installation inbetween versions. Upgrading one to the next. I end up with a file tree looking like:

All backup strategies inclusive the ones in the wiki basically says; "pack up /opt/zimbra, move it somewhere, in case you need a restore, unpack it". This works. But this is not a smart backup strategy.

Sure it is, depending on how you do it. Using a backup tool, e.g. rsync, dar, which does incrementals or deltas, most backups don't take that long. And most of that time is needed for the store and database.

What files under /opt/zimbra can I exclude?

Excluding none would be best.

Do I need to take backup of binaries which exist within the .deb/.rpm files and will be restored by a clean install before unpacking my config anyhow?

Most people would not do a clean install for a restore. Just restore the installation directory, e.g. /opt/zimbra, and you're done. Even if you had to do a clean install, backing up the entire directory insures not missing anything.

Is there some "minimal" list of files that can be backed up in order to perform a full backup of my contents?

You will need to back up the conf directory, store, and the database, at a minimum. These comprise by far the most files and most size of the typical Zimbra installation. It's not worth dissecting the rest of the installation directory to minimize further what you back up, IMHO.

Can these earlier versions be cleaned up? Why doesn't the install script do so? Is there any risk associated?

Sure it is, depending on how you do it. Using a backup tool, e.g. rsync, dar, which does incrementals or deltas, most backups don't take that long. And most of that time is needed for the store and database.

The downside with the incremental backups is that you require to have the other increments taken before that one. And I don't see the justification for snapshotting the binaries just because it doesn't take long or much space

To motivate my question a bit better: All scenarios where I had to perform a restore / disaster recovery included reinstalling a server or atleast Zimbra. It's even in the official backup wiki to install Zimbra with same settings then restore the backup.

Originally Posted by LaFong

Most people would not do a clean install for a restore. Just restore the installation directory, e.g. /opt/zimbra, and you're done. Even if you had to do a clean install, backing up the entire directory insures not missing anything.

Don't you want your package manager (apt/rpm/yum/etc) to be aware that you have installed packages and what files there packages own? If you just install a server, unpack your latest snapshot & start zimbra it will probably work, but it will Not be pretty package management wise.

Originally Posted by LaFong

You will need to back up the store and the database, at a minimum. These comprise by far the most files and most size of the typical Zimbra installation. It's not worth dissecting the rest of the installation directory to minimize further what you back up, IMHO.

Considering that all the collective .deb files are ~425MB I would say this to be considerable backing up a fully deployed server.

The downside with the incremental backups is that you require to have the other increments taken before that one. And I don't see the justification for snapshotting the binaries just because it doesn't take long or much space

So, you want to take a full backup every time, but just of the minimum files? The average backup time will be considerably longer, and take up more room. For instance, a full backup of our server would take 70GB or so, just for the minimum files. The other files take up much less than 1GB. We do a full once a week, but the diffs during the week only take several hundred MB.

To motivate my question a bit better: All scenarios where I had to perform a restore / disaster recovery included reinstalling a server or atleast Zimbra. It's even in the official backup wiki to install Zimbra with same settings then restore the backup.

Our backup software can do a bare metal restore, though I would end up copying over the /opt/zimbra backup because the dbs and un-synced message files are backed up with Zimbra stopped to insure consistency.

Don't you want your package manager (apt/rpm/yum/etc) to be aware that you have installed packages and what files there packages own? If you just install a server, unpack your latest snapshot & start zimbra it will probably work, but it will Not be pretty package management wise.

Only if you have to restore the entire server. If, instead, you have db corruption, you don't have to restore the whole server, just /opt/zimbra. If you did have to restore the whole server, you would reinstall Zimbra, as you've noted. Then, just copy over /opt/zimbra, done.

Considering that all the collective .deb files are ~425MB I would say this to be considerable backing up a fully deployed server.

The .deb files are not in /opt/zimbra, are they? I'm on CentOS, and the rpm installer is elsewhere. You don't need to back up the installer, but the binaries in /opt/zimbra are a very small portion of its overall size.

So, you want to take a full backup every time, but just of the minimum files? The average backup time will be considerably longer, and take up more room. For instance, a full backup of our server would take 70GB or so, just for the minimum files. The other files take up much less than 1GB. We do a full once a week, but the diffs during the week only take several hundred MB.

My last backup was 1.4GB tar-gzipped. Whereof I suspect 400MB or something are from redundant files already found in the .deb files which will be restored upon reinstall before restore.

Besides. Even if I did an incremental backup, it'd feel excellent shaving off the first 400-500MB of "useless" files.

Originally Posted by LaFong

Our backup software can do a bare metal restore, though I would end up copying over the /opt/zimbra backup because the dbs and un-synced message files are backed up with Zimbra stopped to insure consistency.

Cool. However not what I'm having in mind for my home mail server. :-) Would perhaps do it in a company environment. I do back up my whole vm image before I perform any version upgrades. This is probably my as-close-to bare metal backups I perform.

Originally Posted by LaFong

Only if you have to restore the entire server. If, instead, you have db corruption, you don't have to restore the whole server, just /opt/zimbra. If you did have to restore the whole server, you would reinstall Zimbra, as you've noted. Then, just copy over /opt/zimbra, done.

Yes. And this is probably doable with a lot less data backed up. I.e. binaries already supplied. etc.

Originally Posted by LaFong

The .deb files are not in /opt/zimbra, are they? I'm on CentOS, and the rpm installer is elsewhere. You don't need to back up the installer, but the binaries in /opt/zimbra are a very small portion of its overall size.

No. Not as a part of the installation. But all the raw data extracted to /opt/zimbra during your first install comes from these files.

When they are installed/extracted they are probably even larger. And this is a part of your active installation. zimbra-core is 171MB as a .deb, 411MB extracted. During a restore scenario these 411MB backed up data is probably 99% redundant and useless for a successful outcome. Which is the bare minimum I want to achieve.

Sure. While taking backup it will be compressed again. So I still state that the overhead of the total backup is about half a gigabyte.

Originally Posted by LaFong

I believe openldap data is in openldap-data, ssl certs in conf, messages are in store, database is in db. Though some it may have migrated to the db.