The backup tool creates 2 files for each mail store: a data file and an index file.

The index file contains information about folders, the hierarchy and messages. The fields are colon separated. There are 3 types of entries in the index file, which are R, C and M. The R stands for Root, and is always the first and the only R entry in the index. It contains a key which folders use as their parent key to denote that they are directly connected to the root container of the store.

The C stands for Container, which can be any type of folder. It has 2 keys, one parent and one to identify the container itself. It also has a unique restore key. This key can be used to select the folder for the restore tool. It has an indicator of how many items there are in the folder, a last modification unix timestamp, and a type of the folder (eg. IPF.Note for a mail folder, IPF.Appointment for a calender). The last part of a C entry is the name of the folder, which may contain a colon itself, so therefore it is the last part in the entry. A detailed list of the fields for a Container can be found in the appendix.

The M in the index stands for Message, which can be any type of message or item. It has a parent key, which matches a folder key. Then it has a restore key, which can be used to restore this specific message. A unix timestamp follows which is the last modification time of the message. If a user changed the message, this timestamp will be updated. The index entry continues with the type of message (mail, calendar, meeting request, etc). The entry contains an offset where the item starts in the data file, and lastly contains the subject of the item. Since this subject may contain colons, it is at the end of the entry. A detailed list of the fields for a Message can be found in the appendix.

The data file is a binary dump of all the message properties, recipients and attachments. Folders are only set in the index file, thus only the name is backed up, since that is enough to recreate the folder.

When a first backup of a store is created, the backup tool will perform the following actions:

Because it first creates a list of everything in the store, newly created items during the backup will not be seen and thus will not be backed up. Moved items will still be in the backup, but in the original location they were found in. Hard deleted items during the backup will not be backed up because they cannot be opened anymore.

When the backup is started again, it will find the previous backup and automatically start an incremental backup, and will perform the following actions:

To start the backup process use:

zarafa-backup -u <username>

or for all users and public folders:

zarafa-backup -a

There are a few things to notice about this behavior of the backup tool. When the lists of the previous index and the current contents of the store are compared, it does this per matching container. This means that if the user moved items from one folder to another, they will not be found, thus will be backed up again because they will be marked as ‘new’ in the other folder they we’re moved to.

If a message was changed by the user since the last backup, the item will have a new ‘last modification date’, and will be backed up again in it’s totality since the backup would become unbearably slow if it would need to check all the properties of a message to see which property changed and which not. Overwriting the old message is also problematic because the new message may be bigger than the old, and it will not fit on the old space of the message.

Then when the actual backup process starts, it will first remove the old index. The index file will then be rebuild while the backup processes each message found in the list. The data file will be appended with the new data, keeping the old information which was still available and did not need to be stored again.

For more options of the zarafa-backup tool use:

man zarafa-backup

In order to restore items from the zarafa-backup tool, use the zarafa-restore tool. To restore items or complete folders, find the corresponding restore key in the user.index.zbk file.

This index file isn’t humanly readable with a text editor. Instead, use the readable-index.pl perl script, which can be found in /usr/share/zarafa/zarafa-backup-helpers/. To identify items, use the container name field or the subject to find the items needed to be restored.

/usr/share/zarafa/zarafa-backup-helpers/readable-index.pl username.index.zbk

When the items are found, place the restore keys in a separated file, or give them as parameters to the zarafa-restore tool. If the restore key of a container is entered, the complete container with all its items will be restored on one level. If the subcontainers of the selected container need to be restored, add the -r parameter to the command. The following example restores the inbox with subcontainers from userA. The restore key AF000000 is found in the userA.index.zbk file and needs to be defined at the end of the command.

zarafa-restore -u userA -r -c userA.index.zbk AF000000

The --c parameter as a reference for the index file is not necessary when using an index file from the same user. For example, if using zarafa-restore --u userA, the zarafa-restore tool will automatically use the userA.index.zbk file when index.zbk is in the same directory as where the command is executed.

In the next example a file (keys.txt) containing multiple restore keys from multiple items and folders from user userA is used. Every restore key in the file needs to be separated with a new line.

zarafa-restore -u userA --r --i keys.txt

For more options of the zarafa-restore tool, please check the man page.

man zarafa-restore