Zimbra NG Modules/Zimbra NG Backup/Disaster Recovery
Zimbra NG Backup - Disaster Recovery
Zimbra NG Backup - Disaster Recovery
The Disaster
Disaster:
1: a sudden calamitous event bringing great damage, loss, or destruction.
2: when your Zimbra server goes boom.
What can go wrong
To classify a problem under "Disaster", one or more of the following must be happened:
- Hardware failure of one or more vital filesystems (such as / or /opt/zimbra/)
- Contents of a vital filesystem made unusable by internal or external factors (like a dumb rm * or an external intrusion)
- Hardware failure of the physical machine hosting the Zimbra service or of the related virtualization infrastructure
- A critical failure on a software or OS update/upgrade
Minimizing the chances
Some quick suggestions in order to minimize the chances of a disaster:
- Always keep vital filesystems on different drives (namely /, /opt/zimbra/ and your Zimbra NG Backup path)
- Use a monitoring/alerting tool for your server to become aware of problems as soon as they appear
- Carefully plan your updates and migrations
The Recovery
How to recover your system
The recovery of a system is divided in 2 steps:
- Base system recovery (OS installation and configuration, Zimbra installation and base configuration)
- Data recovery (reimporting the last available data to the Zimbra server, including Domain and User Configurations, Classes of Services and mailbox contents)
How can Zimbra NG Backup help with recovery
The "Import Backup" feature of Zimbra NG Backup provides an easy and safe way to perform step 2 of a Recovery.
Using the old server's Backup Path as the import path allows you to restore a basic installation of Zimbra to the last valid moment of your old server.
The Recovery Process
- Install Zimbra on a new server and configure the Server and Global settings.
- Install Zimbra NG Modules on the new server.
- Mount the Zimbra NG Modules Store folder of the old server on the new one. If this is not available, you use the last External Backup available or the latest remote backup.
- Begin an External Restore on the new server using the following CLI command:
zxsuite backup doExternalRestore /path/to/the/old/store
- The External Restore operation will immediatly create the domains, accounts and distribution lists, so as soon as the first part of the Restore is completed (check your Zimbra NG Modules Notifications) the system will be ready to be used by your users. Emails and other mailbox items will be restored afterwards.
Settings and Configs
Server and Global settings are backed up but are not restored automatically: Zimbra NG Backup's high-level integration with Zimbra allows you to restore your data to a server with a different OS/Zimbra Release/Networking/Storage setup without any constraints other than the minimum Zimbra version required to run Zimbra NG Modules.
Whether you wish to create a perfect copy of the old server or just take a cue from the old server's settings to adapt those to a new environment, Zimbra NG Backup comes with a very handy CLI command: `getServerConfig`.
zimbra@test:~$ zxsuite backup getServerConfig
command getServerConfig requires more parameters
Syntax:
zxsuite backup getServerConfig {standard|customizations} [attr1 value1 [attr2 value2...]]
PARAMETER LIST
NAME TYPE EXPECTED VALUES DEFAULT
type(M) Multiple choice standard|customizations
date(O) String "dd/MM/yyyy HH:mm:ss"|"last"|"all"
backup_path(O) Path /opt/zimbra/backup/zextras/
file(O) String Path to backup file
query(O) String section/id/key
verbose(O) String false
colors(O) String false
(M) == mandatory parameter, (O) == optional parameter
Usage example:
zxsuite backup getserverconfig standard date last
Display the latest backup data for Server and Global configuration.
zxsuite backup getserverconfig standard file /path/to/backup/file
Display the contents of a backup file instead of the current server backup.
zxsuite backup getserverconfig standard date last query zimlets/com_zimbra_ymemoticons colors true verbose true
Displays all settings for the com_zimbra_ymemoticons zimlet, using colored output and high verbosity.
Specifically,
zxsuite backup getServerConfig standard backup_path /your/backup/path/ date last query / | less
will display the latest backed up configurations.
You can change the "query" argument to display specific settings, e.g.
zimbra@test:~$ zxsuite backup getServerConfig standard date last backup_path /opt/zimbra/backup/zextras/ query serverConfig/zimbraMailMode/test.domain.com config date_______________________________________________________________________________________________28/02/2014 04:01:14 CET test.domain.com____________________________________________________________________________________________________________both
The {zimbrahome}/conf/ and {zimbrahome}/postfix/conf/ directories are backed up aswell:
zimbra@test:~$ zxsuite backup getServerConfig customizations date last verbose true
ATTENTION: These files contain the directories {zimbraHome}/conf/ and {zimbraHome}/postfix/conf/ compressed into a single archive.
Restore can only be performed manually. Do it only if you know what you're doing.
archives
filename customizations_28_02_14#04_01_14.tar.gz
path /opt/zimbra/backup/zextras/server/
modify date 28/02/2014 04:01:14 CET
VMs and Snapshots
Thanks to the advent of highly evolved virtualization solutions in the past years, Virtual Machines are now the most common way to deploy server solutions such as Zimbra Collaboration Suite.
Most hypervisors feature customizable snapshot capabilites, and snapshot-based VM backup systems: in case of a disaster, it's always possible to roll back to the latest snapshot and import the missing data using the "External Restore" feature of Zimbra NG Backup - using the server's backup path as the import path.
Disaster Recovery from a previous VM state
Snapshot-based backup systems allow you to keep a "frozen" copy of a VM in a valid state and rollback to it at will. To 100% ensure data consistency it's better to take snapshot copies of switched off VMs, but this is not mandatory.
When using this kinds of systems, it's vital to make sure that the Backup Path isn't either part of the snapshot (e.g. by setting the vdisk to "Independent Persistend" in VMWare ESX/i) or altered in any way when rolling back in order for the missing data to be available for import.
In order to perform a Disaster Recovery from a previous machine state with Zimbra NG Backup you need to:
- Restore the last valid backup into a separate (clone) VM in an isolated network, making sure that users can't access it and that both incoming and outgoing emails are not delivered.
- Switch on the clone and wait for Zimbra to start.
- Disable Zimbra NG Backup's RealTime Scanner.
- Connect the Virtual Disk containing the untampered Backup Path to the clone and mount it (on a different path).
- Start an External Restore using the Backup Path as the Import Path.
Doing so will parse all items in the Backup Path and import the missing ones, speeding up the Disaster Recovery by a good measure. This steps can be repeated as many time as needed as long as user access and mail traffic is inhibited.
After the restore is completed, make sure that everything is functional and restore user access and mail traffic.
The Aftermath
The disaster happened and you bravely survived it with the help of Zimbra NG Backup: congratulations!
What now?
Just initialize a new Backup Path and store the old one until you please - should you need to restore any content from before the disaster. Then (if your corporate policy allow it) sit back and relax, you deserve it!
Zimbra NG Modules
Zimbra NG Modules Resources
Here you can find useful resources for your Zimbra NG Modules
- What are the Zimbra NG Modules?
- FAQs
- Downloads
- Zimbra NG Modules Installation Guide
- Zimbra Client Zimlet
- How to migrate Zimbra with Zimbra Migration Tool
- How to perform an incremental Migration with Zimbra NG Modules
- Known Issues
