Backups and restore

Scheduled, encrypted copies of a database or an app, sent to S3 or to another server's disk.

What it is

Scheduled, encrypted copies of a database or an app, sent to an S3 bucket or to another server's disk, with a restore that puts them back.

The second destination kind is the point: disaster recovery can use hardware you already own, instead of requiring a cloud account you were trying to leave.

How it works

A destination is where artifacts go. A schedule says what to copy, where, how often and how many to keep. A run is one execution, producing one artifact.

The work happens on the agent that stands on the data. For a database it is a dump; for an app it is its data and its configuration. The stream is compressed and encrypted before it leaves the process, with age, using one key pair per destination. The agent only ever receives the public half, so a server acting as a backup store produces artifacts it cannot itself read.

When the destination lives on a different host than the workload, the bytes relay through the control plane, because agents cannot dial each other. They relay as ciphertext: nothing in the middle ever holds your plaintext.

Add a destination

Storage -> Destinations -> Add Destination.

Pick any server in the fleet, including a storage-only box that runs nothing else. Leave the path empty to use the agent's own managed store.

Then click Test connection. It is a real probe run by an agent: a bucket gets a head request, a zero-byte write and a delete, so a read-only key is correctly reported as failed. A folder gets a resolve, a probe write and a free-space check.

A failed probe is a normal result, not an error dialog. Connection log in the destination's menu shows the whole sequence, the agent's own message, and the equivalent commands to reproduce it by hand.

Read the destinations list

Opening Storage -> Destinations tests every destination in the team, so what you see is measured now, not last week. The round is rate-limited, and a destination that cannot be reached keeps its previous figures and turns its badge red - it never goes blank.

Each destination reports how much it holds:

A folder on a server gets a bar: how much your backups take, how much everything else on that filesystem takes, and how much is free. It turns amber past 80% used.
A bucket has no size limit, so it reports the total instead: 48.2 GB in 137 backups.

The refresh icon next to the figure re-tests that one destination.

The same toolbar sits on Destinations and Backups: search, filters, and a switch between cards and a table. Cards show the bar and any warnings in full; the table fits more rows and puts the warnings on the name as icons you can hover.

Save the recovery key

Every destination has one, and the card keeps nudging you until somebody downloads it. Download recovery key in the destination's menu.

It is the private half of the encryption key pair. Two situations make it the only thing standing between you and permanent loss:

DEPLO_SECRET was rotated or lost, so the stored copy cannot be decrypted.
The control plane itself is gone, which is exactly the disaster the backups were for.

With the file, any artifact from that destination can be decrypted anywhere:

age -d -i recovery-key.txt backup.sql.gz.age > backup.sql.gz

Fetching the key is recorded in the activity trail. It is one of only two places in Deplo where a secret is deliberately shown.

Schedule a backup

Start a new backup

Storage -> Backups -> New Backup, or Back up -> New schedule on the Backups tab of an app or a database.

Pick the target

Pick the target: one app or one database.

Pick the destination

Pick the Destination.

Name it

Name it. A name is suggested from the schedule.

Set the schedule

Set the schedule and its Timezone.

Set retention

Set Keep.

Keep is a count, not a number of days. "Keep 7" means the seven most recent successful artifacts, whether they were taken over a week or a year. Older ones are removed after each successful run, and the newest successful artifact is never removed.

Back up -> Back up now runs one immediately without touching the schedule.

Restore

Every finished run is a restore point. On the target's Backups tab they are listed under Restore points, and each row's menu holds Restore, Download and Delete.

In place and destructive. It asks you to type the target's name.

Drops and recreates, per engine.

The artifact's checksum is verified before a single byte is fed to anything. An artifact taken before checksumming existed says so out loud rather than skipping the check quietly.

Back up -> Restore from file takes an artifact you are holding yourself. If it is encrypted, you paste the recovery key.

Download an artifact

Download in a restore point's menu. Only from a server destination, and it is decrypted on the way out. Bucket artifacts are not downloadable through Deplo: you already have credentials for that bucket.

Limits and gotchas

An app schedule does not include its databases. Schedule the database separately. This trips people up more than anything else here.
Retention counts successes. Failed runs do not consume a slot.
A skipped hour on a DST change raises a warning rather than silently missing a run.
Deleting runs can leave a target with no restore point. That is why delete_backups is a separate, flagged capability.
Deleting a schedule does not delete what it already backed up. Retention prunes per schedule, so once the schedule is gone nothing prunes its copies: they stay in the destination, and on the target's Restore points, until you delete them there. Check the list before you delete a schedule that was writing large artifacts.
Deleting the app or database itself does clear them, after 30 days. An artifact whose target is gone is kept that long on purpose, so a delete you regret is still recoverable, then removed from the destination.
A destination on the same server as the workload survives everything except losing that server, which is the failure people actually have. Put at least one copy elsewhere.
Backups are encrypted, always, both kinds. There is no plaintext mode.

If it does not work

Test connection fails on a bucket - most often the key is read-only, or the endpoint and region do not match the bucket. Read the Connection log.
Runs fail with no space - the destination server's disk is full. Its card on Storage -> Destinations shows how full, and how much of it is your backups.
Restore refuses - the checksum did not match, or the artifact is encrypted with a key this destination does not hold. Use Restore from file with the recovery key.