Backup and Restore of 4.5.7 CE

[bjquinn]

I've successfully backed up a running copy of 4.5.7 CE on CentOS5 which seems to be working fine. I'm using the LVM method, and I make the snapshot while Zimbra is not running.

However, it doesn't seem to matter what I do, I can't get tomcat running on the restored machine. I'm restoring to another computer that's running the exact same version (4.5.7) and then I run install.sh and do an upgrade. Everything seems to work except for tomcat, which when I do zmcontrol status, it always says

tomcat is not running

And of course, I get some error about a stale PID being found in the zimbra log.

I've tried the instructions exactly as stated in the Wiki and in the forum posts I've found. As I was typing this post, I think I've fixed my problem, so I guess I'll share it with everybody, hope it helps, and maybe someone can explain why I had to do this.

At any rate, here's what fixed it -

1. I started out with a running test production server and a backup server that was actually already set up as a zimbra server.
2. I backed up the test production server using the LVM backup method (I used a short cold backup -- the Zimbra server was only down for a few seconds, long enough to take the snapshot).
3. I copied the /opt/zimbra folder from the backup (version 4.5.7) and copied it over the backup server's /opt/zimbra folder (which had also already been set up as 4.5.7).
4. I upgraded the backup server using install.sh from a 4.5.7 install tar file.
5. zmcontrol start, tomcat won't start.
6. Whoops, Wiki article said to run /opt/zimbra/libexec/zmfixperms first. Did that.
7. zmcontrol start, tomcat still won't start.
8. Hit with sledgehammer, knowing it won't work but frustrated and wanting to break something ---> chown -R zimbra:zimbra /opt/zimbra
9. zmcontrol start
10. Well, of course, that was stupid, now postfix won't start. I should have known that.
11. Forget it, it's time to wipe it all out and try again and write a forum post asking what I'm doing wrong, but first, for the heck of it (believing I've messed up the permissions beyond repair)
12. /opt/zimbra/libexec/zmfixperms again
13. SUCCESS!!!

So, it seems that somewhere along the lines, zmfixperms is supposed to chown something zimbra:zimbra but it doesn't do it. My sledgehammer "chown -R zimbra:zimbra /opt/zimbra" did, and running zmfixperms again undid the damage done by my sledgehammer.

Is this just a bug in zmfixperms? Or am I doing something else wrong?

Anyway, I'm now off to see if I can accomplish the same procedure without having to do the "upgrade" portion.

[Dirk]

The first time you used zmfixperms, did you run it as root or as the zimbra user?

[bjquinn]

Now, THAT command I know I ran as root. I tried it as zimbra user once and it yelled at me and complained about not having permission to set the permissions on all those files.

That was the correct way of doing it, wasn't it?

Oh BTW, looks as if I got a bit greedy when it came to trying to get it running without an upgrade. Tomcat wouldn't start, even with my hack mentioned above. Anyone else been successful in doing a restore without an upgrade? I have some anti-spam changes, etc., that I don't think survive the upgrade.

[greenrenault]

I have used the same approach as you described above successfully, with a few the exceptions:
1. Before migrating, checking /etc/passwd to ensure the user ids are the same
2. Executing /opt/zimbra/libexec/zmfixperms as the zimbra user

I would have expected any anti-spam customisations to be retained.

[bjquinn]

I was just going off the notice in the Improving Anti-Spam wiki that said that many of the changes made there wouldn't survive an upgrade...


... and didn't you get errors saying you don't have permission to change the permissions on these files when running zmfixperms as zimbra?

[bjquinn]

UPDATE : With 4.5.8, I don't seem to need to do the whole "upgrade" step. Just have a server running the same version of Zimbra, stop the services, copy over /opt/zimbra, run chown -R zimbra:zimbra /opt/zimbra, /opt/zimbra/libexec/zmfixperms, and start the services, and voila! Actually, I didn't try it without the last two permissions-related steps, so I'm not sure they're still absolutely necessary, but those could easily be scripted and don't kill any of your customizations. This would allow you to always have a backup server running with up-to-date data as of the last backup. Is anyone else trying anything like this?