Skip to main content

Backing up and Restoring Data

BlueMind automatically generates backups so that data can be easily restored through the admin console.

All system data (calendar/contacts/emails) is saved at regular intervals and placed in a system directory. An additional backup system (Bacula, TiNa, etc.) can be used to copy and externalize these backups on tapes or on the external backup system.

Backup data is organized so that you can go back in time and restore user data at a specific point.

Backup frequency can be configured and depends on the disk space you have available. Please note that the minimum time between backups is one day.

Backups can then be linked to a centralized enterprise backup software provider (Time Navigator, NetBackup, etc.).

What are the benefits of a built-in backup system?​

  • Time-saving Backups are incremental. Only changes (new messages, deletions, etc.) since the previous backup are transferred. transit.
  • More functionalities The system manages data history.
  • More space available The system historizes data without duplicating it. Each backup is standalone (snapshot-like), even if only differences have been transferred. As a result, 10 backups can occupy the same amount of space as your mail storage.
  • Optimization Data is deduplicated automatically.
  • Complete backups The integrated backup tool ensures that all current and future data is automatically backed up, whether it be mail (messages stored as files), calendar and address book data (stored in databases) or configuration files.
  • Compatibility Backups, regardless of when they were performed, remain compatible with all minor versions of a major version (e.g. 3.5.x or 4.x). This means that a backup in a given version can be mounted again in a more recent version of BlueMind. For example, a backup made in version 3.5.12 can be mounted in version 3.5.16-7, or a backup made in version 4.0.1 can be mounted again in version 4.4.3
  • Performance Backups do not cause service downtime. They are designed and performed within a short timeframe to ensure the consistency of the data restored. This constraint lies at the heart of the BlueMind backup design.
  • History Backups are incremental while maintaining data history. The historization feature is particularly useful for those without a large backup infrastructure: one piece of data is only present in one backup and new data is stored in an increment. In addition, to ensure safe restoration, the program reconstructs the data from one backup and one or several increments. This is transparent for the administrator who is able to specify the date the data should be restored from.

Technical backup architecture​

  • Storage and historization component BlueMind relies on the open-source software rsync. This utility allows you to make incremental copies. The data, including the mail spool, is saved by creating symbolic links since the last backup, only new emails are saved.
  • BlueMind modules and backups BlueMind's architecture allows you to split services over distinct servers. Depending on the services hosted on each server, they can be assigned different backup methods adapted to the data stored on that application node (mail spool, database, index, archiving, etc.). As a result, each role assigned to BlueMind servers has its specific backup procedure, thus ensuring optimum and comprehensive data retrieval.
  • Backup localization Backup data is usually outsourced to a separate server. BlueMind offers 2 solutions for configuring storage spaces for backed-up data:
    1. Set up an NFS mount on your production server's file system.
    2. Use a dedicated node (a server) of the BlueMind architecture which acts exclusively as a backup server. You can use either option depending on your availability and your infrastructure type, bearing in mind to keep production and backup data separate to make sure that you are able to remount services in the event of lost or corrupted data.
  • Integration in a backup infrastructure Information systems are typically equipped with backup infrastructure. Software such as Atempo Time Navigator, Tivoli Storage Manager or Net Backup centralize backup methods and manage your backups' historization. These tools interface well with BlueMind. They require a specific configuration to enable the storage of BlueMind's backup history. The BlueMind server performs the backup of production data securely, comprehensively and immediately. The client's backup software must be configured not to historize data. That way, the third-party backup software retrieves the contents of the backup made by BlueMind and transfers it to another tape or other medium.

Backup​

Backup configuration​

The admin console allows you to configure the number of daily backups you want to keep.

To implement a backup policy, go to the BlueMind administration > Backup and Restore > Settings > Configuration:

  • Retention policy: indicates the number of days during which a backup (here, daily backups) and deleted emails should be kept
  • Backup emails (email content): when this option is activated, all server data is backed up, including e-mails. Conversely, when it is not, only contacts, calendar and task data are saved. This allows you to avoid duplicate backups when emails are already backed up in another dedicated system.
  • Backup Elasticsearch: when this option is activated, all BlueMind data indexing is backed up. ⚠️ By checking this option, the backup will be significantly slowed down. Elasticsearch indexing can be easily recreated from the backed-up data (mails, contacts, appointments, etc.), this option is not essential.
info

See the limits and best practices section for more details.

Post-backup actions​

When the backup is complete, the script /usr/bin/bm-post-full-backup.sh runs automatically if it exists.

It can contain several specific operations to be performed after a successful backup.

Permanent access to the last backup

In this example, the script /usr/bin/bm-post-full-backup.sh allows creating, for each BlueMind role, a "last" folder pointing to the most recent backup version:

#!/bin/bash
parts=("bm/es" "bm/pgsql" "filehosting/data" "mail/imap" "mail/archive")
server_ip="192.168.124.72"

for part in ${parts[@]}; do
  echo "creating last directory for part : $part"
  # get last backup directory
  last_version=`ls -tr /var/backups/bluemind/dp_spool/rsync/$server_ip/$part | grep -v "last" | tail -1`
  echo " last version : $last_version"
  # create link
  rm /var/backups/bluemind/dp_spool/rsync/$server_ip/$part/last
  ln -s /var/backups/bluemind/dp_spool/rsync/$server_ip/$part/$last_version /var/backups/bluemind/dp_spool/rsync/$server_ip/$part/last
done

NFS Mount Configuration​

The BlueMind backup space must be shared by all the servers on your BlueMind platform, excluding the edge server.

info

The backup directory must be accessible from all BlueMind domain nodes. You must therefore perform the following mount and verification operations on all the servers concerned.

For ext3 or ext4 NFS mount points, you need to apply the options nodiratime and noatime to speed up disk access. Advanced file systems such as NTFS, ext3/4 can tell you the last file access date. For each file read, an additional writing operation is performed in order to modify the last file access date and check it. Here is an example of mount for the file /etc/fstab:

# Point de montage NFS
nas.mydomain.lab:/backup  /var/backups/bluemind  nfs  rw,soft,noatime,nodiratime,vers=3,exec 0 0

To enable the NFS mount, run the following command as root user:

mount /var/backups/bluemind

Next, we recommend that you test the mount to make sure it is running properly, using the following command lines - always as root user from the BlueMind server:

cd /var/backups/bluemind
touch test

Then, delete the test file:

rm test

Restore​

One single BlueMind backup can be used to perform both a disaster recovery plan and single-user restoration (for a user's data or part of it).

Disaster Recovery Plan (DRP)​

Versions

For data restoration to work, the server must have the same IP address and the same BlueMind version as the original server.

All the data is restored when you install or re-install BlueMind.

When you install BlueMind using the Setup Wizard, you can choose either to install a blank BlueMind system, or perform a global restoration. A global data restoration allows you to rebuild your entire server from a backup, and is akin to a DRP restoration.

This solution is an easy, fast and safe way for you to rebuild a new BlueMind server.

Single-user Restoration​

The single-user restoration functionality BlueMind offers is extremely useful if you want to restore a single user's data quickly. Restoration is done graphically and enables you to choose the object type (entity: user, mail, calendar, shared mailbox, etc.), and then the object whose data you want to restore itself

This functionality also relies on data historization to choose the date of the data you want to back up.

Limits and best practices​

note

The volumes and durations indicated below are indicative values. They can be adjusted according to the performance and capabilities of your platform.

The backup duration is affected by the volume of mail and the retention policy. The larger the mail volume and/or the more important the retention policy, the higher the performance of the backup space.

Generally, for a mail volume <1TB, BlueMind backup can be used without particular constraints.

When mail volume is significant (>1TB), BlueMind backup can be used, but we recommend a retention period of 1 day.
In this case, the use of third-party tools (file system level snapshots, copying to a third-party space...) is recommended to keep a history of backup data.

On the other hand, we recommend using the double-bottom recycle garbage can feature, which is better suited to recovering mistakenly deleted mail. In particular, it enables much longer retention times at no cost to platform performance.

For very large mail volumes (several TB), we recommend disabling the backup of emails and ElasticSearch indexing. Backup of e-mails, and ideally of the platform as a whole, will be carried out at infrastructure level (backup of VMs at hypervisor level, backup at file system or storage level, etc.).

In a nutshell:

  • Mail restoration mainly relies on the double-bottom recycle garbage can feature
  • it is possible to reinject mail recovered from the third-party backup in special cases (mistaken deletion of a mailbox, etc.)
  • integrated backup is used for all other data (directories, diaries, address books, etc.), with no retention period constraints, and restoration is carried out via the BlueMind tool. In this context, it is quite possible to store 20 days of data via DataProtect.
Last updated on