Off-site backups
CloudPilot can back up to S3-compatible storage that you own — AWS S3, Backblaze B2, Wasabi, MinIO, or anything else that speaks the same API.
Off-site is the point. A backup sitting on the same server as the thing it backs up does not survive the failure you are most worried about.
Adding a destination#
You provide:
| Field | Notes |
|---|---|
| Name | For your own reference |
| Endpoint | Your provider's S3 endpoint |
| Region | As your provider labels it |
| Bucket | Must already exist |
| Prefix | Optional, to keep CloudPilot's backups in their own folder |
| Access key | |
| Secret key | Stored encrypted; never shown back to you |
Use a restricted key#
Create a key scoped to this one bucket, not a root or admin key. If it is ever exposed, the damage is limited to a bucket of backups rather than your whole storage account.
Running a backup#
Start one from the Backups screen and watch it report progress. Recent backups are listed with their outcome.
Restore at least once#
An untested backup is a guess. Do a real restore — into a scratch environment, not over production — and confirm the data is actually there and usable.
Do it before you need it. The moment you need a restore is the worst possible moment to discover the backups have been writing empty files for a month.
A backup of your data does not capture the shape of the server around it — the packages installed, the web server configuration, the cron jobs. If the machine is lost entirely, plan to rebuild it and restore data into it, rather than expecting a backup to hand you the same server back.
A working routine#
- Back up on a schedule that matches how much work you can afford to lose.
- Keep enough history to survive a problem you did not notice for a few days.
- Restore-test periodically.
- Alert on backup failure via notification channels — silent failures are the norm otherwise.
Raise a ticket and someone will pick it up. Sign in with the same account you use for the panel.
Raise a ticket