Backing Up and Restoring App Data with neo backup

What a backup covers

neo backup snapshots an app's declared volumes — the data that survives a redeploy but not a lost disk, a fat-fingered docker volume rm, or a server that needs to be rebuilt from scratch.

neo backup my-app

Restoring

neo restore my-app <backup-id>

Works against the same server the backup came from, or a fresh one after neo init — useful for migrating an app to a new VPS, not just for disaster recovery on the original.

What backups don't replace

A volume backup is not a database backup strategy by itself if the app uses an external managed database rather than a container volume — that data was never in a Neo-managed volume to begin with, and needs its own backup plan (most managed database providers offer this natively). Where the database is a Neo volume (SQLite, or a bundled MySQL/Postgres from a template), neo backup covers it along with everything else.

A practical cadence

For anything with real user data, a scheduled backup (a cron job on your own machine or CI calling neo backup on a schedule) beats a manual "I should probably do this" — the value of a backup is entirely in it existing before you need it, and the only way to guarantee that is to stop relying on remembering.