Backups and recovery

Storage

Add an S3-compatible storage under Backups (Cloudflare R2, Backblaze B2, AWS S3, MinIO or any other) with an access key limited to one bucket. Orbit writes, reads and deletes a probe object before accepting it.

The policy

Each database has its own: when it runs, in which time zone, how many days backups are kept and where they go. Keeping backups on the server itself protects against mistakes, not against losing the server.

• When: every hour or every few hours at a chosen minute, every day at a chosen time, on chosen weekdays, or a custom cron (30 2 * * 1-5). A database is backed up at most once an hour.
• Time zone: any IANA zone (America/Sao_Paulo, Europe/Berlin). Daylight saving changes are followed: a time that a change skips runs when the clock jumps.
• The policy shows the next three backups before you save it.

Verified backups

A backup only shows as verified after Orbit downloaded it again and restored it in an isolated container that nothing can reach. A backup that fails that test stays stored but unverified, and the operation shows why.

A backup is a pg_dump in custom format for PostgreSQL, a mysqldump file for MySQL or an RDB file for Redis. It is uploaded with its SHA-256 and read back before it counts as stored.

Restoring

Choose a verified backup on the database's page and type the database's name.

1. By default Orbit first backs up the current data, so there is always a way back.
2. A PostgreSQL restore runs in one transaction, so it either completes or leaves the data untouched.
3. The applications that use the database are restarted, and Orbit compares the restored tables and rows (or keys) with what the backup's test found.

Importing data

Import data brings data from elsewhere as a backup marked Imported. It goes through the same checksum and isolated test, and nothing changes until you restore it.

• From another database: paste its connection URL with the password (postgresql://, mysql:// or redis://). The dump runs on your server, so the source must accept connections from the server's IP. The URL is sealed while the import runs, erased when it ends and never written to the logs.
• From a file: a custom-format pg_dump -Fc file, a mysqldump .sql file or a dump.rdb, up to 64 GiB.
• PostgreSQL's pg_dump refuses a server newer than itself, so import from the same major version or an older one.

Point-in-time recovery

A PostgreSQL database on CloudNativePG whose policy sends backups to external storage also archives its WAL there, continuously.

• Turning it on: saving such a policy restarts the database once and starts a first base backup. Every later backup also takes a base backup.
• The archive: in the same bucket, under <prefix>/orbit/pitr/<database id>, with the policy's retention. A WAL file that is not full is archived after a minute at most. After a major upgrade it starts over from a new base backup.
• The window: the database's page shows it, from the oldest base backup kept to now. When WAL files wait to be archived, or archiving fails, it ends at the last file archived. A failing archive, or WAL waiting for more than 10 minutes, marks the database as degraded.

Restore to a point in time takes any second in the window and the database's name:

1. Orbit keeps a copy of the current data, like any restore.
2. It recovers the archive into a temporary cluster at that moment and copies its data into the database in one transaction.
3. It restarts the applications that use the database and checks the tables and rows.

On a test cluster, restoring to the second before a destructive change took about a minute.

Rebuilding from the archive

When no instance of the database answers (every server or volume holding it is gone), the page says so and offers Rebuild from the archive, with the database's name to confirm.

1. Orbit removes what is left of the instances and their volumes.
2. It recovers the last base backup and every archived WAL file into new instances on the same servers. They archive under a new name in the same folder, so the WAL they came from stays untouched.
3. It restarts the applications that use the database, checks the credentials and takes a first base backup, which opens the window again.

Writes that had not reached the archive are lost: up to about a minute of them. The activity says up to which commit the data came back. Orbit refuses the rebuild while the database still has a primary that answers.

Backing up Orbit itself

Database backups do not include Orbit's own data. See Running Orbit for orbit backup and orbit restore.