Zfsbackrest: Pgbackrest Style Encrypted Backups for Zfs Filesystems
Posted4 months agoActive4 months ago
github.comTechstory
calmmixed
Debate
40/100
ZfsBackupDatabase
Key topics
Zfs
Backup
Database
The post introduces zfsbackrest, a tool for encrypted backups of ZFS filesystems, sparking discussion on its design and potential issues with storing ZFS send streams.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
2h
Peak period
4
3-6h
Avg / period
2
Comment distribution12 data points
Loading chart...
Based on 12 loaded comments
Key moments
- 01Story posted
Sep 1, 2025 at 9:35 AM EDT
4 months ago
Step 01 - 02First comment
Sep 1, 2025 at 11:50 AM EDT
2h after posting
Step 02 - 03Peak activity
4 comments in 3-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 3, 2025 at 6:53 AM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45092605Type: storyLast synced: 11/20/2025, 4:44:33 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
It was a major pain point for my backups for years.
They create a new file with the diffs of a bundle of Postgres files, and upload that to blob storage.
For example, tools like Plakar (contributor here) split data into smaller immutable chunks and only store the modified ones, avoiding full re-uploads of 1GB files when only a few bytes change.
> Incremental ZFS send streams do not have any of these properties and full ZFS send streams only have a few of them. Neither full nor incremental streams have any resilience against damage to the stream; a stream is either entirely intact or it's useless. Neither has selective restores or readily available indexes. Incremental streams are completely useless without everything they're based on. All of these issues will sooner or later cause you pain if you use ZFS streams as a backup format.
https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSSendNotA...
However ZFS replication was originally designed with the assumption and use case in mind that organizations would store the send streams as opaque blobs on tape. This is, in part, why storing send streams as blobs is still a thing people do.
There are some use cases where this makes sense. I’ve stored full send streams of archived ZFS file systems in S3(-compatible services) where integrity is handled at the platform level. In that use case I didn’t benefit from having every copy of the filesystem in question running on live storage media, and incremental sends/snapshots weren’t on the table. (I also SHA checksummed the resulting files, and did restore tests.)
There is also a misconception that frequently gets brought up in the ZFS community that the send stream format isn’t stable between versions and cannot be relied upon in future, but it absolutely is stable. In fact the ZoL manpage for send explicitly states that it is. As with anything in ZFS though, you want to move versions forward or not at all, rather than backward.