Advice on Borg backup from Devuan (Debian) to Debian ZFS server

[NicholasFlamy]

Currently I have a server running Debian and its file system is ZFS. I'd like to set up a Borg backup server on there and set up a Borg backup client on my Devuan machine. Currently I have ext4 on Devuan. The backup is mainly so that I can easily restore the actual operating system and all my configs and apps. My actual data and documents are already going to be stored on the server.

Should I be worried about bitrot on ext4 (and switch filesystems)?

For the ZFS dataset where Borg backup will be storing things I know based on other discussions to disable compression and use 1M recordsize.
Should I disable snapshots? (Not sure how it behaves with changes. I don't want every backup to result in tons of space used by snapshots. I assume this is not the case because Borg appends so I should be fine with snapshots enabled.)

I'd prefer to disable encryption as well. It wasn't clear to me which one is the fastest with encryption disabled: #9104 (comment)

[VectorPeak]

The Devuan-to-Debian part should be pretty uneventful. Borg only really cares that both sides have a compatible Borg version and that the repository storage is reliable. ext4 on the client and ZFS on the server is a perfectly normal split.

On ext4 bitrot: ext4 will not detect or repair silent corruption the way ZFS can. That said, for an OS/config backup source, switching the client filesystem just for Borg is probably not the first thing I would do. Borg will faithfully back up whatever it reads; if a source file is already silently corrupted, Borg cannot know that from ext4 alone. The stronger practical protection is: store the repository on ZFS, scrub the pool regularly, run occasional borg check, and test restores. If the machine’s important user data already lives on the ZFS server, the remaining ext4 risk is mostly around the local OS/config state.

For the Borg repository dataset, recordsize=1M is a reasonable choice because Borg segment files are large and mostly written/read sequentially. Compression depends a bit on where you want compression to happen. If Borg compression is enabled, ZFS compression usually does little useful work and may just add overhead. If Borg compression is disabled and the repo is not encrypted, lz4 on ZFS can sometimes still be useful, but I would not expect it to be the main performance lever. The usual bigger factors are network speed, CPU hashing, compression choice, and disk latency.

Snapshots are fine, but the important detail is that Borg is not purely append-only forever. New backups add segment files, while prune/compact can delete or rewrite repository data. ZFS snapshots will keep those old blocks alive until the snapshots expire. That does not mean every backup doubles the repository, but frequent long-retention ZFS snapshots can absolutely retain space that Borg has already pruned or compacted away.

A practical setup is to keep ZFS snapshots enabled, but give them a modest retention policy and schedule them after Borg jobs rather than taking very frequent snapshots during active writes. They are useful protection against accidental repository deletion, bad prune commands, or client-side mistakes, especially if the Borg client user cannot delete the ZFS snapshots. Just don’t treat ZFS snapshots as free when the Borg repository is being compacted.

For encryption disabled, I would strongly prefer authenticated over none:

borg init --encryption=authenticated ssh://borg@server/./repo

authenticated does not encrypt the contents, but it still authenticates repository data. That protects you from accidental corruption and malicious tampering at the Borg layer. none removes that protection and is discouraged for new repositories; there is also active discussion around deprecating/removing it for Borg 2 except for migration paths. Even if none wins a microbenchmark, it is usually the wrong tradeoff for a long-lived backup repository.

If you want confidentiality disabled but still want a solid repo, use authenticated. If you want encryption but no passphrase prompt, use something like repokey/keyfile with an empty passphrase, understanding that this encrypts data at rest but the key protection is intentionally weak. For pure “fastest unencrypted mode”, benchmark on your hardware, but for a real backup setup I would not choose none just to save a small amount of CPU.

---

If my answer solved your problem, you can click answered the question. I'm really here to help, and along the way I'm also collecting Galaxy Brain badges haha 😆