Database inside a VM? Dump it before the backup
Your VM backup has a database inside. The trap is trusting the VM backup alone for an application with a database.
Your VM backup has a database inside. The trap is trusting the VM backup alone for an application with a database. The backup captures the state of the VM's disk at a moment in time. With the guest agent installed, snapshot mode flushes the filesystem, which is usually enough. Usually is not a word the book likes in a backup chapter.
The book covers this under the heading "Backing Up the Things Proxmox Can't See." A whole-VM backup of Home Assistant is a perfect copy of the VM. It is also 32 GB to move around when all you wanted was yesterday's automations, and it does not help when you want to move Home Assistant to a different machine entirely. The same goes for OPNsense: the VM is replaceable, the config is not. And inside your Docker guests there are databases that do not like being copied mid-write. Each of these wants its own, smaller, application-level backup on top of the VM backup.
The trap: trusting the snapshot
The trap is the belief that a Proxmox snapshot captures a consistent state. The book notes that the guest agent installed on the VM flushes the filesystem, which is usually enough. Usually is not enough when a database is mid-write. A transaction can be half-applied to the log files, leading to corruption on restore. The fix is to run a database dump a few minutes before the Proxmox backup so the VM backup contains a consistent copy even if the live files were mid-write.
The fix: dump the database before the backup
For any guest running Postgres, MariaDB or SQLite under Docker, add a dump to the inventory. The dump runs a few minutes before the Proxmox backup, lands on the guest's disk, and gets picked up by the backup like any other file. The VM backup then contains a consistent dump even if the live database files were mid-write.
Immich's own documentation gives the exact command, and it is the one the book recommends:
docker exec -t immich_postgres \ pg_dumpall --clean --if-exists --username=postgres \ | zstd > /srv/backup/immich-db-$(date +%F).sql.zst
find /srv/backup -name 'immich-db-*' -mtime +14 -delete
For Vaultwarden, stop the container or use SQLite's own .backup command against the live file; a plain cp of a busy SQLite database can land between pages. For Nextcloud, turn on maintenance mode, dump the database, turn it off. All three are a few lines in a script on a systemd timer at 02:00, half an hour ahead of the 02:30 backup job.
The fix: backup the firewall config separately
OPNsense keeps its entire state in one file, /conf/config.xml, and it offers to back that file up for you. System, then Configuration, then Backups. Download gives you the file now. Tick Encrypt this configuration file and set a password; the file contains every secret the firewall knows, including VPN keys and the admin password hash.
Google Drive and Nextcloud backup are built in on that same page: the firewall uploads the config whenever it changes. Nextcloud is the better fit if you self-host it (the book covers the setup); a dedicated Nextcloud user with one shared folder is enough. The os-git-backup plugin pushes every configuration change as a commit to a Git repository you host. Every change becomes a diff you can read, which is worth more than it sounds when a rule you do not remember writing starts blocking something.
You also keep OPNsense in the weekly vzdump job. A restore from the VM backup is the quickest way back if the VM breaks. A restore from config.xml onto a fresh install is the way back if the hardware changes: install OPNsense, assign the interfaces, then System, then Configuration, then Backups, then Restore. The one thing to know in advance is interface names. A new VM with different NIC order will not match vtnet0 and vtnet1 in the file, and you will reassign interfaces at the console before the GUI comes back.
The fix: back up the host config
The nodes are the one thing nothing above protects. /etc/pve holds every guest config, the storage definitions, the backup jobs, user accounts and the cluster configuration; /etc/network/interfaces holds the bridges and VLANs that took an afternoon to get right. Chapter 3 shows the proxmox-backup-client command that sends both to PBS nightly. If you are not running PBS, a tarball to the NAS does the job:
tar czf /mnt/pve/nas-backup/host-$(hostname)-$(date +%F).tgz \ /etc/pve /etc/network/interfaces /etc/hosts /etc/vzdump.conf /etc/apt
Add the output of pvesm status, zpool status and lsblk -f to a text file next to it. On a rebuild, those three listings answer every "what was that storage called?" question.
Checklist: beyond Proxmox
☐ Home Assistant automatic daily backups on, encrypted, emergency kit saved ☐ HA backups going to at least one location other than its own disk (NAS or B2) ☐ OPNsense config.xml backed up on change to Nextcloud, Google Drive or Git, plus an encrypted download after big changes ☐ A database dump before the backup window for every guest with a database ☐ The nodes' /etc/pve and network config backed up nightly ☐ A text file of storage, pool and disk layouts kept with the host backup
