Off-site backups

Since 1.15.0 tilspire can send an encrypted copy of your whole site to storage you control every night, and then prove the copy restores. It's off until you set it up.

What a copy holds #

Every table tilspire and your modules own, your uploads, your themes and your modules, as one compressed archive. It's encrypted on your server before it leaves, with AES-256-GCM under a key only your site holds, so the storage provider sees nothing but the archive's size. Secret settings are left out unless you choose otherwise, and your AI provider keys never go in.

Setting it up #

1. Open System ▸ Backup, and under off-site backups enter an S3-compatible destination: the endpoint, bucket, region and an access key that may write to it. Test connection checks it.
2. Download the recovery kit and keep it somewhere safe, away from the server. It holds the key, BACKUP_KEY, without which no copy can ever be opened. Type its check code to confirm you have it.
3. Turn off-site backups on. Back up now and Test now run each step at once.

These steps ask for your password and a code from your authenticator app.

The nightly restore test #

After each copy, tilspire downloads it again, decrypts it and loads it into scratch tables beside your own, then removes them. A copy only counts as good once that test has passed, and old copies are pruned only when a newer one has passed. The dashboard's health check and an email tell you when a step fails.

Restoring #

From the site's root folder, php core/cli/offsite.php can decrypt a copy, inspect it, and restore it. A restore checks the whole copy before it changes anything, then swaps every table in one step. It lists what it left out, such as the AI provider keys you will need to add again.

Keep the key apart #

Keep the recovery kit together with a copy of site/config/config.php, which holds the keys for two-factor sign-in and your AI providers, and never on the server the copies are made from.