Homelab Storage Design: How I Split Boot, App, Media, and Backup Tiers Without Making a Mess

Disclosure: This article contains affiliate links. If you purchase through these links, we may earn a commission at no additional cost to you.

After running Proxmox in production for three years, I made the same storage mistake most homelabbers make - I treated every disk like it should solve every problem.

That usually starts with one SSD for Proxmox, one big hard drive for "data," and a vague plan to sort it out later. Later turns into messy VM placement, backups living on the wrong disk, media shares fighting with databases, and one ugly restore day where you realize your storage layout never had clear boundaries.

This is the storage model I actually recommend now. It is not fancy. It is not the cheapest possible layout. It is the one that stays understandable when your lab grows from a single mini PC into a stack of VMs, containers, shared storage, and off-host backups.

Key Takeaways

• Your homelab storage layout should separate boot, active app/VM, bulk media, and backup tiers.
• Fast SSD or NVMe storage should hold Proxmox itself plus the workloads that feel latency first.
• Big HDD capacity should hold media libraries, archival files, and low-IO bulk data.
• Backup storage is its own tier. It is not the same thing as primary storage with snapshots.
• In most small homelabs, mirrored SSD for active workloads plus mirrored HDD for bulk data is a saner starting point than chasing one giant pool.
• If you run Proxmox, learn your current layout with pvesm status, cat /etc/pve/storage.cfg, zpool status, and lsblk before you buy more disks.

What a homelab storage solution actually means

Google is already sending traffic for queries like "what is a homelab storage solution?" to broad beginner pages, which tells me the SERP still does not have a sharp answer.

So here is the short version.

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 I prefer 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 I follow

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. I have done it. It works right up until you need to troubleshoot performance, expand capacity, isolate failure domains, or explain your setup six months later.

The mistake I made:

I used to 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.

Now I split 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.

My four-tier homelab storage layout

Tier	What belongs there	Best media	Why
Boot tier	Proxmox OS, host config, minimal local system data	Mirrored SSD or NVMe	Fast boot, easy recovery, predictable host behavior
Active tier	VM disks, LXC rootfs, databases, app configs	SSD or NVMe, often mirrored	Latency-sensitive workloads feel the difference immediately
Bulk tier	Media libraries, downloads, ISO archives, cold project files	Large HDD mirror or RAID/ZFS array	Cheap capacity matters more than raw IOPS
Backup tier	Proxmox backups, PBS datastore, off-host copies	Separate HDD array, NAS, or remote PBS	Backups should survive mistakes in the primary tiers

That is the whole design in one table.

Everything else is implementation detail.

Tier 1: Boot storage should stay boring

If you are building or rebuilding a Proxmox host, I like a mirrored SSD boot tier 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

I 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

I like ZFS when I care more about snapshots, data integrity, and clear dataset management.

I like LVM-thin when I want a simpler local block-storage path and I do not need ZFS features on that exact tier.

My 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 I Recommend 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 I put:

• 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. I would 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?

I use this split:

• 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 I recommend 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 I like it:

• 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 I like it:

• 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 I like it:

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

Commands I 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

What I am looking 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 I see 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 my 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

I would spend money in this order:

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 saves more homelabs than buying the biggest drive first.

Frequently Asked Questions

What is a homelab storage solution?

A homelab storage solution is the layout you use to separate boot storage, active VM or app storage, bulk data, and backups so each workload lands on the right tier.

Should Proxmox VMs live on SSD or HDD storage?

Most active Proxmox VMs should live on SSD or NVMe storage. HDD tiers make more sense for bulk media, archives, and backup repositories.

Are ZFS snapshots enough for homelab backups?

No. Snapshots help with quick rollback, but they are not enough unless you also keep separate backup copies outside the primary storage failure domain.

When should I use shared storage in a homelab?

Use shared storage when it solves a real problem such as multi-node access to bulk data or backup centralization. Do not add it just to make a small lab look more enterprise-like.