Backup & restore

1. What a backup actually contains

Two things, either or both:

The database dump uses the engine's own tool (mysqldump, pg_dump, mongodump), so it is a normal dump you could restore by hand if you ever needed to.

What is not included: anything outside the document root. System packages, PHP or Node versions, web server configuration, cron jobs, SSL certificates and other applications on the same server are not part of an application backup.

2. Permissions

Without the permission the section is hidden entirely rather than disabled. Note that the delete button on a backup is not gated by either — anyone who can see the tab can delete a backup.

3. Manual Backup

Scope

Full is the right default. The two narrow options are for specific moments: Code Only before a deployment where the schema is not changing, Database Only before a data migration or a bulk edit.

Be careful with the asymmetry: restoring code without its database can leave an application running new code against old data, or the reverse. A Full backup gives you the option to restore either part later; a narrow one does not.

Backup Destination

A Local / Offsite switch.

Two things about this switch matter more than they look:

It saves the moment you flip it. There is no separate save button — the choice is stored on the application immediately, and it also governs where scheduled backups go. It is not just a setting for the next manual backup.

Offsite is a move, not a copy. Once the upload succeeds the server-side archive is removed, so an offsite backup exists in exactly one place. That is the point — a server that dies takes its local backups with it — but it also means restoring from offsite has to download first, and an offsite backup is only as reachable as the storage service.

When Offsite is selected:

The per-GB rate comes from your account's configured pricing and appears on your bill alongside other storage.

Backup Now

Starts the backup, showing Starting…, then:

The backup runs in the background. The response comes back immediately; the work continues on the server. You can leave the page.

4. Backup List

While anything is running, a Backup in progress… pill appears and the list refreshes itself every 5 seconds until nothing is in the creating state.

Local and Offsite tabs

The list is split by destination. The tab you land on defaults to the application's current destination, and a pulsing dot on either tab means a backup is being created there — so you see activity on the tab you are not looking at.

The table

Type badges:

Content badges: Full, Code, DB.

Status:

Restore is only offered on an Available backup. Delete is always offered.

Empty states are specific: No backups yet. Click "Backup Now" to create the first one. on a fresh application, and No Local backups yet / No Offsite backups yet when the other tab has them.

Retention — only 5, and pre-restore backups count

All types count toward the five, including the automatic Pre-Restore snapshots. That has a consequence worth internalising:

When a backup is pruned, its files are removed from the server and its offsite objects are deleted. Pruning is not a database-only cleanup.

If you need a snapshot to survive beyond five, take it out of the rotation — restore it somewhere, or export the data — rather than assuming it will still be there next week.

5. Auto-Backup Schedule

Frequency

Time

Hour, Minute and AM/PM selectors, with a timezone shown beside them.

Weekly adds a Day of Week selector.

Next backup available

The heading shows when the next run is due — the schedule name for Daily and Weekly, and a specific date for the longer intervals, calculated from the most recent backup plus the interval.

Saving

Save Schedule is disabled until something changes, and opens a confirmation listing exactly what you are about to set:

Confirming reports Auto-backup set to: Weekly on monday at 02:00.

Scheduled backups use the scope Full and the application's current destination.

6. Restoring

The restore icon on an Available backup opens Confirm Restore, showing the snapshot's name, date and size.

What to restore

Only a Full backup offers a choice — Full, Code Only or Database Only. A Code-only or Database-only backup restores exactly what it contains.

This is the most useful capability in the tab: a Full backup lets you undo a bad deployment without touching the database, or roll the data back without reverting code.

The warning is accurate

Both halves are true and both matter.

The safety backup is real, and it is always a full snapshot — files and database — even if you are restoring only one of them. It inherits the destination of the backup you are restoring, and if an offsite upload of it fails, it is kept locally rather than being lost. It appears in the list as Pre-Restore, and it is your way back if the restore was a mistake.

The restore itself is destructive, and specifically:

The .env point deserves emphasis: a restore replaces your environment file with the one from the snapshot. If you changed database credentials, API keys or an APP_URL since then, those changes are reverted along with everything else. Check the file after any restore.

An offsite backup is downloaded back to the server first, restored from there, and the temporary copy cleaned up afterwards — so an offsite restore takes longer than a local one, proportional to the snapshot's size.

Starting a restore reports:

It then runs in the background, and the list polls until it settles.

7. Deleting a backup

Confirmed with Delete Permanently. The archives are removed from the server and, for an offsite backup, from object storage too.

8. Sensible practice

• Back up before you change anything — a deployment, a plugin update, a schema migration, a bulk data edit. A manual Full backup takes seconds to start.
• Use Offsite for anything you would miss. A local backup does not survive the server it sits on.
• Prefer Weekly over the longer intervals until 14 Days and Monthly behave as labelled.
• Set your profile timezone, or your schedule fires at an hour you did not intend.
• Check .env after every restore.
• Remember the limit of five, and that restores consume slots. Do not treat this as long-term archival.
• Test a restore before you need one. A backup you have never restored is an assumption, not a safety net — and the pre-restore snapshot means testing is reversible.
• Take a Full backup rather than a narrow one when you are unsure. You can always restore part of it later; you cannot restore a part you never captured.

9. Common problems

10. How this relates to other places

The division worth remembering: a server backup protects the machine, this protects the application. They are not substitutes — restoring a whole server to undo one bad deployment is a much larger operation than restoring one application.