The dashboard was working yesterday. Today the database keeps restarting, an image update fails halfway through, and Docker says no space left on device . Somewhere in the search results, somebody suggests a prune command with every available flag. That is a good moment to slow down. The server may contain months of monitoring history, a password vault, or the only copy of an application configuration. A full disk needs a short investigation before it needs a cleanup command. This guide walks through that investigation on a Linux home server: identify the full filesystem, find the growing data, recover enough space to operate, and put a limit on whatever caused the problem. The quick answer: check both space and inodes, compare host usage with Docker’s inventory, and reclaim only data you have identified. Container logs, application data and build cache need different fixes. df -hT df -i docker system df -v docker ps -a --size These commands inspect the situation. If Docker is...

Home Server Backup Restore Drill: Prove Your Docker and VM Backups Actually Work Last updated: October 2026 Tested on: Ubuntu 24.04 LTS, Docker Engine , Docker Compose v2, Proxmox VE ,  A backup is not real because a job says “success”. A backup is real when you can restore it, boot it, log in, see your data, and explain the steps without searching through old browser tabs at midnight. This is the restore drill I would run on a home server that has both Docker services and virtual machines. It is not glamorous. It does not look impressive on a dashboard. It does something more useful: it proves whether your homelab backups actually work. If you are running Docker Compose stacks, Proxmox VMs, databases, reverse proxies, monitoring tools, file shares, DNS services or anything else you would miss if the server died, this drill is worth doing. Backups are only half the system. Restore is the part that tells the truth. Quick answer: how do you prove a home serv...

Most home servers do not fail loudly. They fail quietly. A Docker container stops. A dashboard becomes unreachable. A reverse proxy breaks. A disk fills. A service is technically running, but the web page is dead. You only notice when you actually need it, or when someone in the house complains that “the thing is not working again”. That is why I like Uptime Kuma . Uptime Kuma is a self-hosted monitoring tool that gives you a simple dashboard, uptime checks, response times, notifications and status pages without needing a full Prometheus/Grafana setup. The official project describes it as a “fancy self-hosted monitoring tool”, and for a Linux home server or homelab, that is exactly the sweet spot. This post is split into two parts: Part 1: the short install-and-ready-to-go version; Part 2: the more technical setup with Docker Compose, UFW, reverse proxy, alerts, backups, monitor design and hardening tips. If you just want Uptime Kuma running quickly, start with t...

Nobody thinks about Docker backups when everything is working. The dashboard loads. The media server streams. The reverse proxy behaves. The database container has a cute little green “healthy” status. Life is good. Then one day you run an update, delete the wrong volume, lose a disk, break a Compose file, or discover that the “temporary” container from six months ago was actually storing something important. That is when Docker stops feeling magical and starts feeling like archaeology. This post is a practical guide to backing up Docker containers on a Linux home server . Not enterprise disaster recovery. Not Kubernetes. Not a 40-page policy document. Just a realistic backup plan for a homelab running Docker Compose, bind mounts, named volumes and a few services that became more important than expected. The main idea is simple: You do not really back up containers. You back up the things needed to recreate them, plus the data they would destroy your weekend by losing. ...

Docker is one of the best and worst things that can happen to a homelab. Best, because it makes self-hosting ridiculously easy. Worst, because it also makes it ridiculously easy to expose random containers, run things as privileged, mount dangerous volumes, forget updates, and pretend that “it is inside a container” means “it is safe”. It does not. Containers are useful. Containers are convenient. Containers are not magic security boxes. This post is a practical Docker security guide for homelab beginners . Not enterprise Kubernetes theory. Not compliance paperwork. Just the things I would check on a Linux home server running Docker, especially if that server is always on and slowly collecting services like a digital junk drawer. The goal is simple: Stop exposing random containers and understand what your Docker host is actually doing.