I personally think of a small DIY rack stuffed with commodity HDDs off Ebay with an LVM spanned across a bunch of RAID1s. I don’t want any complex architectural solutions since my homelab’s scale always equals 1. To my current understanding this has little to no obvious drawbacks. What do you think?
Hot take: For personal use, I see no value at all in “availability,” only data preservation. If a drive fails catastrophically and I lose a day waiting for a restore from backups, no one is going to fire me. No one is going to be held up in their job. It’s not enterprise.
However, redundancy doesn’t save you when a file is deleted, corrupted, ransom-wared or whatever. Your raid mirror will just copy the problem instantly. Snapshots and 3,2,1 backups are what are important to me because when personal data is lost, it’s lost forever.
I really do think a lot of hobbyists need to focus less on highly available redundancy and more on real backups. Both time and money are better spent on that.
A single ssd with whatever formatting came with it, along with a webdav frontend I made myself. Very high security (confidentiality) actually, since I check for client side cert, user auth, biometrics (that’s plural), behavior recognition through a custom typing website and hardware token, but the integrity could use some help. And I’m painfully aware that someone could just steal my session.
I love security.
You’ll never get my duck nudes.In reality I just had a fun night
Shit I forgot to install a firewall.
No worries, I installed it for you.
Pfew, close one.
Wait a minute.
Why always scale to 1?
I set up garage, which works fine.
Advantage of an s3 style layer is it’s simplicity and integration with apps.
I also use it so I can run AI agents that have zero access to a disk based system
Just btrfs.
Why btrfs and not ZFS? In my info bubble, the btrfs has a reputation of an unstable FS and people ended up with unrecoverable data.
Just the 5-6 raid modes are shit. And its weird willingness to let you boot a failed raid without letting you know a drive is borked.
That is apparently not the case anymore, but ZFS is certainly more rich in features and more battle-tested.
This has been my journey.
I started with pure docker and hostpath on an Ubuntu server. This worked well for me for many years and is good for most people.
Later I really wanted to learn k8s so I built a 3 node cluster with NSF managed PVC for storage, this was fantastic for learning. I enjoyed this for 3 plus years. This is all on top of proxmox and zfs
About 8 months ago I decided I’m done with my k8s learning and I wanted more simplicity in my life. I created a lxc docker and slowly migrated all my workloads back to docker and hostpath, this time backed by my mirrored zfs files system.
I guess my point is what are you hoping to get out of your journey and then tailor your solution to that.
Also I do recommend using proxmox and zfs.
I have a few Ext4 drives connected and I mount them in /etc/fstab and that’s it.
I’ve yet to find a reason to change it.
You can use OpenEBS to provision and manage LVM volumes. Host path requires you to manually manage the host paths.
You need to ask yourself what properties you want in your storage, then you can judge which solution fits. For me it is:
- effortless rollback (i.e. in case something with a db updates, does a db migration and fails)
- effortless backups, that preserve database integrity without slow/cumbersome/downtime-inducing crutches like sql dump
- a scheme that works the same way for every service I host, no tailored solutions for individual services/containers
- low maintenance
The amount of data I’m handling fits on larger harddrives (so I don’t need pools), but I don’t want to waste storage space. And my homeserver is not my learn and break stuff environment anymore, but rather just needs to work.
I went with btrfs raid 1, every service is in its own subvolume. The containers are precisely referenced by their digest-hashes, which gets snapshotted together with all persistent data. So every snapshot holds exactly the amount of data that is required to do a seamless rollback. Snapper maintains a timeline of snapshots for every service. Updating is semi-automated where it does snapshot -> update digest hash from container tags -> pull new images -> restart service. Nightly offsite backups happen with btrbk, which mirrors snapshots in an incremental fashion on another offsite server with btrfs.
Backups… with LVM, if you’re trying to do a full system backup (ie with clonezilla, etc) then you have to backup the whole thing - you can’t backup just 1 drive.
I have a media server with 2x 2TB HDDs and 1x SSD in a LVM, split into Music, Video, TV… and the OS … and I can backup the individual files of course, but I can’t backup just the OS drive.
btrfs didn’t exist when I created it, but I use it on my NAS and it’s great.
I’ll be rebuilding my media server one day and change LVM to btrfs.
