List of files outside of /opt

[simonb]

Anyone know of a list of files altered or created by Zimbra during installation and running Zimbra that are outside or the /opt directory?

This would be useful for me to know for planning a cold-backup VM scheme.

[phoenix]

All the files that Zimbra requires are in the /opt directory, that's all you should backup. For a restore you'll need to have the same operating system and install a version of Zimbra before you do the restore of your backup - please search the forums and wiki for details.

[simonb]

Yes, that is how I normally do it. I can see that I didn't adequately explain what I am trying to achieve. So apologies for that.

I am setting up an EC2 instance for an emergency failover scenario. We found we can failover by swapping in the captured /opt directory of the initial install and a recently captured config directory from an nfs backup. LDAP is from an external Zimbra instance. Then restore the latest backup file. The accounts appear first followed by the emails. So we get the users up and running while their mailboxes are being recovered in the background. Speed is the essence in this case.

We've kind of assumed that the version of Zimbra installed on the EC2 instance has to match the instance being recovered for this to work.

This will work if the EC2 instance version of Zimbra matches the failed-over machine. If not, then I guess we will also need to run a re-install over the EC2 instance. The problem is that this re-install is quite a lengthy process. If the only files outside of /opt are minor things like the zimbra user definition, some cron changes, rpm database changes, the init script, then why go through a whole re-installation to re-assert them. Why not just splat these few files over the EC2 instance....if I knew what they all were? Hopefully, for emergency purposes, updating the rpm database won't even be necessary, but even if we do need to re-install the rpms, it doesn't take so long to do.

Upgrading Zimbra every time there is an update and re-bundling an EC2 instance takes a long time. I'll do it if it is necessary, but I was exploring the possibility that I could increase the useful lifetime of a particular EC2 image without rebundling through multiple Zimbra upgrades.