Pi plus NAS — the practical self-host starter if you keep mounts and backups boring

If you're starting a self-host setup and you don't already have strong opinions, a Raspberry Pi paired with a NAS is the right shape. Cheap, low-power, expandable, and well within the operating envelope of a hobbyist who's also doing other things.

The usual failure mode isn't the hardware; it's the impulse to make the storage layer interesting. People stack ZFS over RAID over a custom mount-point scheme, add bind mounts for "organization," and put backups behind a homemade script that runs sometimes. Two months later, a disk acts up and the recovery is harder than it should be because nothing about the storage is boring.

The Pi-plus-NAS stack is durable when you keep the storage boring. This guide is the boring playbook.

The architecture in one paragraph

A Pi (or several) is the compute layer. A NAS (Synology, QNAP, or DIY with TrueNAS) is the storage layer. The Pi mounts shares from the NAS over NFS or SMB. Application containers on the Pi keep their configuration on the Pi's local SD card or SSD and their data on the NAS share. Backups run from the NAS, not from the Pi.

This split is the whole game. Compute is cheap and replaceable; storage is the part that has to last. Keep them separate.

The naming conventions that prevent half the future pain

Storage paths drift in the worst way. The conventions worth committing to up front:

One root mount per NAS share. /mnt/nas/<share> and never anywhere else. Don't bind-mount the same share into ten places. If you want shorter paths, symlink — but the symlinks all point to one root.

One directory per app. Under each share, one directory per application. /mnt/nas/apps/nextcloud, /mnt/nas/apps/jellyfin. Apps never share directories; never "oh, both of these read the same folder."

Predictable subdir layout per app. Inside the app's directory, the same subdirs: data/, config/, cache/. The application's container is mounted at the right subdirs.

Hostname-aware paths if you have multiple Pis. If two Pis run the same app, paths include the hostname: /mnt/nas/apps/<hostname>/nextcloud. Otherwise their data clobbers each other.

These feel obvious and they get violated all the time by half-asleep operators. Stick to them. The reward shows up when you migrate Pis, swap disks, or restore from backup six months later.

The mount layer

NFS or SMB? Use NFS when the NAS supports it and your Pi is Linux. SMB if you must.

NFS mounts go in /etc/fstab:

nas.local:/volume1/apps  /mnt/nas/apps  nfs  defaults,_netdev,nofail,x-systemd.automount  0  0

Key options:

• _netdev tells systemd this is network-dependent.
• nofail so the Pi still boots if the NAS is offline.
• x-systemd.automount so the mount is brought up lazily on first access rather than blocking boot.

Without these three, you'll have Pis hanging at boot because the NAS isn't reachable yet. With them, the Pi boots; the mount comes up when something asks.

For write-heavy apps (Nextcloud, Jellyfin metadata), consider NFSv4 with actimeo=1 to reduce attribute caching weirdness.

Where Docker volumes live

This is the question that trips people up. Should Docker volumes live on the Pi's local SSD, or on the NAS?

The practical answer: app data goes on the NAS, but app config and small caches can live locally.

Why:

• App data is large, durable, and needs backup. Put it on the NAS.
• App config (the YAML, the SQLite databases that the app uses for its own settings) is small and reads frequently. NFS reads are slower than local SSD reads; the user notices.
• Caches are recreatable. Put them locally; they'll regenerate if lost.

In a Compose file, this maps to bind mounts that explicitly choose the right side:

volumes:
  - /var/lib/myapp/config:/config           # local SSD
  - /var/lib/myapp/cache:/cache             # local SSD
  - /mnt/nas/apps/myapp/data:/data          # NAS

This split keeps the app fast and the data safe.

Backups: the discipline that decides everything

A Pi-plus-NAS setup lives or dies by backups. The boring playbook:

Two destinations, always. The NAS is one. An offsite location is the other — Backblaze B2, AWS S3, a Hetzner Storage Box, or a friend's NAS. "Backups" with one destination is a synonym for "copies."

Use a real backup tool. restic is the popular default for a reason: encrypted, deduplicated, verifiable. borg is the other strong choice. Don't write your own.

Schedule via cron on the NAS, not the Pi. The NAS already runs 24/7 and has direct access to all the data. Pi reboots shouldn't interrupt backups.

Heartbeat every backup. Use the cron monitoring pattern from this site. If the nightly backup doesn't ping, you find out within the hour.

Test restores monthly. Pick a small app. Restore its data to a side directory. Spin up a container against it. Verify the app reads the restored data correctly. If it doesn't, your backup is theoretical, not real.

Document the restore. "To restore Nextcloud: 1. restore /mnt/nas/apps/nextcloud from latest snapshot. 2. point Compose at the restored path. 3. start the container. 4. verify the home view." Write this for each app and keep it in your homelab repo.

A setup with verified offsite backups, monthly restore drills, and documented per-app restore procedures is genuinely resilient. A setup without those is one disk failure from a bad weekend.

Why people overcomplicate this

The most common mistakes:

Trying to use the NAS for compute too. Synology and QNAP boxes can run containers. They shouldn't run your main self-host workloads — they're underpowered, their container support is a second-class citizen, and you've now made the storage box also the compute box. If the NAS reboots, your apps go down. Keep compute on Pis.

Tiered storage on the NAS. Building a fancy pool layout with hot and cold tiers. For a hobbyist self-host setup, one pool with one RAID level is fine. Tier when you outgrow it.

Encrypted everything everywhere. Encrypting the NAS at rest is reasonable. Encrypting individual Docker volumes on top of that is usually unnecessary friction.

A bespoke mount script. A custom shell script that mounts everything in the right order. Use systemd and _netdev; let it work.

Each of these adds operational surface for not much benefit at the starter scale.

What to add in stage two

After the Pi-plus-NAS setup has been running stably for a few months and you've drilled the backup restore at least twice, the natural extensions:

• A second Pi for redundancy on critical services. Keep state on the NAS; the second Pi takes over if the first dies.
• A small monitoring layer. Either the lightweight observability pattern or a single Grafana panel reading from the rollup.
• A VPN into the homelab. Tailscale is the easy default. Don't expose anything to the public internet you don't have to.
• A reverse proxy. Caddy or Traefik on the Pi. TLS for everything, including internal apps.
• Snapshots on the NAS. Synology and TrueNAS both make periodic local snapshots cheap. They protect against accidental deletes.

Each of these earns its place after the storage layer is already boring. Adding them before that point amplifies the chaos.

A short checklist for week one

If you're standing the Pi-plus-NAS setup up this week, the minimum:

• NAS configured with a single pool and one share per category (apps, media, backups).
• Pi fstab uses NFS with _netdev and nofail.
• Each app's compose file uses explicit bind mounts split between local config/cache and NAS data.
• One backup destination (NAS local snapshots) + one offsite destination (restic to B2 or equivalent).
• Backup heartbeat configured for the offsite job.
• One restore drill completed end-to-end on one app.
• Restore procedures documented in your homelab repo.

That's the boring baseline. From there, add apps without changing the storage discipline. The setup will hold for years.

The summary

Pi-plus-NAS is the right shape for starter self-hosting. The durability comes from the storage discipline, not the hardware. Keep paths boring, mounts predictable, backups verified, and restores drilled. The hardware stuff people obsess over is downstream of those four. Get the storage layer right; the rest of the homelab grows on top without surprise.