ZFS Resilver Time Calculator for Home Servers

The silence of a healthy ZFS pool can be deceiving. It’s easy to forget just how hard the drives is working until one fails. When a drive does fail, it kicks off the rebuild timer and it makes home server owners anxious. Will the new disk finish its repair before the next one fails? This means losing data, which in this case would of been a disaster.

Knowing the reason behind the wait helps transform passive dread into active management. A lot of folks think ZFS will copy all the bytes on the bad drive, which isn’t generaly accurate. Unless you initiate a full scan or add another mirror, it won’t even walk the block pointers for blocks where there’s nothing, just those with actual data. You might have an eight-terabyte pool containing four terabytes of files. So the amount of stuff you’re rebuilding is more like four terabytes.

Why ZFS Rebuild Takes So Long

That’s important because the tools tell you how long it’ll take based off more than just how much space you purchased. It also use your disk speed and vdev configuration to estimate how much data really needs copying. In short: What you store is more important for rebuild time than how much storage you purchased.

The speed penalty depends on your pool setup. Rebuilds should be roughly native-speed for mirrors. They are fairly permissive because any surviving mirror can pull data. For a RAIDZ config, rebuilds read both data and parity blocks, increasing overhead. The wider your RAIDZ array, the more drives it has to deal with, and the more complex its parity calculations, making it worse. Expect to notice the efficiency difference in the estimated time; wide RAIDZ arrays (even with the same data as a mirror) may take considerably longer then.

Workloads reduce rebuild performance by interfering with it. In most cases, a ZFS rebuild doesn’t interrupt file service. That is, your VMs will still run and your photo backup will complete while a disk is being repaired. However, the background repair consumes some of your disks I/O bandwidth, which competes with other tasks (like backups). To model that, use “percentage of disk load” field in the calculator. If a lot of clients are accessing the storage, then the time for rebuilding will increase (the background process will be throttled). Most admins reschedule their rebuilds for off-peak hours or temporarily suspend demanding tasks to give the pool enough breathing room so it can recover to redundancy as fast as possible.

Metadata configuration and disk geometry also matter. More blocks = more metadata for ZFS to scan across in order to perform repairs. For example, you’ll get worse performance resilvering a pool containing millions of tiny files (e.g., MySQL database) compared to repairing a pool full of large video archives, despite both pools having the same number of gigabytes. The ashift parameter makes sure the filesystem is lined up with the underlying drive sector(s), avoiding unnecessary read-modify-write cycles and saving some time. If you get this correct at deployment time, it will help when disaster come.

What does this mean? By having some idea of rebuilding time, you don’t have to suffer it, instead, you can manage it. Twenty hours sounds like something you could schedule around; days feels like a good time to re-evaluate your redundancy strategy (or switch to faster disks) so you won’t be in this pickle again.

The objective is to get your busted drive fixed ASAP, and limit your exposure to “no data has a safety net” mode. Using resilver time as a planning metric stabilizes your home server. It reliably hums along but now you know the cost.