Build a proper home server: proper instructions

A proper home server is a documented, recoverable system with controlled access, rather than a collection of containers. Build around the data: identify files, photos, databases, passwords and configuration that cannot be recreated; separate them from disposable caches. RAID, snapshots and mirroring can improve availability but do not protect against deletion, ransomware, theft or a bad synchronisation. This guide creates a secure Debian foundation for adding services gradually.

Plan hardware, storage and network

• Use a low-power desktop, mini PC or server with reliable cooling. If reusing a laptop, test thermals and battery health.
• Connect by Ethernet and reserve the address in the router. Record drive serials, disk layout, reservation, BIOS settings and recovery contact.
• Use an external disk, second machine or encrypted off-site repository that is not permanently writable by every service account.
• Enable automatic restart after power loss only after testing. A USB-signalling UPS needs compatible shutdown configuration and a tested battery.

Install the base host

1. Back up all existing disks. Install current Debian stable from an official image, create an ordinary administrator and select SSH only if remote management is needed.
2. Partition deliberately. Keep OS and service data separate where possible. Even on one disk, a dedicated mounted /srv path distinguishes service data from the operating system. Never assume a disk is empty based only on its size.
3. Update and restart:

   sudo apt update
   sudo apt full-upgrade
   sudo reboot

   .

4. Create the router reservation and verify state:

   hostnamectl
   ip -br address
   ip route
   getent hosts deb.debian.org

   .

5. Install minimal administration tools:

   sudo apt install curl ca-certificates vim-tiny smartmontools

   . Inspect each actual drive, substituting the right path:

   sudo smartctl -a /dev/sdX

   . Read results carefully; USB enclosures sometimes hide SMART data.

6. Set up SSH keys. Verify key login in a new session before disabling password login, and retain a local console path in case access is misconfigured.

Backups must be restored, not merely scheduled

1. Create service-specific directories below /srv, for example /srv/files and /srv/monitoring. Assign least-privilege ownership; avoid a world-writable directory shared by all services.
2. Choose a versioned backup tool such as restic or borg and follow its official initialisation and retention instructions. Keep repository credentials protected and outside normal service data. Plain synchronisation is insufficient because it can replicate damage.
3. Back up a small test dataset and configuration. Run the tool’s integrity verification where available, restore a file to a new path and open it. Only then schedule unattended backups.
4. Write a recovery note: replacement hardware, OS installation, storage mount, secure credential retrieval, restore command source and service startup order. Do not put plaintext secrets in that note.

Add services one at a time

For every workload, record its purpose, owner, ports, data path, update method and backup inclusion. Containers simplify packaging but do not make networks, volumes or image updates safe by default. Store each Compose file with its configuration, use reviewed image versions where stability matters and keep persistent data in the planned service area.

1. Identify required inbound ports and whether each must be LAN-only. Bind management interfaces to localhost or the LAN address where possible.
2. Deploy one service, test it from a LAN client, reboot the server, then test persistence and automatic startup.
3. Inspect the exposure:

   sudo ss -tulpn
   systemctl --type=service --state=running

   . If Docker is used, also run

   sudo docker ps

   . Compare results to the written inventory.

4. Before every planned update, verify a backup, read release notes, update one service and run its smoke test. Do not mass-update unfamiliar images just because newer tags exist.

Security boundaries and acceptance tests

Keep services private by default. Do not port-forward SSH, dashboards, databases, NAS administration or container management. For remote access, prefer a maintained VPN or overlay network with named accounts and multi-factor authentication where supported. TLS and reverse proxies encrypt a connection; they do not replace authorisation or patching.

• Use unique passwords in a password manager and remove access for old devices and users promptly.
• Choose monitored automatic security updates or a regular manual patch window. Both require planned reboots for some kernel updates.
• Review router firmware, existing port-forwards and UPnP. Disable UPnP when it is not required.
• Place untrusted IoT devices on a guest or IoT network if the network supports it, and do not allow that network to administer the server.
• Protect physical access. Firmware passwords, a locked location and disk encryption address different risks; encryption also requires a reboot-unlock plan.

1. Reboot and confirm the reservation, SSH key access, intended mounts and services. Check storage:

   df -h

   .

2. Restore a non-sensitive backup file to a new location and read it. This is the essential acceptance test.
3. Disconnect the backup target after completion if the design permits, then ensure it is not casually exported as a writable share.
4. Review port-forwards and verify that no internet exposure has been created accidentally.

Rollback and failure recovery

To undo a new service, stop it, remove LAN exposure, preserve its data and configuration until deletion is approved, and restore the previous configuration if an upgrade caused the fault. For host failure, do not overwrite the only surviving disk while investigating. Build a patched base OS on replacement hardware, mount intended storage, recover from the verified backup, and bring services online one at a time. Update the recovery note after every material change; a server is only as recoverable as its tested documentation and backup.