Replication mechanisms protect data against physical damage. However, this does not mean that no backups are required. Classic backups protect data against logical corruption. Standard backup tools require scripting, which introduce the risk of potential human error.

EuroDB offers ready-to-use tools to perform physical backups. They are created continuously and provide the possibility to recreate the database to any point in time. This allows to schedule disaster recovery procedures even in the most demanding cases.

When logical backup is used, it is taken from the backup window. In the event of a database failure (restore from backup is necessary), a copy from previous backup window is available. This may cause the following situation:

The backup was made at 04:00 a.m., and it is a consistent image of the database from that hour. A failure (involving logical data corruption, e.g. due to an undetected error in the application) was detected at 12:00 p.m., at 12:30 p.m. the decision to restore from the backup was made. This would mean the loss of data from the previous 8 hours. In most cases, this situation is unacceptable and very expensive.

EuroDB offers a mechanism that in addition to the backup performed in the backup window also has information about all transactions that took place later. This enables to recreate the database and then execute the saved transactions on it until the specified time. These transactions can be compressed to save disk space on the backup server.

Centralization of backups is an important asset of the EuroDB. One central console enables to back up and restore many instances. The backup manager has a number of configurable options, including: minimum number of backups, recovery window – a range of dates in which the database can be restored to a selected point in time.

Tablespaces are handled transparently and can be relocated (including the primary one) during the restore process.

The backup can be restored to another location, i.e. to a temporary (sandbox) server. This allows for a scenario where a copy is restored on a temporary server in the first step, and only then a single table is selectively restored on the production server.

The manager has modules that enable monitoring in Nagios format, as well as management via Puppet. In case of special needs it can be also customized using a RESTful API.