Skip to main content

​
Backups

DNZ backs itself up: Settings → Backups makes scheduled, optionally encrypted archives of the whole install (zones, users, settings, DNSSEC keys, certificates, the GeoIP database) to a folder, S3-compatible storage or SFTP, keeps N daily, weekly and monthly ones, and restores them onto any database, even a new install from its first-run page. See Backups and restore. The database’s own tools work too. With SQLite, the default, all of DNZ’s data is in one file: Take a consistent copy while DNZ runs with SQLite’s .backup:
Don’t just copy dnz.db while DNZ runs: recent changes may still be in dnz.db-wal. Use .backup, or stop DNZ first.
With Postgres or MySQL, use their own tools (pg_dump, mysqldump). See Database. To restore such a copy, stop DNZ, put it back in place of the database (for SQLite, remove any dnz.db-wal and dnz.db-shm next to it), then start DNZ again.

​
Updates

Copy the new binary out of the new image, replace it and restart:
Database migrations run automatically at startup. Take a backup before updating, so you can go back. If you run dnz-proxy nodes, update them together with DNZ, to the same version. With Docker, pull the same tag of terrificci/dnz-proxy on each node (docker compose pull && docker compose up -d); with the binary, run the install script again.