Backup and restore

A usable nia-todo backup must include more than the SQLite file. Runtime data also contains attachments, avatars, generated keys and instance-specific files.

Debian package backups

The full server package installs a daily systemd timer:

sudo systemctl status nia-todo-backup.timer
sudo systemctl start nia-todo-backup.service

Create a manual backup:

sudo nia-todo-backup

Backups are stored below /var/lib/nia-todo/backups by default.

Restore one:

sudo systemctl stop nia-todo
sudo nia-todo-restore /var/lib/nia-todo/backups/nia-todo-YYYYMMDD-HHMMSS.zip
sudo systemctl start nia-todo

The helper creates a consistent SQLite backup and includes runtime files while excluding the backup directory itself.

Docker backups

With a named volume, run the packaged helper inside the container:

docker compose exec nia-todo /app/scripts/nia-todo-backup.sh

Then copy the resulting archive out or back up the volume with your normal container backup tooling. A snapshot of a running SQLite volume is not automatically application-consistent; prefer the provided helper or stop the container before a filesystem-level copy.

What to protect

Back up the entire configured NIA_TODO_DATA_DIR. By default it contains:

• nia-todo.db
• attachments and avatars
• generated application and VAPID keys
• local runtime configuration and backups

Custom NIA_TODO_AVATAR_DIR, NIA_TODO_ATTACHMENT_DIR or NIA_TODO_VAPID_KEYS paths outside the main data directory are not automatically included by the packaged helper.

Migration

1. Create a backup on the old instance.
2. Stop writes to the old instance.
3. Install the same or newer nia-todo release on the target.
4. Restore the archive into the target data directory.
5. Start the target and verify users, attachments and configuration.
6. Change DNS or the reverse proxy only after verification.

Keep at least one copy outside the nia-todo host and test a restore periodically. A backup that has never been restored is mostly a motivational poster.