5.0.4 upgrade backup procedure; prevent new mail during upgrade?

[adam.vollrath]

I'm going to be upgrading our 70 user NE from 5.0.2 to 5.0.4 this evening. When I make the full backup before the upgrade, should I place the server into Maintenance mode to prevent any new mail from being delivered that won't be included in the backup?

Should I also copy that full backup (and the redo logs) to another machine?

I'm worried about, in the event of catastrophe, losing mails received after this last full backup.

[adam.vollrath]

From #zimbra on freenode:

(10:29:35) zaf: adam_vollrath, when you run the upgrade process it shuts the server down so mail won't be delivered anyway
(10:33:25) adam_vollrath: zaf, rite, but I'm asking about mail delivered after the full backup is started, before the upgrade starts. If somehow the mailstore were to be corrupted, would I lose all that mail delivered after the beginning of the full backup?
(10:33:38) adam_vollrath: Should I just copy the redo-logs as well?
(10:33:45) zaf: adam_vollrath, you need to shut down before full backup
(10:34:02) adam_vollrath: oh, so I can perform a full backup when the server is shutdown?
(10:34:13) zaf: and by full backup, I mean copy all of /opt/zimbra
(10:34:19) adam_vollrath: oooooo
(10:34:22) zaf: not just the mailbox backup
(10:34:42) zaf: yeah

That's very helpful. Anything else I should be concerned about when upgrading, outside of the release notes?

[glitch23]

Although I do not know the specifics of your setup I assume you run everything on one server since you only have 70 users. I ran into this problem about 10 months ago during my first upgrade in the 4.5.x series. I realized that the best thing to do at least for my company was to install another server (nothing robust) that was just and MTA server.

This way I could do the full backup, then upgrade the main server while the mta queued up the emails during the upgrade, which if you have a large mysql db can take a while.

Once the main server was done and back up, the queued up emails would flow, and once the queue was empty, I'd start the upgrade on the MTA server. When that server is down other mail servers trying to deliver mail to it should keep retrying until its back up, which should not take long since there are no mailboxes on the server.

That's just my 2 cents...

[LMStone]

I'm going to be upgrading our 70 user NE from 5.0.2 to 5.0.4 this evening. When I make the full backup before the upgrade, should I place the server into Maintenance mode to prevent any new mail from being delivered that won't be included in the backup?

Should I also copy that full backup (and the redo logs) to another machine?

I'm worried about, in the event of catastrophe, losing mails received after this last full backup.

Configuring a second non-Zimbra MTA (with second MX records) as a backup host is the bulletproof method for not losing any inbound emails.

If you can tolerate bouncing inbound emails during the upgrade (since the installer script starts the ZCS services at the end of the upgrade), you can do things like:

1. Change the firewall rule to block inbound port 25 traffic to the Zimbra host
2. Unplug the Ethernet cable if you are doing the upgrade locally at the console.

Hope that helps,
Mark

[Klug]

• Change the firewall rule to block inbound port 25 traffic to the Zimbra host
• Unplug the Ethernet cable if you are doing the upgrade locally at the console.

You can also to a "ifconfig down" on the interface if you got connected by an out-of-band connection 8)

And I personally launch any upgrade procedure inside "screen", just in case the ssh session goes down.

[glitch23]

Mark is correct, I forgot to add that in my scenario I have 2 MTA servers (both Zimbra though) that have 2 separate MX records.

When the Mailbox server goes down for the upgrade the MTA servers will just hold any email until its backup. When the queue is empty I do the lower priority mail server (lower MX record) then the higher, and any mail sent in between is fine. However there is no MX record for the actual mailbox server, this keeps other servers/relays from trying to hit it directly.

[LMStone]

You can also to a "ifconfig down" on the interface if you got connected by an out-of-band connection 8)

And I personally launch any upgrade procedure inside "screen", just in case the ssh session goes down.

Totally true!

We do major work over the iLO port on HP boxes. No worries about ssh, and we can reboot the box and watch the startup too. It's also nice for doing firmware updates remotely as well. But I'm guessing I'm already preaching to the choir here!

:-)

All the best,
Mark