How I Reorganized My Homelab Around Compute, Storage, and Backups

My homelab did not begin with an architecture plan.

It grew one service at a time. I added containers when I needed them, created shares when something needed storage, and put data wherever there was enough space. Eventually, one Unraid server was responsible for media, Docker, virtual machines, personal files, application data, and NAS shares.

It worked, but I could no longer explain what was supposed to happen when that server failed.

My wife’s photos and documents lived on the same machine as media I could download again. Application configuration sat beside data that could not be replaced. Some things needed a real recovery plan. Other things only needed enough documentation to rebuild them.

I had treated all storage as if it had the same value and all workloads as if they belonged on the same server.

The rebuild started when I stopped asking where I had free space and started asking what each system was responsible for.

Defining the problem

Unraid was not failing at the jobs I gave it. The problem was that I had given it nearly every job.

When storage, applications, virtual machines, and personal data all depend on one machine, normal maintenance affects unrelated services. Restarting the application platform also restarts the NAS. A boot-device problem can make every role on the server unavailable at once. Even a small migration becomes harder because each change touches several dependencies.

I wanted the new design to answer four questions:

Where do applications and virtual machines run?
Where does bulk media live?
Where do normal NAS shares live?
Where is the separate recovery copy of important data?

I also needed to classify the data itself.

Data I cannot replace

This includes family photos, personal documents, and other files that do not have another source. Losing these would be permanent.

Configuration I can rebuild but would rather restore

Application data, container configuration, and boot configuration may be reproducible, but rebuilding them takes time. A backup changes a multi-hour recovery into a much smaller job.

Data I can reacquire

Bulk media still consumes storage and time, but it does not have the same value as family photos. It needs protection from an ordinary disk failure, but it does not necessarily need the same backup strategy as irreplaceable personal data.

That classification became more useful than a generic rule that everything should be backed up the same way.

Building a separate TrueNAS backup target

The first change was adding another physical system for important data.

I had an unused i3 system and four 8 TB SAS drives. I installed TrueNAS SCALE and created a ZFS pool with two mirrored vdevs, giving me roughly 14 TB of usable capacity.

The pool contains datasets that match the data copied from Unraid:

tank/photos for family photos
tank/wifesname for my wife’s files
tank/michael for my personal data
tank/backups for Time Machine and other backups

Staggered rsync jobs copy data from Unraid to TrueNAS overnight.

For personal data, I omit the --delete option. If I accidentally delete a source file from Unraid, rsync does not automatically remove the existing destination copy during the next job.

That choice provides one useful safeguard, but it does not turn rsync into a complete versioned backup system. A changed file may still replace the previous destination version, and corruption may be copied if nothing else preserves an earlier state.

ZFS snapshots or another retention layer would determine how many older states I can recover, not the absence of --delete by itself.

The migration also forced me to decide what was worth keeping. I found a 58 GB recovery folder that had not been touched in ten years.

I deleted it.

Not every old file becomes important just because I have enough storage to keep it.

Learning that configuration needs a recovery plan too

During the rebuild, the Unraid boot USB failed.

The drive showed 100% full in the dashboard, and the FAT32 filesystem began returning I/O errors. I could not remount it, create a current backup, or repair it while the server was running.

I had to replace the flash drive and rebuild the Unraid configuration.

The array data was intact. Appdata remained available, and the copies on TrueNAS were unaffected. From a data-loss perspective, the important files were safe.

Recovery still took time because the missing item was configuration rather than data.

That failure exposed a gap in how I had thought about backups. I had focused on the files stored by the server without giving the server’s own boot configuration the same attention. The array could survive while the system remained inconvenient to rebuild.

I now archive the Unraid flash configuration to the array each night and create another backup after significant changes.

A data backup and a configuration backup solve different recovery problems:

Lost personal file → restore from another data copy or snapshot
Lost application configuration → restore appdata or rebuild the service
Lost Unraid boot device → restore the flash configuration
Lost replaceable media → recover with parity or reacquire the data

The failed USB drive did not prove that every recovery path was complete. It showed which one was missing.

Moving application workloads to Proxmox

Adding TrueNAS protected another copy of important data, but Unraid was still doing too much.

I installed Proxmox on my dual-Xeon server and moved virtual machines and application workloads there. Proxmox became the place where I manage compute rather than asking the NAS to act as the application platform too.

This creates a clearer boundary:

Proxmox runs virtual machines and applications.
Unraid provides selected NAS duties and file shares.
TrueNAS stores separate copies of important data.

The boundary is not perfect physical separation. My bulk media disks also live on the Proxmox host, so losing that host affects both application workloads and access to that media storage. I accepted that coupling because the media is replaceable and the design lets me use the hardware I already have.

That is different from allowing the same failure to take out the only copy of personal data. TrueNAS remains a separate machine for that reason.

Building bulk media storage with XFS, mergerfs, and SnapRAID

For bulk media, I built a storage layer directly on the Proxmox host using XFS, mergerfs, and SnapRAID.

The three pieces have different jobs.

Each data disk uses XFS as its own filesystem. mergerfs then presents those disks through one combined mount point:

disk1 ─┐
disk2 ─┼─→ mergerfs → /mnt/data
disk3 ─┘

Applications can use /mnt/data without needing to select an individual disk. The underlying files still live on normal filesystems rather than being striped across every disk as one filesystem.

SnapRAID calculates parity separately. If a protected data disk fails and the parity information is current, SnapRAID may be able to reconstruct the lost data within the limits of the configured parity.

This design fits media because the data changes less frequently than application databases or active virtual-machine disks. It also lets me add disks of different sizes more flexibly than some traditional array layouts.

It comes with tradeoffs:

SnapRAID parity is not real-time.
New or changed files are not protected until a sync completes.
The latest parity state matters during recovery.
The Proxmox host remains part of the media-storage failure domain.
A deleted file may also disappear from parity after later syncs.

Most importantly, parity is not a backup.

Parity helps recover from a supported disk failure. It does not create an independent copy on another machine, preserve every previous file version, or protect against losing the entire host.

That is why I treat the systems differently:

SnapRAID protects replaceable bulk media from ordinary disk failure.
TrueNAS holds separate copies of important data.
Configuration backups reduce rebuild time.

One mechanism does not cover every type of loss.

The current responsibility model

The homelab now has more components, but each component has a narrower purpose.

Proxmox host
├── Virtual machines and application workloads
└── Bulk media storage
    ├── XFS filesystems on individual disks
    ├── mergerfs combined mount at /mnt/data
    └── SnapRAID parity

Unraid
└── NAS duties and selected file shares

TrueNAS SCALE
└── Separate copies of important personal data and backups

Remote access is separated by purpose too. Tailscale provides access to internal resources from approved devices. Selected browser-based services can use Cloudflare Tunnel and Cloudflare Access when I want access without joining the private network first.

The important part is not the number of servers. It is knowing which role belongs to which system and what becomes unavailable when that system fails.

Testing the failure domains

An architecture diagram shows where components live. A recovery plan needs to explain what happens when they do not work.

Based on the current design, the expected failures look like this:

Failure	Expected effect	Recovery path
Proxmox host is offline	Virtual machines, applications, and `/mnt/data` media become unavailable	Restore the host or workloads; media disks remain the storage source
Unraid is offline	NAS shares become unavailable, along with any service that depends on them	Repair Unraid or restore its flash configuration; important data also exists on TrueNAS
TrueNAS is offline	Backup copies are temporarily unavailable	Primary services continue; repair TrueNAS before another copy is needed
One protected media disk fails	Files on that disk are unavailable	Recover with current SnapRAID parity if the failure is within tolerance
A personal file is deleted from Unraid	Source file disappears	The no-delete rsync copy may remain; snapshots determine whether earlier versions are recoverable
Unraid boot USB fails	Unraid cannot boot normally	Restore the archived flash configuration to a replacement device

This table describes the intended design. It should not be treated as proof until the recovery paths have been tested.

A backup job finishing successfully proves that files were copied. It does not prove that I can find and restore the right version under pressure.

That is the next level of this project: testing recovery rather than assuming the copies are enough.

What the new architecture costs

Separating responsibilities did not make the homelab objectively simpler in every way.

I now have more operating systems to update, more hardware consuming power, more network paths, and more places where permissions can be wrong. Applications may depend on storage provided by another system. Monitoring and documentation matter more because the architecture has more boundaries.

I accepted those costs because the boundaries solve problems I actually have:

Application maintenance no longer has to happen on the NAS.
Important data has a copy on another physical machine.
A failed Unraid boot device does not destroy the array data.
Replaceable media can use a different protection strategy from family photos.
Each system has a recovery purpose I can describe.

This is not an argument that every homelab needs Proxmox, Unraid, TrueNAS, mergerfs, and SnapRAID. Running all of them without a reason would create the same kind of unnecessary complexity I was trying to remove.

The design makes sense for me because I already had the hardware and because the data categories have different recovery requirements.

What I learned

I used to treat consolidation as another word for simplicity. Sometimes one machine is simpler. There are fewer systems to patch, fewer network dependencies, and fewer things drawing power.

But consolidation can also hide unrelated failure domains inside one box.

The better question is not how many servers I can eliminate. It is whether each system has a clear job and whether I understand the effect of losing it.

The biggest improvement was not installing Proxmox or building another NAS. It was separating four ideas that I had previously mixed together:

Running an application
Storing its data
Recovering from a disk failure
Recovering data or configuration from another copy

Those jobs can overlap, but they are not the same.

My homelab has more pieces now. It also has a clearer answer for what matters, where it lives, and how I expect to recover it.

The remaining work is to test those expectations. A diagram is useful. A successful restore is better.