Backup & restore

Percher backs up the entire platform every night to encrypted off-site storage. The goal is that a corrupted database, a deleted volume, or a lost server does not turn into lost user data — restores happen from yesterday's archive, not from scratch.

• Every app's /app/data volume (your databases, uploaded files, SQLite, caches)
• Every PocketBase sidecar's pb_data directory (auth, collections, file uploads)
• Platform metadata (apps, users, deployments, env-var ciphertext, custom-domain config)
• Forgejo repositories — the deploy history we keep of every published version
• Caddy TLS certificates so HTTPS keeps working immediately after a restore

• Daily, 02:00 UTC
• Encrypted with AES-256 (GPG symmetric)
• Uploaded to encrypted off-site storage in a different EU datacenter from the production server, so a region failure doesn't take both copies
• Retention: 30 days off-site. Recent nightly copies also stay on the production server; under disk pressure, older verified copies move off-site while at least three recent nightly generations stay local.
• If a backup fails, on-call gets a Discord ping and an operations email within minutes

Self-service from the CLI. A local MCP assistant can use percher_backups and percher_restore. The hosted connector can list backups but cannot restore them. For running PocketBase apps, the dashboard also offers restore under Data → Backups.

bunx percher backups <app>                    # what you can restore from
bunx percher restore latest <app> --dry-run   # see the plan first
bunx percher restore latest <app>             # or YYYY-MM-DD / a backup id
bunx percher restore latest <app> --components pocketbase

Older archives held only off-site require support to bring the selected copy back for restore. For anything the CLI can't reach — a deleted app, a cross-account copy — open a dashboard support case with the app name, what was lost, and roughly when.

During the beta, for ordinary support, please share App Data (logs, files, database content, diagnostics) only through a dashboard support case; describe it or attach screenshots there. General questions may be emailed to support@percher.app; the abuse@, security@ and legal@ reporting channels are unchanged.

• Writes since the last successful backup (up to ~24 hours if the latest scheduled backup completed; longer if it failed)
• Application-level corruption that you replicated into a backup — if your code wrote bad rows for three days, the restore will faithfully bring those rows back too
• Loss older than the 30-day retention window — once an archive ages out of both local and off-site storage, it's gone

Note: bunx percher delete queues app deletion and skips any extra snapshot. A retained successful archive may contain the app metadata and saved data components. If you delete by accident, open a dashboard support case within the 30-day retention window for available recovery options. Recovery depends on a retained successful archive and is not guaranteed.

For sub-daily protection or self-service exports, run your own dump from inside the app — for PocketBase apps that's the built-in/api/backups endpoint in the PB admin UI. For custom SQLite, use its online backup API or VACUUM INTO for a consistent live snapshot. Do not copy only an active main file: committed writes may remain in its WAL.

With the SQLite CLI installed, replace the paths with your database and snapshot destination:

sqlite3 /app/data/app.db ".backup /app/data/app-snapshot.db"

Copy the completed snapshot to protected off-site storage.