Note: To keep this guide clear and easy to follow, I’ve divided it into two parts. The first part covers the overall process and goals—the 'why' behind each step. The second part, found at the end of this article, is a Command Reference Guide with all the commands used in the video. This way, we can focus on the big picture first, then quickly reference the practical commands when it’s time to build. Keep in mind that specific commands and configurations may vary depending on your operating system, its version, and your environment.
What’s up guys — welcome (or welcome back) to the blog. In the last few videos, we set up Proxmox Backup Server (PBS) and even covered how to back up and restore a full Proxmox host configuration using PBS. If you haven’t seen those yet, make sure you check them out later.
Now, one of the main reasons I set up that backup system in the first place was to prepare for some hardware upgrades. In this post, we’re going to talk about why I’m upgrading parts of my lab server, how my storage is structured, and what the thought process looks like when you’re planning storage for a homelab environment.
This isn’t just a “swap this drive, run that command” kind of post — it’s about the why behind each step, and how to think about your own setup before you start plugging things in.
Separation is key. It’s the same principle used in professional setups:
- Dev = playground for learning and testing.
- Prod = reliability and performance.
And because this server is my dev environment, I’m not obsessing over things like high availability or redundancy the same way I would for prod server. The whole idea is to squeeze as much life as I can out of the hardware while still keeping it fast enough to work comfortably.
Why the Upgrade?
Originally, I had no plans to upgrade this server. The goal was simple — run it until it can’t anymore. But over time, I started to notice something: a few of the virtual machines (especially GUI-based ones) were getting sluggish.
Everything was still running off a set of old drives that came with the system, so performance drops made sense. I don't want to buy a new server just yet, so upgrading a few drives feels like a smart middle ground — a little speed boost without a full rebuild.
My goal here isn’t perfection. It’s efficiency — to keep this aging server alive, functional, and fast enough to continue building, testing, and creating content.
Everything is already being backed up to PBS, so I’m not too worried about redundancy at the hardware level. I just want the system to perform a bit better for as long as it can.
The Storage Layout
Let’s talk about the setup. The server has a total of eight drive bays, and after this upgrade, here’s how things are structured:
- Two SSDs (4 TB each) for VM operating systems.
- Three newer HDDs (4 TB each) for application and data storage.
- Three older drives left in place for testing or future experiments.
I flashed the controller into IT mode so Proxmox could see every drive individually — that’s an important step if you want full flexibility in how you configure ZFS pools.
Storage Strategy
Since this is a dev environment, I focused on speed and flexibility over redundancy. Here’s how I structured it:
SSD Pool — “VM-OS-DATA”
These two SSDs are set up in ZFS RAID 0. Yeah, RAID 0 means no redundancy, but it doubles the performance and available space — perfect for running VM operating systems. Because all my VMs are backed up, the risk is acceptable. The SSDs give me the performance bump I need when booting or using heavier applications inside VMs.
HDD Pool — “VM-APP-DATA”
The three newer HDDs are configured as a ZFS RAID Z1 pool. This gives me roughly 8 TB of usable space with one drive’s worth of redundancy. This pool is where application data lives — things like databases, uploads, logs, and app configs. I chose RAID Z1 because while I don’t mind losing a VM OS (since it’s easily restorable), I do want a little more protection for persistent data.
The Spare Drives
The three older drives are sitting idle for now. I’ll likely use them for testing new setups, passthrough experiments, or upcoming videos on topics like TrueNAS or ZFS replication.
Why Separate OS and Data Storage?
Separating your OS and data gives you a clean structure and helps performance.
- The SSD pool handles fast-changing VM workloads — things that benefit from quick read/write.
- The HDD pool handles long-term data — the stuff you want to protect and access reliably.
This balance keeps the system efficient, organized, and easier to maintain.
Restoring VMs to the New Storage
Once the new pools were created, I restored my VMs and containers from PBS backups directly onto the new storage. The restoration process worked smoothly — and everything came back exactly as before, only faster.
If you remove or rename storage before restoring, you might need to manually clean up some old configuration files. Once those references are gone, restoring to the new pool should work fine.
Command Reference Guide
Here’s a quick reference section for those who want to set up a similar configuration on their own system.
These commands are generic — replace drive names and pool names with what fits your setup.
List Available Disks
- lsblk
Check Existing ZFS Pools
- zpool status
Create a New ZFS Pool (RAID 0)
- zpool create vm_os_data /dev/sde /dev/sdf
Verify Pool Creation
- zpool status
Add the Pool to Proxmox web
- Datacenter → Storage → Add → ZFS
Unlike RAID 0, which you have to create from the shell, RAID Z1 can be configured directly from the Proxmox web GUI. Just head over to Storage → ZFS → Create ZFS, select your three drives, and choose RAID Z1 from the list. Once it’s created, I also enable LZ4 compression to keep things efficient by running zfs set compression=lz4 <pool_name>. From there, you can verify your setup with zpool list to confirm everything is recognized properly.
After your new pool is ready, restoring from Proxmox Backup Server (PBS) is straightforward — just open Datacenter → Backups, select your VM or container, click Restore, and choose the new pool as your Target Storage. This makes it easy to bring your workloads back online while taking full advantage of the upgraded storage performance.
However, if your restoration fails, it usually means the old storage name no longer exists in your environment. When that happens, you’ll need to clean up the VM or container configuration file by removing any references to the old storage. This issue is common when the storage names don’t match between your previous setup and the new one. Once those outdated entries are removed, you can re-run the restoration process, and it should complete successfully.
Final Thoughts
This upgrade isn’t about chasing perfection — it’s about practicality. The server isn’t new. It’s not running the latest hardware. But with the new drives and storage layout, I'm hoping it will performs better, runs smoother, and keeps the workflow efficient enough to keep building, testing, and learning.
It’s not lightning-fast, but it’s “fast enough,” and sometimes that’s all you really need in a dev environment. So that’s it for this one. As always — stay geeking, stay curious, and I’ll see you guys on the next one. Peace!
