# Backup

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

Source: https://joinnasnet.com/en/guides/nasnet-linux/backup/
Last updated: 2026-08-14

---

## 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.

## Related

- [Settings](/en/guides/nasnet-linux/settings/)
- [Installation](/en/guides/nasnet-linux/install/)
- [Telegram bot](/en/guides/nasnet-linux/telegram-bot/)