Zmbackup Structure
Zmbackup structure is maintained only by five files and a folder: zmbackup itself, zmbackup.conf, sessions.txt, zmhousekeep, zmbackup.cron, and zmbackup lib folder. Below there is a explanation for each one of the files and what it does in your environment.
Zmbackup
The first one is the zmbackup script itself, where you going to open only when you need to make some modifications by your own. The script is stored inside /usr/local/bin and only the zimbra user can execute it. This is made as a design choice: the zimbra user is the only one that has the .bashrc with the correctly $PATH configured, and is easy to maintain and give support if I only load the this file. Synacor change from time to time the path for the zimbra and ldap binary.
When you execute zmbackup, you have three choices of backup and restores: full, incremental, and distribution list. Each one of the options have a different behavior.
Full Backup
The first one is the Full Backup, where it does a backup of everything the user access and store in the Web Client with the exception of Spam and Trash: both of this folders are not covered by zmbackup as a strategy to make the script more quickly. You can still make the backup of this folders, but you will need to change the following options in each Class of Service or account you want this backup:
zmprov mc <COS> zimbraPrefIncludeTrashInSearch TRUE
zmprov mc <COS> zimbraPrefIncludeSpamInSearch TRUE
When you execute any kind of backup, the first thing zmbackup will do is search if exist a backup in that day for the account. If exist, the zmbackup will not execute again and will only return for you the information that there is a valid backup already done in the day for that account. If no backup was done for the account, then the zmbackup will export all the LDAP entry for each account you choose to do, or all the accounts if the field wasn't specified. Only after this the zmbackup will start the backup of all the mail accounts and store each one of them inside a temporary folder, that in the end will be renamed to "full-YYYYmmddHHMMSS".
The backup process will be executed using GNU parallel, a software that execute various scripts or commands at the same time. The benefit compared to "&" is that parallel manage when a process end and when a new one should be started. At the end of the process, a e-mail containing the result of the process is sended to the admin account, or the account you configured in EMAIL_NOTIFY.
Incremental Backup
Same as the Full Backup, but with only one difference: to execute a Incremental Backup you need to have at least one Full Backup. If you don't have one, the zmbackup will execute a Full Backup in the place. The rules for the incremental is: download everything from the server after the last time a backup action (incremental or full) happened. This information is stored inside /backup/sessions.txt, so, if you lost this file, zmbackup will execute a Full Backup and will lost his capabilities to recover old backups. This kind of backup is stored inside the folder "inc-YYYYmmddHHMMSS"
Distribution List Backup
This one is different from the others, because the only thing that need to be exported is the LDAP entry. A LDIFF containing the Distribution List and their members is save inside a folder called "distlist-YYYYmmddHHMMSS".
Restore LDAP
Zmbackup has a big major difference compared zmbkpose when it does the restore: Zmbackup will not restore the LDAP if you don't explicit ask it to do it. This was made because sometimes you don't want to restore the LDAP, but there is a great chance that you want to restore the messages from some account. Zmbkpose always restore the LDAP, wherever you want or not. Because of this some modifications made before the restore will be lost. Zmbackup doesn't have this problem, so you only ask to restore a session and say if it will be a LDAP restore or a Mail restore.
When the zmbackup restore the LDAP, the first thing he does is delete the account. So, if you are using the webmail during this restore, your session will be expired. Save any e-mail you are writing before doing this, or your editions will be lost.
Restore MAIL
This one is a little tricky, because Zimbra API is slow for restoring messages because it will try to download and save file by file inside the server, besides it will execute some checks to see if the message already exist. So accounts with big e-mails will be more quickly to import than accounts with a bunch of 4k messages.
From the zmbackup part, when you ask a restore using a incremental session ID or a full session ID, the script will act in different ways. When you execute a full restore, the zmbackup will check if there is incremental backups after this full. If exist, it will restore the backup from the most recently incremental backup before a full backup until reach the full backup you asked to restore. It will be something like this:
zmbackup -r -m full-123450000
inc-123456789 -> inc-123456780 -> inc-123456700 -> inc-123456000 -> full-123450000
When you ask for a Incremental Restore, only this incremental will be restored. This is made because the incremental is only part of the backup, and if you asked for a incremental restore, the chance that you don't need all the files is high.
Zmbackup.conf
This file is used to store the configurations for zmbackup, like the number of threads it will use during the backup and restore process, LDAP Server location, user and password, and other options. For more information about each option, please open the article about zmbackup.conf.
Session.txt
This is the zmbackup database: here it will store each backup that has being executed, when was executed, and which kind of backup is. Don't worry with the size of this file so much: if you exclude an old backup with zmbackup, the sessions.txt will be updated too. The only problem is if you delete the backup with your hands, exclude the session.txt, or stop in the middle of the process the zmbackup: in both cases you will end with a broken sessions.txt, and at this moment zmbackup has no feature to recovery the file.
zmbackup.cron
This is where you schedule the backup and the rotation activity. This file is stored inside /etc/cron.d and already has some default values. These default values are:
- Full Backup: Every Sunday at 1 AM;
- Incremental Backup: From Monday to Saturday at 1 AM;
- Alias: Every day at 1 AM;
- Distribution List: Every day at 1 AM
- Backup Rotation: Every day at Midnight
zmbackup lib
All files used as lib or classes for Zmbackup are stored inside "/usr/local/share/zmbackup". At this moment, only the zmbackup-validate-config-file stay there.
zmhousekeep
This script runs and clean all old backups and empty files inside your backup directory. To inform how many days this script should keep for backups, please edit the zmbackup.conf and change the field ROTATE_TIME for whorever value you want in days.