Skip to content

Backup and restore management

Backup

When you click on the Backup and restore tab, a calendar displaying the current month will appear:

backup.png

Each dot inside a day represents a snapshot. Clicking on one of the dots will open the restore dialog which, if confirmed, will restore the instance to the selected snapshot.

A backup is taken automatically every day, but you can trigger a backup at any given time. For example before doing an upgrade. Just click Create backup.

Note

Backups can only be executed when the database is running.

Backup details

Backups are based on snapshots on the underlying storage. A snapshot contains just changed file system blocks. Once a snapshot is restored, the instance is restarted to execute the crash recovery, as if that just occurred.

Snapshots are deleted in an automatic fashion, whenever space reserved for snapshots is full. The older snapshots will be deleted first. This prevents snapshots space overtaking space reserved for the active file system. By default, our system reserves 50% of space for snapshots, that means 50% for snapshots and 50% for the active file system. If the snapshots take more than 50% space, the system will start to delete older snapshots until the snapshot reserved space occupation falls back below 50%.

Binlogs (for MYSQL) and Wals (for PG) files are archived on a separated volume in the primary storage. These files are necessary and used behind the scene to do a Point In Time Recovery.

Restore

There are two types of restore:

  • Snapshot
  • Point In Time Recovery (PITR)

In both cases, our SOP does not allow users to restore beyond (roughly) one month back in time.

A Snapshot restore should be possible at any time, subsequent attempts can be done in any chronological order.

Caveat about timelines

With PostgreSQL multiple snapshot restores, or PITR, are possible but each attempt will create a new timeline. After some attempts, the timelines can become messy. Please get in touch with DBOD Team before that happen. MySQL does not create new timelines, but mixing archived binlog files, from different PITs, can become messy as well.

timelines_postgresql.png

Caveat for MySQL

A PITR should be possible at any time, but subsequent attempts can only reference a point further back in time (not more recent). Because of this, if unsure, it is always better to start with the more recent PIT candidate but it can be time consuming and requiring multiple attempts. This restriction does not apply to PostgreSQL.

To initiate a PITR of your instance:

  • Click on the Point in Time Restore button. It will open a dialog where you can specify the date and time you want to restore to.

pit_restore.png

To initiate a Snapshot restore of your instance:

  • Click on the dot of the calendar corresponding to the snapshot that you want to restore your instance to. A confirmation dialog will pop up.

restore.png

Some restores are possible only on demand

Snapshots (normally one in three) are also copied in a compressed format to EOS storage. Depending on the space required, they might be retained for longer than one month. Binlogs (for MYSQL) and Wals (for PG) are also archived in EOS. Please open a ticket to investigate restoring from EOS but motivating your exceptional circumstances.

Warning

Before starting ANY action, please make sure you understand the abovementioned warnings. Please open a SNOW ticket in case of doubts.

Warning

Please be careful when restoring your database after an upgrade. If the database is restored back to a point in time previous to the upgrade, the restore will fail, please open a SNOW ticket if you need to do this.

Warning: Restore jobs can timeout before actually starting, further info here