Recurring Backups and Retention #
Setting up a recurring backup #
Go to System > Backups and click Configure Recurring Backups in the Recurring Backups box, then create a new recurring backup:
| Field | Value |
|---|---|
| Source | The database to back up — Main Database. |
| Destination | One of your Backup Destinations. |
| Period | The number of seconds between backups, e.g. 86400 for daily. |
| Backups to keep | Optional retention limit for this schedule — see below. |
Common periods:
| Schedule | Period (seconds) |
|---|---|
| Every 6 hours | 21600 |
| Daily | 86400 |
| Weekly | 604800 |
A recurring backup runs as soon as its period has elapsed since its most recent backup, and the first one runs shortly after the schedule is created. You can create multiple recurring backups — for example, a daily backup to one destination and a weekly backup to another.
Retention #
By default, backups accumulate forever and will eventually fill the destination server’s disk. Two independent retention limits can prevent that, and you can use either or both:
Per-schedule limit #
Set Backups to keep on the recurring backup.
This keeps the most recent N successful backups made by that schedule and automatically deletes older ones, including the file on the destination server. For example, a daily backup with Backups to keep = 30 maintains a rolling 30 days of backups.
Each recurring backup has its own limit. Two schedules pointing at the same destination each keep their own N backups.
Example configurations #
The rule of thumb: Backups to keep = how long you want to retain ÷ the period.
| Goal | Period (seconds) | Backups to keep |
|---|---|---|
| 3 days of hourly backups | 3600 |
72 |
| 7 days of backups every 6 hours | 21600 |
28 |
| 7 days of daily backups | 86400 |
7 |
| 30 days of daily backups | 86400 |
30 |
| 12 weeks of weekly backups | 604800 |
12 |
| 1 year of monthly backups | 2592000 |
12 |
Schedules can be combined on the same destination for tiered retention — for example, one schedule keeping 7 daily backups plus another keeping 12 weekly backups gives you fine-grained recent history and three months of coarser history, at a total of 19 stored files.
Per-destination limit #
Set Backups to keep on the Backup Destination itself.
This caps the total number of successful backups stored on a destination, across all schedules and manual backups combined. This is a hard safety limit for the destination server’s disk: whenever the total exceeds the limit, the oldest backups on that destination are deleted first, regardless of which schedule created them.
The destination limit counts manual backups too. A manual backup sent to a capped destination will eventually age out like any other. If you want a backup kept forever, store it on a destination without a limit.
When cleanup runs #
Old backups are only cleaned up after a new backup completes successfully:
- A failed backup never triggers cleanup, so a broken destination or database problem can never delete your existing good backups.
- Only successful (Finished) backups count toward the limits and only successful backups are ever deleted by them. Failed backup records don’t use meaningful space and are kept for visibility until you delete them.
- If backups keep failing, your most recent N good backups remain untouched on the destination, no matter how long the failures continue.
Leave both fields empty to keep every backup. In that case, plan the destination’s disk capacity accordingly — a rough estimate is the size of one backup file times the number of backups per month you make.