TrueCloud Backup: support backing up from ZFS snapshots instead of live datasets

Feature Requests
1

TrueCloud Backup currently backs up the live dataset. When the source dataset contains child datasets with actively running applications — particularly databases (Postgres, MySQL, MongoDB) — the backup has two serious problems:

  1. Correctness — live database files (WAL, data pages) are in a constantly changing state. While ZFS snapshots are consistent, the live filesystem is not a safe backup source for databases.

  2. Performance — restic re-chunks and re-uploads large portions of database files on every run because they change between backups, even if the logical data change is small. This makes backups extremely slow.

The correct approach is to back up from a ZFS snapshot, which is a frozen, consistent point-in-time view of the data. TrueNAS already creates periodic ZFS snapshots — these should be usable as the backup source for TrueCloud.

My specific setup (concrete example):

I have a ZFS pool with the following structure:

AppsVmsPool/appdata ← parent dataset
AppsVmsPool/appdata/berriai-postgres ← child dataset (Postgres DB)
AppsVmsPool/appdata/immich-postgres ← child dataset (Postgres DB)
AppsVmsPool/appdata/homeassistant ← child dataset (app data)
AppsVmsPool/appdata/gitea ← child dataset (app data)

Each child dataset is a Docker container volume, managed via individual docker-compose stacks. Several of these are live databases (Postgres, MongoDB, MySQL) with actively written WAL files.

TrueNAS runs a recursive periodic snapshot of AppsVmsPool/appdata daily. Because the snapshot is recursive and atomic, all 65 child datasets are snapshotted simultaneously — this is consistent and safe.

The TrueCloud Backup task is pointed at /mnt/AppsVmsPool/appdata.

What TrueCloud actually backs up:

  • :white_check_mark: The live contents of each child dataset — but these include constantly mutating database files, causing restic to re-upload large chunks on every run

  • :cross_mark: The .zfs/snapshot/ contents of child datasets — restic stops at the ZFS filesystem boundary and does not recurse into child dataset snapshots

What should happen:

TrueCloud should be able to back up from /mnt/AppsVmsPool/appdata/berriai-postgres/.zfs/snapshot/latest/, /mnt/AppsVmsPool/appdata/immich-postgres/.zfs/snapshot/latest/ etc. — i.e. each child dataset’s frozen snapshot path individually — rather than the live filesystem.

2

My 2p worth

The issue with what you are saying is that a snapshot, in particular of a database, isn’t nessesarily consistent either. You need something to freeze the database - which generally has to be done from inside, and not outside.

For something like a container (docker) then I would suggest doing a docker stop, followed by a backup, followed by a docker run (or whatever the commands are). Do these as part of the pre and post script in the task.

3

Using a snapshot as a reference for a backup is not a guarantee for consistency, but form an excellent baseline for creating a consistent backup. Since the sysadmin will know when the snapshot will be taken, relevant services can be put in a consistent state by scheduled tasks beforehand.