Back up an app, and prove the restore works
An untested backup is a guess. This walks through backing up one app, deliberately breaking it, restoring, and confirming the data came back.
Time: ~20 minutes · You’ll need: one installed app with some data in it
Do this on an app you can afford to lose — the restore step erases the app’s current data before replacing it. Pick something you installed to experiment with, not your only copy of anything.
What you’ll have at the end
- A backup archive on disk you can point at
- First-hand proof the restore path works
- A sense of how long it takes, before you need it under pressure
What Hub’s backup actually captures
Per app, Hub archives three things into a single .tar.gz:
| Included | What it is |
|---|---|
app-data/ | The app’s persistent data directory — its database, uploads, and state |
app/ | The installed app definition (compose file, config) |
user-config/ | Your overrides for that app, when you have any |
Nested backups directories are excluded, so backups don’t accumulate inside each other.
Backups land on the same disk as the data they protect, under
<ROOT_FOLDER_HOST>/backups/<app-store>/<app-name>/. That covers a bad update
or a mistaken change. It does not cover the disk failing. For that, copy
archives somewhere else — see Backup and
restore for whole-machine migration.
Put something recognisable in the app
Open the app and create something you’ll recognise later — a document, a note, an uploaded photo. You need a specific thing to look for, not a vague sense that it “looks right.”
Take the backup
On the app’s page in the dashboard, open the backups panel and choose Backup now.
Hub copies the app’s data, config, and any user overrides into a temporary directory, creates a .tar.gz, and moves it into the app’s backup folder. Larger apps take longer — it is a real copy, not a snapshot.
Confirm the archive exists
The Backups list shows each archive with its ID, Date, and Size.
You can also see it on disk:
ls -lh <ROOT_FOLDER_HOST>/backups/<app-store>/<app-name>/Archives are named <app-urn>-<timestamp>.tar.gz. A size of a few hundred bytes means it captured nothing — check the app actually had data before you trust it.
Break something on purpose
This is the part that makes it a drill instead of a ritual.
Go back into the app and delete the thing you created in step 1. Confirm it is really gone from the app’s own interface.
Restore
In the backups list, choose Restore on the archive you made.
Hub warns you that all current data for the app will be erased and replaced with the backup’s contents. That is exactly what you want here — accept it.
Verify
Open the app again and look for the specific thing you deleted.
- It’s back — your backup and restore path both work.
- It’s not back — the archive didn’t contain what you assumed. Better to find that out now.
Retention
By default Hub keeps every backup: MAX_BACKUPS defaults to 0, which means unlimited. On a busy app that grows without bound.
You can cap it globally, or per app at install time — the install form has an App backup limit field, where empty means “use the global setting” and 0 means unlimited. Values run from 0 to 100.
Hub also offers to back up an app before updating it, in the update flow. Leave that on; it is the cheapest insurance available.
Moving archives off the machine
The backups panel lets you download an archive to whatever device you’re using, and upload a .tar.gz back to an app later. That upload-and-restore path is what makes a backup useful after a disk dies — the archive has to already be somewhere else.
For scheduled copies, see Auto backup your apps using cron.
Next
- Backup and restore — moving a whole Hub to new hardware
- Auto backup your apps using cron — scheduling this
- Backup & Restore — the feature reference