Backup

Create, download and restore database backups, plus the one thing to do before every upgrade.

Last updated Aug 14, 2026View as Markdown

Overview

Everything Nasnet Linux knows, from users and subscriptions to accounts, settings and the audit trail, lives in one database, so a database backup is a backup of the whole deployment. The Backup page creates them, lists them, downloads them and restores them, for both PostgreSQL and SQLite. Schema migrations run automatically on startup, which is exactly why you take a backup before every upgrade.

Before you start

  • Backups are written to BACKUP_DIR, which defaults to ./data/backups and is a bind mount under Docker. Make sure it is part of your host-level backup routine, along with the database volume.
  • Restoring replaces all data. It is not additive and it is not reversible.
  • The Telegram bot can also trigger a backup with an admin command.

Steps

  1. Open Backup from the sidebar.
  2. Create a backup. It appears in the table with its filename, size and creation time.
  3. Download it and move the copy off the server, because a backup that only exists on the machine you are protecting is not a backup.
  4. To restore, choose Restore this backup on a row, or upload a backup file.
  5. Confirm the destructive-action dialog by typing RESTORE into the confirmation box.
  6. Restart the server afterwards. The page says so explicitly: a restore is only fully applied after a restart.

Reference

Column What it shows
Filename The backup file’s name.
Size How large it is.
Created When it was taken.
Actions Restore this backup, Download, Delete.

For SQLite, a restore swaps the database file and the process restarts. Because a restored database may carry deployment-specific settings such as URLs, ports and tokens from a different server, the panel drops a reseed marker and, on the next start, re-applies your local environment settings over the restored values. Your current .env wins for deployment-specific keys, so a restored backup cannot point your panel at somebody else’s URL.

For PostgreSQL, restore into the database the panel connects to using the standard pg_restore or psql workflow against the nasnet_panel database, then restart the panel.

Troubleshooting

After a restore, admin sign-in or the base URL looks wrong. Verify APP_BASE_URL and your admin credentials, since both are deployment-specific and worth re-checking on the first start after any restore.