Turn backups on for an application
Choose what to copy, how often, how many to keep and what to leave out — then run one immediately to prove the storage works.
Backups are configured per application. You can start from either end: Backups → Overview → Set up backups, which asks which application first, or the application's own Backups tab, which already knows.
Both open the same form and produce the same thing: one schedule, one destination, one retention count.
You need a storage destination first. Without one the form has nowhere to send anything.
Steps
Open Backups and click Set up backups. On a server where nothing is protected yet, the Overview tab is an introduction with that button at the bottom.
The form opens with nothing chosen yet. It already knows which storage destination to use when there is only one.
Choose the application. The picker lists every application on the server, with its primary domain underneath, and has a search box for when there are many. Staging sites appear as their own entries.
Choose what to back up.
| Option | What it copies |
|---|---|
| Files and database | Everything. The only option that gives a full restore. |
| Files | The web root only. |
| Database | The attached databases only. |
Database is greyed out, with This application has no database, for applications that have none attached — a static site, or a site whose database was never linked. Attach one on the Databases screen if that is wrong.
Set the schedule. Leave Back up automatically on and pick a frequency: every hour, every 3 / 6 / 12 hours, daily, weekly or monthly. Daily, weekly and monthly also take a time of day.
Times are UTC, as the form says — not the server's local time and not yours.
Turning Back up automatically off keeps the destination and the settings but runs nothing on a schedule; backups then only happen when you press Back up now.
Set how many to keep. Between 1 and 365. The number is a count of backups, not days — at Daily · keep 7 that works out to about a week of history, and the form says so underneath.
Pruning happens at the end of a successful run, and only verified backups count. If you lower the number later, the panel removes the excess straight away rather than waiting for the next run.
Exclude what you do not need, under Exclude files or folders. One item
per line, with separate boxes for paths and for databases. The chips underneath
fill in the usual suspects: node_modules, .git, vendor, storage/logs,
*.log.
Excluding is not just about size: anything excluded is not restored later, because it was never in the archive. Keep that to things the application can rebuild — dependency folders, caches, logs.
The grey line at the bottom is the whole configuration in one sentence —
my-blog · Files and database · Daily · keep 7 · Offsite SFTP. Read it before
saving.
Save, then run one immediately. The confirmation offers Back up now, and it is worth taking: it is the only way to find out that the storage credentials work without waiting for the first scheduled run.
After it is on
The application's Backups tab becomes a summary: what is backed up, how often, how many are kept, where they go, when the last run was and when the next one is due — plus the last few runs.
- Back up now queues a run immediately. It does not move the schedule.
- Edit settings reopens the same form.
- All backups jumps to the History tab filtered to this application.
- A row tagged Safety copy was taken automatically before a restore, not by the schedule. Safety copies never count towards retention and are never pruned.
Pause or turn off
Turn off backups removes the schedule and its settings, and it insists on deleting the application's archives at the same time — the panel will not leave backups behind that nothing is tracking.
If what you actually want is "stop running for now", take the Pause instead option in that dialog, or switch Back up automatically off in the settings. Both keep every existing backup.
Deleting the archives cannot be undone.