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...

Last updated: June 12, 2026 SSH is usually the front door of a Linux home server. It is the thing you use when the web dashboard is broken, when Docker is misbehaving, when a service refuses to start, or when you need to fix something from another room with a laptop balanced on your knees. That also means SSH deserves more attention than most people give it. A home server does not need enterprise paranoia. It does not need a ten-page access policy, a hardware security module, and a dashboard full of red lights. But it does need a sensible SSH setup: key-based login, no direct root login, no password login when practical, firewall rules that limit who can connect, and a recovery plan so you do not lock yourself out of your own machine. This guide is the SSH hardening article I would follow for a small Linux home server, cheap homelab box, old workstation, mini PC, laptop server, or self-hosting machine running Docker services at home. If you are building the whole security s...