Homelab Storage Design: Separate Boot, Apps, Media, and Backups

Disclosure: This article may contain affiliate links. If you purchase through a link, we may earn a commission at no additional cost to you. Recommendations are matched to the documented requirements described below.

Documentation basis: This guide is grounded in Proxmox VE storage documentation, Docker volume documentation, and Proxmox Backup Server documentation. It does not claim private testing, personal ownership, or measured performance.

Homelab storage design is a placement and recovery problem. Boot files, active applications, bulk media, and backups have different capacity, latency, failure-domain, and restore requirements.

The useful question is not which storage product is best in isolation. It is which workload belongs on which tier, what happens when that tier fails, and how a restore is verified.

Key Takeaways

• Separate boot, application, media, and backup roles before migrating workloads.
• Match latency and capacity needs to the workload instead of treating every disk as interchangeable.
• Keep backup copies outside the primary failure domain and verify restores periodically.

What a homelab storage solution actually means

Search intent around “homelab storage solution” is best answered with a concrete layout model rather than a list of storage acronyms.

The short version is:

A real homelab storage solution is not one product. It is a layout decision.

You are deciding:

1. where the hypervisor boots

2. where VMs and containers live

3. where large datasets live

4. where backups live

5. how much redundancy each tier deserves

6. what can die without ruining your weekend

That is why the guide uses a design article over another generic storage-types explainer. Most people do not need ten paragraphs on what NFS stands for. They need a clear answer to "where should each kind of data go so this setup stays fixable?"

The main boundary rule

Do not mix critical boot, latency-sensitive app storage, bulk media, and backups into one emotional junk drawer.

You can build one giant ZFS pool and throw everything into it. That layout can work until you need to troubleshoot performance, expand capacity, isolate failure domains, or explain your setup six months later.

A common failure pattern is:

A legacy layout may keep VM disks, Plex media, ISO files, snapshots, and random exports all on the same storage pool because it felt tidy. It was tidy in the same way one giant junk drawer is tidy. Everything was technically in one place, which meant nothing had a clear role.

A clearer design splits storage by behavior.

• Boot storage should be boring and dependable.
• Active app storage should be fast.
• Bulk data storage should be cheap and expandable.
• Backup storage should be isolated from the mess above.

Once you accept those boundaries, the rest gets easier.

A four-tier homelab storage layout

That is the whole design in one table.

Everything else is implementation detail.

Tier 1: Boot storage should stay boring

For a Proxmox host, a mirrored SSD boot tier is a sensible option when the budget allows it.

Why? Because the host layer is too important to sit on one tired consumer drive if the machine is doing real work.

For smaller labs:

• 2 x SATA SSD mirror is perfectly respectable
• 2 x NVMe mirror is even better if the board supports it cleanly
• keep the boot tier small and focused

Do not treat boot storage as the place for every VM by default. Proxmox itself is happiest when the host stays simple.

Useful commands:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT\ncat /etc/pve/storage.cfg\npvesm status

If you install Proxmox on ZFS, the official storage docs and ZFS backend docs are worth reviewing before you start moving guests around:

• Proxmox VE storage model
• Proxmox ZFS backend reference

If you are still deciding whether your whole homelab should center on Proxmox, read Choosing a Homelab OS: Proxmox, TrueNAS, or Plain Linux?.

Tier 2: Active app and VM storage is where SSD money actually pays off

This is the tier people feel.

Put your active VM disks, LXC root filesystems, databases, monitoring stacks, and write-heavy services on SSD or NVMe. That includes things like:

• PostgreSQL and MariaDB volumes
• Home Assistant databases
• Immich thumbnails and metadata
• Git forge data
• observability stacks like Prometheus, Loki, or Grafana storage
• the VM disks behind your everyday services

If you are on Proxmox, this usually means a dedicated ZFS dataset or LVM-thin pool for images and rootdir, separate from bulk file storage.

ZFS vs LVM-thin here

ZFS is a strong fit when snapshots, data integrity, and clear dataset management matter most.

LVM-thin is a strong fit when a simpler local block-storage path is preferred and ZFS features are not required on that exact tier.

A practical rule of thumb:

• ZFS for labs where snapshots, replication habits, and data integrity matter more than squeezing every last bit of simplicity.
• LVM-thin for straightforward VM/LXC placement when you already have a separate backup plan and want fewer moving parts.

This is also where Proxmox Storage Architecture: The Layout I Actually Recommend and Proxmox ZFS Setup Guide: The Storage Layout the documented fit is Before You Regret Your Pool Design fit nicely into the bigger picture.

Tier 3: Bulk storage should optimize for capacity and boundaries, not ego

Your media library does not need to live on the same premium flash that serves your databases.

That sounds obvious, but a lot of homelabs end up doing exactly that because the first big SSD feels convenient. Then Jellyfin scans, downloads, backups, and large file moves start competing with actual app storage.

Bulk storage is where a homelab can place:

• media libraries
• ISO and template archives
• long-term document dumps
• camera exports
• large download staging areas
• non-latency-sensitive shared files

This tier is where large HDD mirrors or NAS-backed shares make sense.

If your apps are on Proxmox and your large files live on a NAS, you also need to choose the right sharing protocol. Start with NFS vs SMB vs iSCSI: Which Protocol Should You Use for Your Homelab NAS? and, for mixed Proxmox plus Docker use, NFS vs SMB for Proxmox and Docker: Which Network Share Should You Actually Use?.

Local bulk storage or NAS?

A practical split is:

• single-node Proxmox box - local mirrored HDD bulk tier is fine
• two or three-node lab - shared NAS starts making more sense for media, backups, and reusable datasets
• high-availability fantasies on a budget - slow down and keep it simple before adding shared storage just because the diagram looks cool

Shared storage is useful when it solves a real workflow problem. It should not be your first instinct.

Tier 4: Backup storage is not just "more storage"

Snapshots are great. Snapshots are also not backups.

If your VM disks, media, and snapshots all live in the same failure domain, you do not have a backup strategy. You have a confidence problem.

Your backup tier should be one of these:

• a dedicated local backup disk or pool
• a separate NAS
• a Proxmox Backup Server datastore
• an off-host PBS target
• a combination of local plus offsite copies

The Proxmox community advice on this is consistent: separate backup storage matters, and Proxmox Backup Server earns its keep fast once you have multiple VMs to protect. The official PBS docs are the right baseline if you are designing this properly: Proxmox Backup documentation.

For the practical version, read Proxmox Backup Strategies: How to Never Lose a VM Again and Homelab Backups and Monitoring: The Boring Setup That Saves You.

Three layouts A practical design recommends in the real world

Single-node starter lab

Good for: one mini PC, a tower server, or a first serious Proxmox box

• 2 x SSD mirror for boot and active VMs
• 2 x large HDD mirror for media and bulk files
• external USB HDD or NAS target for backups

Why this works:

• clean boundaries
• easy to explain
• easy to recover
• cheap enough to build without getting weird

Two-node practical lab

Good for: you want separation, not fake enterprise theater

• each node gets local SSD boot and active tiers
• one shared NAS or one dedicated backup box handles bulk and backups
• replicate only what actually matters

Why this works:

• each host stays fast locally
• shared capacity stays centralized
• backups stop competing with production writes

Three-node growing lab

Good for: you already know why you need three nodes

• local SSD or NVMe on every node for active workloads
• shared NAS or carefully planned distributed storage only if you truly need it
• dedicated PBS box or datastore off the main compute path

Why this works:

• cluster behavior stays predictable
• storage roles are visible at a glance
• expansion decisions stop feeling random

Commands to use to audit a storage layout before changing anything

Run these before you buy drives, migrate VMs, or rewrite your storage map:

pvesm status\npvesm list local-lvm\ncat /etc/pve/storage.cfg\nzpool status\nzpool list\nzfs list\nlvs\nvgs\npvs\ndf -h\nlsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT

Audit for:

• which storage IDs currently hold images and rootdir
• whether VM disks are sitting on slow or crowded storage
• whether backups are mixed into primary tiers
• whether ZFS pools already have role separation
• how much free space exists before any migration begins

If you run a mix of VMs and containers and are not sure which workloads deserve the fastest tier, Proxmox LXC vs VM: Which Should You Run for Each Homelab Workload? helps make that call.

The mistakes Common mistakes seen most often

1. Putting backups on the same pool as production data

This is the classic one. It feels efficient until the pool dies or fills up.

2. Wasting premium SSD on cold media

Fast flash should help services that care about latency. Movies do not care.

3. Using one storage class for every workload

Different workloads want different things. Databases want fast random IO. Media wants cheap capacity. Backups want isolation.

4. Treating shared storage like a requirement

A lot of small labs do better with good local storage and clean backups than with premature shared-storage complexity.

5. Buying drives before drawing the tier map

Always sketch the roles first. Hardware choices make more sense once you know what each tier must do.

Recommended gear for this kind of layout

You do not need exact part-for-part copies of a particular lab, but these categories fit this design well:

• Fast NVMe SSD options for active VM and app storage
• Large NAS HDD options for bulk media and file tiers
• UPS options for graceful shutdowns and cleaner backup windows

A sensible spending order is:

1. reliable SSD for boot and active workloads

2. clean backup destination

3. bulk HDD capacity

4. UPS if you still do not have one

That order prioritizes recoverability and workload fit over buying the biggest drive first.

Once your backup tier is separate from your app and media tiers, the next logical step is a dedicated Proxmox Backup Server setup for homelabs. That is where the guide lays out the retention, verification, and offsite sync workflow that turns this storage design into something you can actually recover from.

Want everything in one place? See my Best NAS Hard Drives for Homelabs list on Amazon, with a note on who each pick is for. For the bigger picture, there's also my Best SSDs for Home Servers and NAS Cache list.

Frequently Asked Questions

Sources and verification

Primary documentation checked before this revision:

• Proxmox VE Administration Guide
• Proxmox storage model
• Proxmox ZFS reference
• Proxmox Backup Server documentation
• Docker volumes documentation

Verification scope: source URLs were checked for reachability; article claims are framed as documentation-based guidance rather than private testing results.