snapraid VS Rdiff-backup

Would mergerfs and snapraid work for you? You'd sacrifice a disk to parity and run the parity calc manually, but you could set up a cron job for that.

Like most people on r/homelab, it started out with Plex. Rough timeline/services below:

0. Got a Synology DS413 with 4x WD Red 3TB drives. Use Playstation Media Server to stream videos from it. Eventually find some Busybox stuff to add various functionality to the NAS, but it had a habit of undoing them periodically, which was frustrating. I also experienced my first and (knock on wood) only drive failure during this time, which concluded without fanfare once the faulty drive was replaced, and the array repaired itself.

1. While teaching self Python as an Electrical Distribution Engineer at a utility, I befriended the IT head, who gave me an ancient (I think Nehalem? Quad-core Xeon) Dell T310. Promptly got more drives, totaling 7, and tried various OS / NAS platforms. I had OpenMediaVault for a while, but got tired of the UI fighting me when I knew how to do things in shell, so I switched to Debian (which it's based on anyway). Moved to MergerFS [0] + SnapRAID [1] for storage management, and Plex for media. I was also tinkering with various Linux stuff on it constantly.

1.1 Got tired of my tinkering breaking things and requiring troubleshooting/fixing (in retrospect, this provided excellent learning), so I installed Proxmox, reinstalled Debian, and made a golden image with everything set up as desired so I could easily revert.

1.2 A friend told me about Docker. I promptly moved Plex over to it, and probably around this time also got the *Arr Stack [2] going.

2. Got a Supermicro X9DRi-LN4F+ in a 2U chassis w/ 12x 3.5" bays. Got faster/bigger CPUs (E5-2680v2), more RAM, more drives, etc. Shifted container management to Docker Compose. Modded the BIOS to allow it to boot from a NVMe drive on a PCIe adapter.

2.1 Shifted to ZFS on Debian. Other than DKMS occasionally losing its mind during kernel upgrades, this worked well.

2.2 Forked [3] some [4] Packer/Ansible projects to suit my needs, made a VM for everything. NAS, Dev, Webserver, Docker host, etc. Other than outgrowing (IMO) MergerFS/SnapRAID, honestly at this point I could have easily stopped, and could to this day revert back to this setup. It was dead reliable and worked extremely well. IIRC I was also playing with Terraform at this time.

2.3 Successfully broke into tech (Associate SRE) as a mid-career shift, due largely (according to the hiring manager) to what I had done with my homelab. Hooray for hobbies paying off.

3. Got a single Dell R620. I think the idea was to install either pfSense or VyOS on it, but that never came to fruition. Networking was from a Unifi USG (their tiny router + firewall + switch) and 8-port switch, with some AC Pro APs.

4. Got two more R620s. Kubernetes all the things. Each one runs Proxmox in a 3-node cluster with two VMs - a control plane, and worker.

4.0.1 Perhaps worth noting here that I thoroughly tested my migration plan via spinning up some VMs in, IIRC, Digital Ocean that mimicked my home setup. I successfully ran it twice, which was good enough for me.

4.1 Played with Ceph via Rook, but a. disliked (and still to this day) running storage for everything out of K8s b. kept getting clock skew between nodes. Someone on Reddit mentioned it was my low-power C-state settings, but since that was saving me something like ~50 watts/node, I didn't want to deal with the higher power/heat. I landed on Longhorn [5] for cluster storage (i.e. anything that wasn't being handled by the ZFS pool), which was fine, but slow. SATA SSDs (used Intel enterprise drives with PLP, if you're wondering) over GBe aren't super fast, but they should be able to exceed 30 MBps.

4.1.1 Again, worth noting that I spent literally a week poring over every bit of Ceph documentation I could find, from the Red Hat stuff to random Wikis and blog posts. It's not something you just jump into, IMO, and most of the horror stories I read boiled down to "you didn't follow the recommended practices."

5. Got a newer Supermicro, an X11SSH-F, thinking that it would save power consumption over the older dual-socket I had for the NAS. It turned out to not make a big difference. For some reason I don't recall, I had a second X9DRi-LN4F+ mobo, so I sold the other one with the faster CPUs, bought some cheaper CPUs for the other one, and bought more drives for it. It's now a backup target that boots up daily to ingest ZFS snapshots. I have 100% on-site backups for everything. Important things (i.e. anything that I can't get from a torrent) are also off-site.

6. Got some Samsung PM863 NVMe SSDs mounted on PCIe adapters for the Dells, and set up Ceph, but this time handled by Proxmox. It's dead easy, and for whatever reason isn't troubled by the same clock skew issues as I had previously. Still in the process of shifting cluster storage from Longhorn, but I have been successfully using Ceph block storage as fast (1 GBe, anyway - a 10G switch is on the horizon) storage for databases.

So specifically, you asked what I do with the hardware. What I do, as far as my family is concerned, is block ads and serve media. On a more useful level, I try things out related to my job, most recently database-related (I moved from SRE to DBRE a year ago). I have MySQL and Postgres running, and am constantly playing with them. Can you actually do a live buffer pool resize in MySQL? (yes) Is XFS actually faster than ext4 for large DROP TABLE operations? (yes, but not by much) Is it faster to shut down a MySQL server and roll back to a previous ZFS snapshot than to rollback a big transaction? (often yes, although obviously a full shutdown has its own problems) Does Postgres suffer from the same write performance issue as MySQL with random PKs like UUIDv4, despite not clustering by default? (yes, but not to the same extent - still enough to matter, and you should use UUIDv7 if you absolutely need them)

I legitimately love this stuff. I could quite easily make do without a fancy enclosed rack and multiple servers, but I like them, so I have them. The fact that it tends to help my professional growth out at the same time is a bonus.

[0]: https://github.com/trapexit/mergerfs

[1]: https://www.snapraid.it

[2]: https://wiki.servarr.com

[3]: https://github.com/stephanGarland/packer-proxmox-templates

[4]: https://github.com/stephanGarland/ansible-initial-server

[5]: https://longhorn.io

If you are using OpenMediaVault, checkout SnapRaid plugin.

I used drivepool for years with snapraid before I switched over to unraid. Nothing but good things to say about either program. Highly recommend both.

You can always use SnapRAID . there is no user interface, it is CLI. also you have to sync it manually. or set up a cronjob. you loose a hdd like unRaid or RAID5 but it gives you parity. then you could always use duplicati and backblaze business to make backups. it isnt as expensive as you would think for a homelab. the first back up might be a little much but then its pennies after that

As for the drives I'm thinking of grabbing a few from ServerPartDeals and upgrading my setup that uses DrivePool and snapRAID, but in Linux you would use mergerfs instead of DrivePool.

I myself prescribe to the teachings of the IronicBadger(Alex Kretzshmar) from the Self-Hosted podcast and (when I get one setup) intend to follow the guides on his site https://perfectmediaserver.com and use mergerfs to turn a JBOD to a single filesystem and use SnapRAID for redundancy.

I have that exact Sabrent 5 bay enclosure and I replaced it with this Orico 5 bay enclosure because the Sabrent's connection would fail while I ran snapraid sync, but the Orico has never failed me.

With two drives? Just run them as-is. Once you get a third disk, set up https://www.snapraid.it. Then as you add more, just follow https://www.snapraid.it/faq#howmanypar to have the correct number of parity disks. Or don't, Plex content is probably easy to re-acquire if you need to so having redundancy or a backup isn't all that important.

For starters it has a tendency to paint itself into a corner on ENOSPC situations. You won't even be able to perform a restore if a backup was started but unfinished because it ran out of space. There's this process of "regressing" the repo [0] which must occur before you can do practically anything after an interrupted/failed backup. What this actually must do is undo the partial forward progress, by performing what's effectively a restore of the files that got pushed into the future relative to the rest of the repository, which requires more space. Unless you have/can create free space to do these things, it can become wedged... and if it's a dedicated backup system where you've intentionally filled disks up with restore points, you can find yourself having to throw out backups just to make things functional again - even ability to restore is affected.

That's the most obvious glaring problem, beyond that it's just kind of garbage in terms of the amount of space and time it requires to perform restores. Especially restores of files having many reverse-differential increments leading back to the desired restore point. It can require 2X the file's size in spare space to assemble the desired version, while it iteratively reconstructs all the intermediate versions in arriving at the desired version. Unless someone fixed this since I last had to deal with it, which is possible.

Source: Ages ago I worked for a startup[1] that shipped a backup appliance originally implemented by contractors using rdiff-backup. Writing a replacement that didn't suck but was compatible with rdiff-backup's repos consumed several years of my life...

There are far better options in 2024.

[0] https://github.com/rdiff-backup/rdiff-backup/blob/master/src...

[1] https://www.crunchbase.com/organization/axcient

and that should install the latest version, rdiff-backup-2.2.4-2.el8.x86_64.rpm. This is all described in the rdiff-backup README file.

Rdiff-backup - close to what you do currently but at least provides versioning. Based on rsync

as in just a copy of your files? This I would barely consider a backup, more of just a mirror from a point in time. What're you missing by doing this? versions of files, deduplication, and encryption (last one being very important for the best kind of backups, which should be off-site). Just because it's not files doesn't mean it's proprietary. Proprietary would mean secret and undocumented. There are many great options. Borg is my favorite but Kopia is probably better if you use windows, urbackup is an option if you want centralized management of backups and rdiff-backup is if you want something kinda what you have currently but adding versioning but lacks deduplication and encryption.

If you're comfortable with the cli and you want to have your backup in a plain file format with some incremental backups, there's rdiffbackup. It uses rsync under the hood and has worked quite well for me.

Rdiff Backup - Reverse differential backups that uses rsync, linking, and can tunnel via ssh. You get a full current backup with increments available to restore any version of the file with minimal storage space used.

borg is great. we've been using it for the past 3 years to archive hundreds of file-level backups of servers, database dumps and VM images. average size of each borg repo is few GB but there are few outliers up to few hundreds of GB.

borg replaced https://rdiff-backup.net/ for us and gave:

Robocopy is great if you don't have access to rsync. If rsync via WSL2 for instance is an option, I'd personally go with rdiffbackup.