I still have drawings I made in MS Paint on Windows 95 when it had just come out, my first text document, and the first report I ever typed in grade school.
Btrfs snapshots of the root volume in RAID1 configuration with 8 hourly, 7 daily, 3 weekly, and automated rsync backups to NAS, with primary and secondary offsite, physically disconnected backups stored in sealed, airtight, and waterproof containers at two different banks prepaid storage and with advanced directive in the event of my demise.
Bit of a hobby really. I acknowledge it’s completely unnecessary. I don’t like to lose data.
You got me there! Not fireproof. In that case I’m just hoping that having two off-site backups at different locations has me covered, but that’s a good idea. I should consider fireproof foil.
I have system images of machines of relatives who have died. Many of the photos that I have retained are the only ones. However, that was more an emergent utility than a motivating one.
There was a time when people used to have 2400 bits per second from home (for the youngsters: that is 0.0003M). So if you are doing it for fun, why not.
I’m probably the overkill case because I have AD+vC and a ton of VMs.
RPO 24H for main desktop and critical VMs like vCenter, domain controllers, DHCP, DNS, Unifi controller, etc.
Twice a week for laptops and remote desktop target VMs
Once a week for everything else.
Backups are kept: (may be plus or minus a bit)
Daily backups for a week
Weekly backups for a month
Monthly backups for a year
Yearly backups for 2-3y
The software I have (Synology Active Backup) captures data using incremental backups where possible, but if it loses its incremental marker (system restore in windows, change-block tracking in VMware, rsync for file servers), it will generate a full backup and deduplicate (iirc).
From the many times this has saved me from various bad things happening for various reasons, I want to say the RTO is about 2-6h for a VM to restore and 18 for a desktop to restore from the point at which I decide to go back to a backup.
Right now my main limitation is my poor quad core Synology is running a little hot on the CPU front, so some of those have farther apart RPOs than I’d like.
How often depends on how much work it is to recreate, or the consequences of loosing data.
Some systems do not have real data locally, get a backup every week. Most get a nightly backup. Some with a high rate of change , get a lunch/middle of the workday run.
Some have hourly backups/snapshots, where recreating data is impossible. CriticL databases have hourly + transaction log streaming offsite.
How long to keep a history depends on how likely an error can go unnoticed but minimum 14 days. Most have 10 dailes + 5 weeky + 6 monthly + 1 yearly.
If you have paper recipes and can recreate data lost easily. Daily seems fine.
I mean I think it really depends on the type of website you’re trying to host. A static blog would use way less bandwidth than a media server for example. Traffic would have the same effect too, where 1 concurrent visitor to a blog would probably be fine but 10,000 would be a problem.
I used devices from gl iNet, the devices are good, but I find the UI of opnsense way better (compared to advance ui of openWRT) and updates are directly from opnsense.
I still have them for smaller network tests but for some reason I never got close to it. Probably another reason is that my brother uses opnsense too, if we have any issues we can ask each other for help.
I was familiar with just organise my docker-compose containers without any frontend. But I discovered casaOS, which make things pretty simple. An AppStore and a SMB-Shared File manager gave me a really good workflow. Things that aren’t on the AppStore can be handled outside of Casa, too.
PS. But never make the mistake to integrate the outside handled containers, this mess things up.
Thanks, yeah I’ve heard good things about casaOS. I think that I’m trying to move in the other direction though: fewer UI’s and more CLI’s + Configuration files.
Sounds like a connection would work with that setup but it would depend on what you are planning on hosting. Anything that is sensitive to latency would probably not work well. Static sites should be fine though.
Depending on what you are trying to host and where you live power usage and your own hardware might be more expensive than the VPS you require to host those.
This. Hosting at home might be cheaper if you are serving a lot of data, but in that case, the speed’s going to kill you.
I’m a keen self-hoster, but my public facing websites are on a $4 VPS (Binary Lane - which I recommend since you’re in Aus). In addition to less hassle, you get faster speeds and (probably) better uptime.
I run microk8s on a 3 node cluster, using FluxCD to deploy and manage my services. I also work with Kubernetes at work, so I’m very familiar with the concepts. But I will never use anything else.
If you want maximum control and flexibility, learn Kubernetes. For a lot of people (myself included) it’s overkill, but IMO it’s the best.
My main gripe with docker-compose, which is what I used to use, is that service changes require access to the machine. I have to run commands on the host to alter services. With Kubernetes, and more precisely a GitOps model, you can just make a commit to a git repo and it will roll out.
For your last point, portainer fixes that. I use portainer to pull compose files from my gitea instance. There is an option to auto update on git comit but I prefer to press the button to update.
I write the compose files in vscode and push them to my repo.
FWIW I manage docker compose files with ansible. Allows me to centrally manage them without the need to go logging into multiple vms. I also create a systemd service file to start/stop the containers (also managed with ansible).
That said I’m starting to switch over to k8s as well (also with microk8s which has been the easiest to work with). Definitely overkill but I want to learn it.
Yes very true, I really would much prefer GitOps as I feel… uneasy about how handwired and ephemeral my current setup is and would love it to be more declarative and idempotent. It does seem like Kubernetes is the way to do that.
In my opinion trying to set up a highly available fault tolerant homelab adds a large amount of unnecessary complexity without an equivalent benefit. It’s good to have redundancy for essential services like DNS, but otherwise I think it’s better to focus on a robust backup and restore process so that if anything goes wrong you can just restore from a backup or start containers on another node.
I configure and deploy all my applications with Ansible roles. It can programmatically create config files, pass secrets, build or start containers, cycle containers automatically after config changes, basically everything you could need.
Sure it would be neat if services could fail over automatically but things only ever tend to break when I’m making changes anyway.
This, I used to have a kubernetes setup but how much redudency can you really have at home. Do you have a generator? Multiple Internet lines?
The fact is most hardware is highly reliable. Having good backups to restore from is all you need and you gain a huge improvement in simplicity which adds reliability in and of itself.
Yeah I guess that’s true, I do think the other part about having configs done programatically is a lot more important anyway. If things go down but all it takes to get it back is to re-run the configs from files then it’s not so bad
More importantly, if you do things programmatically you will still have the information how you did it last time the next time you need to move to a new major version of something which is particularly important in a home setting where you don’t do tasks like that often.
I would say that if you are going to host it at home then kubenetes is more complex. Bare metal kubernetes control plane management has some pitfalls. But if you were to use a cloud provider like linode or digital ocean and use their kubernetes service, then only real extra complexity is learning how to manage Kubernetes which is minimal.
There is a decent hardware investment needed to run kubernetes if you want it to be fully HA (which I would argue means it needs to be a minimum of 2 clusters of 3 nodes each on different continents) but you could run a single node cluster with autoscaling at a cloud provider if you don’t need HA. I will say it’s nice not to have to worry about a service failing periodically as it will just transfer to another node in a few seconds automatically.
You should try out all the options you listed and the other recommendations and find what works best for you.
I personally use Kubernetes. It can be overwhelming but if you’re willing to learn some new jargon then try a managed kubernetes cluster. Like AKS or digital ocean kubernetes. I would avoid managing a kubernetes cluster yourself.
Kubernetes gets a lot of flack for being overly complicated but what is being overlooked with that statement is all the things that kubernetes does for you.
If you can spin up kubernetes with cert-manager, external-dns, and an ingress controller like istio then you got a whole automated data center for your docker containers.
Thanks. Yeah I’m temped to try kubernetes because of what you mentioned. I really like that every part that I need (ingress controller, certs, etc) are considered part of the core service and are built in. Right now I just have to run that stuff like it’s own service and wire everything up by hand. I don’t think I mind the extra overhead of kubernetes either, I love to tinker with that sort of thing anyway!
I think I will try a couple of things though. Maybe find a set of services to deploy with each and compare the experiences.
Well the kubernetes API has all the necessary parts built in mostly, although sometimes you may want to install a custom resource which often comes with complex service installs.
But I think the biggest strength of kubernetes is all the foss projects that are available for it. Specifically external-dns, cert-manager, and istio. These are separate projects and will have to be installed after the cluster is up.
Caution, not all cloud providers support istio. I know that Google’s GKS doesn’t, they make you use their own fork of it
I would also recommend you avoid helm if possible as it obfuscates what the cluster is doing and might make learning harder. Try to just stick to using kubectl if possible.
I have heard good things about nomad too but I have yet to try it.
Recently went through this. Needed a quick and dirty knowledge repository for work. Ended up running bookstack, wiki.js and dokuwik in docker containers, building the same wiki in each and then messed around with it. Landed on bookstack and wiki.js, bookstack because I liked the end user UI and wiki.js because of the backend. I think most my co-workers use the bookstack one.
Bookstack looks really cool, considering it for a project at work but I don’t like how you can’t have pages outside of books. We’re looking to put together a general knowledge base that could span many different types of equipment and manufactures. For that reason I’m leaning towards wiki.js due to the search and tag browsing, but basically planning on doing the same installing those same 3 to check them out.
Another thing with bookstack is that if your local IP changes for any reason, it breaks all the images and it is pretty frustrating to get them working again. They added a command to try to fix this, but I could never get it to work correctly.
I ended up switching to wiki.js and haven’t had a single problem since, but I do miss the super sleek look of bookstack sometimes.
My nas is a low powered atom board that runs unraid.
My dockets run on a ryzen CPU with proxmox. I don’t have a cluster, just 1.
In proxmox I run a VM that runs a all my dockets.
I use portainer to run all my services as stacks. So the arr stack has all the arrs together in a docker compose file. The docker compose files are stored in gitea (one of the few things I still run on unraid) and Everytime I make a change to the git, I press one button on portainer and it pulls down the latest docker compose.
For storage, on proxmox I use zfs with ssds only. The only thing that needs HDDs is the media on my unraid.
When a docker needs to access the media it uses an NFS mount to the unraid server.
Everything else is on my zfs array on proxmox. I have auto zfs snapshots every hour. Borg backup also takes hourly incremental backups of the zfs array and sends it to the unraid server locally and borg base for off-site backup.
The whole setup works very well and it very stable.
The flexibility of using proxmox means that things that work better in a VM (HaOS) I can install as a VM. Everything else is docker.
selfhosted
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.