this post was submitted on 25 May 2026
35 points (94.9% liked)

Selfhosted

60093 readers
859 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam.

  3. Posts here are to be centered around self-hosting. Please ensure it is clear in your post how it relates to self-hosting.

  4. Don't duplicate the full text of your blog or git here. Just post the link for folks to click.

  5. Submission headline should match the article title.

  6. No trolling.

  7. Promotion posts require your active participation in selfhosting or related communities, or the post will be removed. No more than 10% of your posts or comments may be self-promotional, or your post will be removed. F/LOSS Exception: If your post is about a project that is completely open source & can be self-hosted in full without payment, your post is exempt from this rule as long as you continue to engage in comments.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 3 years ago
MODERATORS
 

I currently have a secondary pool (with raidz2) that I was originally going to use for my important documents, such as storage for Paperless-ngx, as raidz offers corruption detection and repair. The pool is encrypted.

However, I'm concerned about rebuild times (it's a pool of 4 22TB drives). Is btrfs a better choice for this use case, or should I just go with raidz like I originally planned?

Edit: I should have mentioned that I already have 4-3-2 backups configured - I'm primarily interested in the "self-healing" aspect of ZFS so that I don't have to recover from backups unless necessary, and to resolve corruption on the fly without me having to notice that a file is corrupt.

you are viewing a single comment's thread
view the rest of the comments
[โ€“] tychosmoose@piefed.social 3 points 1 month ago (1 children)

For your situation I would be more likely to go with a single drive with btrfs and dup for metadata redundancy. Regular snapshots and scrubs.

Use a second drive in the same system with btrfs to store snapshots at wider scheduled intervals. These will be bigger since no CoW on the separate file system. Scheduled scrub here too.

Use a third drive with ext4 as a backup target using a separate backup mechanism.

Use the fourth drive as a spare, or in a separate location as a target to send the backups if you don't already have an off-site solution.

Interesting idea.