Backups and restore
Cover host resources, schedule archives, verify recovery, and restore safely.
Backups schedules and records archives for this server. It sits in the sidebar's Protection group. A job can include files, Docker volumes, Compose stacks, deployment data, repositories, dashboard data, proxy configuration, and native dumps of saved databases. Destinations can be a directory on this server, Amazon S3 or any S3-compatible bucket, or Backblaze B2, and archives can be encrypted with the server's backup key.
Cover what matters
- Open Backups. The picture at the top wires what the server holds to where each job writes. The Coverage list below the jobs shows resources the dashboard can discover, with those not covered by an enabled job first. Selecting an uncovered resource opens a prefilled job form with suggested paths, database dumps, and containers to pause.
- In New backup, review every source and exclusion. Choose a destination; a new job that writes to a bucket encrypts its archives unless you turn Encrypt archives with this server's backup key off. Set a schedule, how many archives to keep and how old they may be,. After saving, use Test destination from the job's menu before relying on the schedule.
- Under Consistency, select a database dump for each saved database connection you intend to recover, and under Containers to pause while archiving, any container that writes to a volume you are backing up. A filesystem archive of an active database directory alone is not the same as a consistent database dump. For a SQLite file, the job can take a native snapshot.
- Use Run now, then open the job's page to inspect its runs, run log, stored archives, and next run.
During a run, database dumps are taken first. The selected containers are paused only while the files are archived and resumed afterward, including when the archive fails. A job that cannot pause a container it promised to pause fails instead of silently taking an inconsistent copy. Backup artifacts and their source manifests are checksummed so later listing, download, and restore can verify the exact artifact. Jobs whose last run failed are listed first. The page no longer flags a job as overdue, so check each job's last run and next run yourself.
Keep the backup key
One backup key per server opens every encrypted archive, and the dashboard decrypts on the way for restores, recovery checks, and downloads. The Backup key panel under the jobs shows the key, what depends on it, and whether a copy has been exported. Use Export key… as an administrator and keep the file off this server: with it, an archive also opens with the age command where the dashboard is not, which matters most for the job that backs up the dashboard's own data. Archives taken before encryption was turned on keep restoring as they were.
Verify and restore
Under Recovery check, set up an application recovery check and choose Verify after every successful backup to run it after each backup. An administrator can also run Verify restore on an individual run, testing a pinned application image against a private extracted copy without production mounts or network access. Verification produces evidence for that particular run; a successful archive alone does not prove the application starts from it.
On a successful run, Browse files lists the archive so you can select a file or directory to restore. Restore files… unpacks into a chosen directory, or puts the files back where they came from; that in-place restore overwrites the live paths, requires a complete manifest, and asks for confirmation. Restore database… restores a native dump through its saved connection, optionally into a drill database first; it is not copied into a live data directory. Download archive gives you an off-host copy, already decrypted for an encrypted run. Restores and downloads require an administrator because an archive may contain everything the job covered.
Retention keeps the newest successful artifact even if its age exceeds the policy. Deleting a job leaves existing artifacts behind. A legacy run without a complete source manifest can still restore into a directory, but cannot prove coverage or restore each source automatically in place.