Network Edition Backup Procedure
From Zimbra :: Wiki
(From Zimbra 4.0 docs)
NOTE: For 4.5 Network Edition Backup and Restore Procedures go to the Zimbra_Documentation_Links page and in the Administration Guide section, select Backup and Restore.
Backing up the Zimbra server on a regular basis can help you quickly restore your mail service, if an unexpected crash occurs. The backup process writes a consistent snapshot of mailboxes to a designated backup directory.
Zimbra mailboxes can be restored from the following:
|
•
|
Full backup files that contains all the information needed to restore mailboxes
|
|
•
|
Incremental backup files that contains the LDAP directory server files and all the redo log transactions written since the last backup
|
|
•
|
Redo logs that contains current and archived transactions processed by the Zimbra server since the last incremental backup
|
The figure below shows the sequence of a full point-in-time recovery. When a system is restored, the last full backup is restored, each incremental backup since the last backup is restored, and the archived and current redo logs are restored.
Sample backup timeline
Backup is performed using CLI commands. This chapter describes how Zimbra data is backed up and restored, and how to use the CLI tools to backup or restore your Zimbra server. In addition, this chapter also provides information and general guidelines for disaster recovery.
Contents |
Zimbra Backup and Restore
A full backup process backs up all the information needed to restore mailboxes, including the LDAP directory server, database, index directory, and message directory for each mailbox.
When backing up shared messages, the backup process looks to see whether a Binary Large Object file (BLOB) representing a message already exists in the backup. If it does, it simply flags this object as such and does not copy its content again.
An incremental backup process backs up the LDAP directory server and gathers all the redo log transactions written since the last incremental backup or the last full backup, if this is the first incremental since the last full backup. If the incremental backup process finds no previous full backup for a mailbox, a full backup is performed on that mailbox.
Incremental backups move the redo logs to the backup directory. The redo logs are a journal of every activity that has been logged. They contain a full copy of all BLOBs delivered, as well as metadata such as tags, contacts, and conversations.
These backup files can be used to restore the complete Zimbra system or individual mailboxes so that account and message data is completely restored.
The LDAP directory is backed up as part of either the full or incremental backup process. All accounts, domains, servers, COS, and other data are backed up. You can restore the LDAP directory without restoring the message server, and restore specific accounts to the LDAP server.
Each Zimbra server generates redo logs that contain every transaction processed by that server. If an unexpected shutdown occurs to the server, the redo logs are used for the following:
|
•
|
To ensure that no uncommitted transactions remain, the server rereads the redo logs upon startup.
|
|
•
|
To recover data written since the last full backup in the event of a server failure.
|
If the server is restored, after the backed up files are fully restored, any redo logs in the archive and the current redo log in use are replayed to bring the system to the point before the failure.
Note:
|
•
|
The Zimbra MTA is not backed up, as the data is only on the server for a very short time.
|
|
•
|
Custom configurations, such as Tomcat’s server.xml, are not backed up.
|
The backup destination is known as a backup target. To the backup system, it is a path in the file system of the mail server. The Zimbra default backup directory is /opt/zimbra/backup.
The backup directory structure created by the backup process is shown in the Backup Directory Structure figure below. You can run regularly scheduled backups to the same target area without overwriting previous backup sessions.
Caution: Only create one backup target directory per Zimbra server. ZCS backup and restore does not support having more than one backup target.
Note: Keeping the same backup target saves disk space, because shared binary large object files (BLOB) and other files do not have to be duplicated every time the backup process runs.
Backup directory structure
The Zimbra backup process writes a consistent snapshot of mailboxes to the designated backup directory. Files are not overwritten. The default directory for the Zimbra backups is on the same mail server as is being backed up. This backup directory would be able to be used to restore one or more, or all user accounts. A disk drive can be mounted at the path to the backup target to store backup data, which can be transferred to tapes later.
The Zimbra backup and restore procedures are run as CLI commands. The following utilities are provided to create backup schedules, perform full and incremental backups, restore the mail server, or restore the LDAP server.
|
•
|
zmschedulebackup. This command is used to schedule full backups and incremental backups and add the backup schedule to your cron table.
|
|
•
|
zmbackup. This command executes full or incremental backup of the mail server. This is run on a live server, i.e., while the Tomcat process and the mailbox server are running. In addition to full and incremental backup of the server, the zmbackup command can be used to backup specific accounts for archiving purposes. This command also has an option to delete old backups when they are no longer needed.
|
|
•
|
zmbackupabort. This command stops a full backup that is in process.
|
|
•
|
zmbackupabort -r. This command stops an ongoing restore.
|
|
•
|
zmbackupquery. This command lists the information about ongoing and completed backups, including labels and dates.
|
|
•
|
zmrestore. This command executes a full or incremental restore to the Zimbra mail server. The zmrestore command is performed on a server that is running.
|
|
•
|
zmrestoreoffline. This command restores the Zimbra mail server when the Tomcat process is stopped.
|
|
•
|
zmrestoreldap. This command restores the complete LDAP directory server, including accounts, domains, servers, COS and other data.
|
Refer to Appendix A, CLI Commands for usage and definitions about each of these commands.
Zimbra CLI commands, zmschedulebackup, is used to schedule full or incremental backups by adding the command to your cron table.
When Zimbra Collaboration Suite is installed, by default, a backup schedule is automatically added to the cron table. The default full backup is scheduled for 1:00 a.m., every Sunday. The default incremental backups are scheduled for 1:00 a.m., Monday through Saturday. This is the recommended schedule to have incremental backups run daily and a full backup run weekly. By default, backups older then a month are deleted on the first of each month at 12 a.m.
You can schedule backups for anytime or you can enter the command zmschedulebackup -D for the default schedule. The zmscheudlebackup command allows you to do the following:
|
•
|
Enter specific times and days for a backup
|
|
•
|
Add a new backup time to your current schedule
|
|
•
|
Replace a current backup schedule with another schedule
|
|
•
|
Review your backup schedule
|
|
•
|
Save the schedule command to a text file. This would allow you to easily recreate the same schedule after reinstall or upgrade.
|
To set the default schedule:
The following is returned.
|
f 0 1 * * 0 i 0 1 * * 1-6 d 1 m 0 0 1 * *
|
Backups are run using the Zimbra CLI command, zmbackup. This command performs full backups and incremental backups for all the accounts on a designated mailbox server. By default, the backup files are saved to the server’s backup directory. You can delete the backup files too.
When you initiate a backup, you can issue the command from the same server being backup up, or you can run the command remotely and specify the target server on the command line.
The full backup process goes through the following steps to backup the message store, the database, the indexes, and the LDAP directory:
|
1.
|
Backs up the LDAP directory.
|
|
2.
|
Backs up the global system data including system tables and the local config.xml file.
|
|
3.
|
Iterates through each account to be backed up and backs up the LDAP entries for those accounts.
|
|
4.
|
Places the account’s mailbox in maintenance mode to temporarily block mail delivery and user access to that mailbox.
|
|
5.
|
Backs up the mailbox.
|
|
a.
|
Creates MySQL dump for all entries related to that mailbox.
|
|
b.
|
Creates a backup of the index directory for that mailbox.
|
|
c.
|
Backs up the message directory for that mailbox.
|
|
6.
|
Returns that account’s mailbox to active mode and moves on to the next one.
|
Full backup is usually run asynchronously. When you begin the full backup, the label of the ongoing backup process is immediately displayed. The backup continues in the background. You can use the zmbackupquery command to check the status of the running backup at any time.
Incremental backups are run using the CLI command, zmbackup. The process for incremental backup is as follows:
|
1.
|
Backs up the LDAP directory.
|
|
2.
|
Backs up the global system data including system tables and the local config xml.
|
|
3.
|
Iterates through each account to be backed up and backs up the LDAP entries for those accounts.
|
|
4.
|
Looks in the backup target directory to find the latest full backup for the account.
|
|
5.
|
Moves the archive redo logs, created since the last backup, to the <backup 'target>/redologs' directory.
|
If no full backup for this account is found, the backup process performs a full backup on this account, even if only an incremental backup was specified.
Note:
|
•
|
-t is not needed if the target is the default
|
|
•
|
-zip can be added to the command line to zip the message blobs during backup. Zipping these can save backup storage space.
|
|
•
|
Perform a full backup of all mailboxes on server1 to target at /mnt/disk.
|
zmbackup -f -s server1.domain.com -a all -t /mnt/disk
|
•
|
Perform incremental backup of all mailboxes on server1 since last full backup.
|
zmbackup -i -s server1.domain.com -a all -t /mnt/disk
|
•
|
Perform full backup of only user1’s mailbox on server1, to the default backup target
|
zmbackup -f -s server1.domain.com -a user1@domain.com
|
•
|
Perform incremental backup of user1’s mailbox on server1, to the default backup target.
|
zmbackup -i -s server1.domain.com -a user1@domain.com
Delete backup sessions either by label or by date. Deleting by label deletes that session and all backup sessions before that session. Deleting by date deletes all backup session prior to the specified date.
zmbackup -del 7d
deletes backups older than 7 days from now. You can specify day (d), month (m), or year (y).
Each run of full or incremental backup creates a backup session, also known as the backup set.
The zmbackupquery command is used to find full backup sets. The command can be used to find a specific full backup set, full backup sets since a specific date, or all backup sets in the backup directory. Each backup session is automatically labeled by date and time. For example, the label backup200507121559510 says this is a backup from July 12, 2005 at 3:59.
Note: If a backup session is interrupted because the server crashes during backup (not aborted), the backup session that was interrupted was saved as a temporary session file. The backup session temporary file can be found at <backup target>/sessions_tmp. You can use the rm command to delete the file.
You can use the CLI command, zmbackupabort to stop a backup that is in progress. The backup is immediately stopped and the files are marked as a failed session.
But before you can abort a backup, you must know the backup session label. This label is displayed when zmbackup first starts. If you do not know the full backup label, use zmbackupquery to find the label name.
|
•
|
Stop the backup, if you know the label name
|
zmbackupabort -lb backup200507121559510 -s server1
|
•
|
Stop the backup, if you do not know the label
|
|
a.
|
zmbackupquery -s server1 -l 2005/07/12
|
|
b.
|
zmbackupabort -s server1 -lb backup200507121559510
|
| Verified Against: ZCS 4.0 | Date Created: 4/27/2006 |
| Article ID: http://wiki.zimbra.com/index.php?title=Network_Edition_Backup_Procedure | Date Modified: 4/8/2008 |
