Skip to content

Snapshots: backing up an app's data

Mesopod keeps your volumes when you stop or uninstall an app. That is not a backup. A backup is a copy somewhere else, and during alpha you make it yourself — this page is the whole procedure.

Do this before you trust an app with anything you would miss, and before every migration.

The script

scripts/snapshot.sh in this repo tars one directory into a timestamped archive:

snapshot.sh <data-dir> [dest-dir]

Copy it to the server — scp it, or paste it into a file and chmod +x. If you'd rather not, this is the same thing by hand:

sudo mkdir -p /backups
sudo tar czf /backups/photos-$(date +%Y%m%d-%H%M%S).tar.gz -C /srv/photos .

1. Stop the app first

In the console, open the app and press Stop. Wait for the status to read stopped.

This step is not optional for anything with a database. A running Postgres or SQLite writes constantly; a tar of its files taken mid-write is not a snapshot of anything, and you will only find that out on the day you restore it.

2. Find the directory

Host directory volumes — the console shows the directory on the volume itself (it is the path you typed when you created it). That is the path on the machine; nothing to look up.

Volumes Mesopod created — ask the cluster where they landed:

sudo k3s kubectl get pv \
  -o custom-columns=NAME:.metadata.name,PATH:.spec.local.path,NS:.spec.claimRef.namespace,CLAIM:.spec.claimRef.name

Each app runs in its own namespace, so the NS column tells you which rows are the app's. PATH is a real directory on the machine.

3. Take the snapshot

The destination has to exist first — neither the script nor tar will create it:

sudo mkdir -p /backups
sudo ./snapshot.sh /var/lib/rancher/k3s/storage/pvc-1234…_photos-ns_data /backups

It prints the file it wrote. Copy that file off the machine — a snapshot that lives only on the disk you are protecting against is not a backup. An external drive, another machine, or object storage: any of them, so long as it is not this one.

4. Start the app again

Press Start in the console. Check that it comes back to running before you walk away.

Restoring

  1. Stop the app in the console.
  2. Empty the volume's directory (sudo rm -rf <dir>/*, having double-checked <dir>).
  3. Untar the snapshot into it: sudo tar xzf photos-20260919-101500.tar.gz -C <dir>.
  4. Fix ownership if the app runs as a non-root user and your tar didn't preserve it: sudo chown -R <uid>:<gid> <dir>.
  5. Start the app.

Restoring into a different app instance works the same way: create the instance, stop it, replace the directory, start it.

Migrating an app onto Mesopod

The alpha rule, and it is not negotiable while we are this young:

  1. Snapshot the data on the old runtime before you move anything.
  2. Bring it into Mesopod as a host directory volume, or restore a snapshot into a Mesopod volume.
  3. Keep the old runtime startable — don't delete the old Compose file, its volumes, or the VM — until the beta gate. Every migration stays reversible by construction.

What this doesn't cover yet

Scheduled backups, off-site replication, and app-aware dumps (pg_dump and friends) are beta work. For now: a stopped app, a tar, and a copy somewhere else.