Backup and recovery

This article describes what to consider when implementing backup and recovery procedures for EMG.

Backing up EMG files

EMG files can be divided into 4 categories:

  • Executables – program files
  • Configuration files
  • Log files
  • Data files (indexed files) containing message queues etc

Executables

These are normally stored in a “bin” directory in the path, are only changed as part of an upgrade and can easily backed up or re-installed from a new distribution.

Configuration files

These are stored in EMGDIR (default: /etc/emg)

Most important files:

  • server.cfg – Main configuration file
  • license – License key file
  • client.cfg – Configuration for command-line utilities
  • routing – Default file for routing information referenced from server.cfg (keyword ROUTING)
  • users – Usually referenced from server.cfg (keyword USERS) including username/password credentials used for authenticating command-line utilities

Depending on exact configuration other files may be used / referenced from server.cfg.

Log files

These are stored in EMGDIR/log (default: /etc/emg/log), frequently change and may be considered to be excluded from backup.

Data files

These are stored in SPOOLDIR (default: /etc/emg/spool) and frequently change.

Simple recovery

If a server with a running EMG is destroyed the necessary steps to get a new server up and running include:

  • Re-install EMG from a new distribution or recover executables from backup
  • Recover configuration files from backup
  • If new hardware is used a new license key needs to be requested from EMG support unless a secondary standby server with a valid EMG license is already in place

The steps above would enable us to get a new server up and running with same config as old one. However, there are a few things to consider.

  • The message id is allocated from indexed file SPOOLDIR/seqno.hdb. If this file is missing it will be recreated starting from message id “1”, OR if the text file SPOOLDIR/seqno is present on emgd startup the message id will be read from there and put into indexed file.
  • All message queues, open delivery report entries, SAT pool entries and keyword sessions are stored in their respective files under SPOOLDIR and will be re-created as empty files (cleared) if not present.

To consider is how to handle the changes that have occured (mainly in data files which change frequently) in the time period between a backup is run and the system becomes unavailable.

If the last EMG message id is known it can be recreated using the procedure mentioned above.

Message queues are normally short-lived (if traffic flows as expected through EMG) while open delivery report entries normally have a life-time between very short (message delivered to recpient immediately) and up to a few days (recipient not available before message expires based on validity period).

One important note here. In order to guarantuee a consistent backup of data files the file system needs to support snapshots such as available in LVM2 (Linux) and ZFS (Solaris).

EMG and MySQL

If EMG is used with a MySQL database the database need to be backed up as well.

There are two ways to do this. Either perform a database dump at a regular interval or replicate MySQL database so a slave instance which can then be used as a replacement should the primary database (master) be destroyed.

Performing a consistent database dump

The following command can be used to perform a dump of the EMG database:

mysqldump --single-transaction -u<username> -p<password> <database> >emg_dump.sql

The option “–single-transaction” ensures a consistent dump of the database is created without locking the database when dump runs, i.e can be performed on a live server with a reasonable performance penalty.