Backups
Snapshot a bucket by hand or on a schedule, keep a fixed number of copies, and restore missing files.
A backup is a point-in-time snapshot of a bucket's live object list. The files in it stay restorable after the objects themselves are deleted and purged, which makes a backup the answer to a bad migration or a script that deleted the wrong prefix.
Console only, for now
Backups and backup schedules live in the console. There is no REST route, SDK method or CLI command for them yet, so they cannot be driven from CI.
Taking a backup
Open Backups
In the console, open the environment, then File Storage, then Backups. The page covers every bucket in that environment.
Select Create Backup
Choose the bucket, and give the backup a name if the default
Backup 2026-08-13 09:30will not mean anything to you later.Wait for Completed
A bucket with up to 10,000 objects is captured immediately and lands as Completed. A larger bucket shows Creating while the manifest is filled in, and only becomes restorable once it finishes.
| Status | Meaning |
|---|---|
creating | The manifest is still being written, not yet restorable |
completed | Written in full and restorable |
deleting | A delete is running against it |
failed | Creation did not finish, so delete it and take another |
A backup records references to the stored content rather than copying it. Those references are also what keeps the content alive: a file deleted and purged from the bucket is still there for as long as a backup names it.
Automatic backups
A schedule backs one bucket up repeatedly and prunes its own output. Configure it from the Automatic backups panel on the same page.
| Setting | Value |
|---|---|
| Schedules per bucket | One |
| Interval | Daily, weekly or monthly |
| Backups to keep | 1 to 30, default 7 |
| Plans | Pro and Enterprise |
A new or re-enabled schedule fires on the next hourly sweep, then repeats one interval after each run. Monthly runs keep their day of the month and clamp it to the shorter month, so the 31st becomes the 28th in February.
Retention counts completed automatic backups of that bucket, oldest pruned first. Backups you took by hand are never pruned, whatever the retention is set to. If the plan stops covering scheduled backups, the schedule is left alone and its next check is pushed out by a day rather than deleted, so it resumes when the plan does.
The panel shows when a run fails and how many failures in a row a bucket has had. Failed runs do not stop the schedule; the next interval is attempted as normal.
Restoring
Restoring recreates the objects that are missing from the bucket, and only those. An existing object at the same key is left alone, never overwritten, and counted as skipped in the result. So a restore can bring a deleted folder back without touching anything written since the snapshot, and running the same restore twice changes nothing the second time.
Only a completed backup can be restored. To roll a key back to its backed-up content, delete the live object first, then restore.
Deleting a backup
Deleting a backup releases its references. Files that still exist in the bucket, or in another backup, are unaffected; the bytes of files that existed nowhere else are removed for good. A backup cannot be deleted while it is still being created.
This is also what blocks bucket deletion: a bucket with backups is refused until they are gone. Delete the backups first, then the bucket. See Buckets.