Self Hosting 10tb in S3 on a Framework Laptop and Disks

Self-hosting implies those features without the cloud element and not just buying a computer.

You can own a computer and not run any services at all. Most people do.

Deciding to run your own services, like email, means a lot of work that most people aren’t interested or capable of doing.

It’s the difference between using your computer to consume things or produce things.

Some former colleagues still using gitlab ce tell me they also removed features from their self-hosted version, particularly from their runners.

I manage several Garage clusters and will keep maintaining the software to keep these clusters running. But concerning the "low level of activity in the git repo": we originally built Garage for some specific needs, and it fits these needs quite well in its current form. So I'd argue that "low activity" doesn't mean it's not reliable, in fact it's the contrary: low activity means that it works well for us and there isn't a need to change anything.

Of course implementing new features is another deal, I personally have only limited time to spend on implementing features that I don't need myself. But we would always welcome outside contributions of new features from people with specific needs.

You also want fast networking, I just use 10Gbps. My nodes each are 6 rust and 1 NVMe drive each, 5 nodes. I colocate my MONs and MDS daemons with my OSDs, each node has 64GB of RAM and I use around 40GB.

Usage is RDB for a three node OpenStack cluster, and CephFS. I have about 424TiB between rust and NVMe raw.

Yes, it's obvious, but it's a terrible title. I don't really get the point. It's trivial to have storage however you want an shove the S3 API on top.

Gives me the benefit of automatic fixes in the event of bit rot in any blocks more then an hour old too.

I have two setups.

1.) A mirror with an attached Tasmota Power Plug that I can turn on and off via curl to spin up an USB-Backup-HD:

  curl "$TASMOTA_HOST/cm?cmnd=POWER+ON"
  # preparation and pool imports
  # ...
  # clone the active pool onto usb pool
  zfs send --raw -RI "$BACKUP_FROM_SNAPSHOT" "$BACKUP_UNTIL_SNAPSHOT" | pv | zfs recv -Fdu "$DST_POOL"

To prevent partial data loss I use zfs-auto-snapshot, zrepl or sanoid, which I configure to snapshot every 15 minutes and keep daily, weekly, montly and yearly snapshots as long as possible.

To clean up my space when having too many snapshots, I wrote my own zfs-tool (https://github.com/sandreas/zfs-tool), where you can do something like this:

  zfs-tool list-snapshots --contains='rpool/home@' --required-space=20G --keep-time="30d"

Your use case perfectly matches mine in that I wouldn't mind much about a few hours of data loss.

I guess the one issue is that it would require more disks, which at the current prices is not cheap. I was suprised how expensive it was when I bought them 6 months ago and was even more suprised when I looked recently and the same drives are even more now.

In my country it's possible to have power loss occasionally, so having the battery on good health is important. I'm planning to setup two unused laptops, and a mobile for servers (different purposes) and power management, battery health has been an issue.

Eventually, the thing that kicked the bucket was actually the keyboard (and later the fan started making "my car won't start" noises occasionally). Even the horribly-slow HDD (that handled Ubuntu Server surprisingly well) hadn't died yet.