Backups and restore

Choose a storage bucket to enable backups for PostgreSQL, MySQL, Redis® or Valkey. Tenkai makes a full, encrypted copy about once a day, or when you choose Back up now. Restoring a copy replaces the database's data and discards later writes.

Where a backup goes

The backup container uses pg_dump for PostgreSQL, mysqldump for MySQL, or a snapshot for Redis® and Valkey. It encrypts the copy with age on your server and sends it to your storage bucket over HTTPS. The database keeps running.

The S3-compatible bucket is yours, at a provider you choose, such as AWS S3, Cloudflare R2 or Scaleway. It sits outside your clusters, so a backup survives their loss. The copy never passes through Tenkai.

A web application's backup can include its kept files and supported databases linked to it. Tenkai stops the application during the copy, unless you choose Live backup. A live copy may be inconsistent. Other applications can still write to shared databases.

When backups run

Tenkai checks each hour for daily backups that are due. A database is due when its latest backup started at least 23 hours and 45 minutes ago, whether it succeeded or failed.

Back up now and failed backups both move the next daily backup about a day later. An unavailable database or invalid bucket keys can delay it further. Tenkai sends no failure notification. Check the timeline, fix the cause and choose Back up now to try sooner.

Before a risky change, choose Back up now and wait for it to succeed. Restoring that copy loses later writes.

Tenkai keeps each database's 7 latest successful backups, Daily and On-demand together. After a backup succeeds, it deletes the older copies from the bucket.

What the backup key protects

Your team's backup key is an age key pair. A backup container gets only the public key, which can encrypt but cannot decrypt. Tenkai stores the private key encrypted and gives it to a restore container to read the backup.

Bucket access keys alone cannot decrypt a backup. An owner or admin can download the backup key. Keep it outside Tenkai to read backups with age without Tenkai.

Backups are not hidden from Tenkai itself. A compromised restore node could also keep the private key. After a leak, rotate the backup key and replace the bucket's access keys. Rotation protects new backups only. Download the key file again, which includes previous keys for older backups.

How a restore works

A restore stops the database and fills a new volume. Applications cannot connect meanwhile. The database keeps its name and credentials, so applications need no new connection settings.

If the restore fails before the switch, the original data stays untouched. Tenkai tries to restart the database on it. If that fails, choose Retry provisioning. Restoring a database alone does not restore application files, which may no longer match its data.

To inspect a backup without stopping the database, or to recover after losing its node, choose New database. You can create it on another cluster in your team. Reconnect applications with its new name and credentials.

You can also start PostgreSQL or MySQL from a dump in a storage bucket or copy an existing database through its connection URL. This includes databases running on Coolify or Dokploy. These are one-time copies. Later writes stay at the source. See Create a database from existing data.

Limits

• Do not run a MySQL migration during a backup. Schema changes and writes to non-InnoDB tables can make the copy inconsistent.
• A daily backup holds about 625 GiB of encrypted data at most.

Test before you rely on a backup. Create a new database from it and check its data.

Go further

• Back up and restore a database
• Read a backup without Tenkai
• Back up an application that keeps files
• Recover after losing a node

Redis is a registered trademark of Redis Ltd. Any rights therein are reserved to Redis Ltd.