4 ms·
> The neat part is that I did it with only three additional 8 TB disks and never transferred my data to external storage. That's neat! I didn't know there was
by xmodem 1y ago
> The neat part is that I did it with only three additional 8 TB disks and never transferred my data to external storage.
That's neat! I didn't know there was a way to do this while maintaining data redundancy.
> Step 1: Borrow one disk to create a RAIDZ2 pool
> To begin, I remove one disk from my original RAIDZ1 pool, leaving it in a degraded state.
Oh, there isn't. :facepalm:
- mtlynch 1y agoWhat's the issue? I have backups, so I was prepared for data loss if the pool failed. Is this any riskier than recovering from a single disk failure on a RAIDZ1 pool?
- SirMaster 1y agoThen why go through all this trouble at all? 1. Build new RAIDZ2 pool with all your disks that you plan to use. 2. Restore backup to the new pool. I keep a backup too and so this is how I move to a new larger ZPOOL with a new layout. Either you have to do this because you don't have a backup, and so this is risky. Or you don't need to do this because you have a backup and can just build your new pool and restore your data from the backup.
- mtlynch 1y agoI address this in the post: https://mtlynch.io/raidz1-to-raidz2/#step-2-backing-up-my-data https://mtlynch.io/raidz1-to-raidz2/#step-2-backing-up-my-da...
- xmodem 1y agoNo issue. Just that the introduction to your post got me excited that I was going to learn how to do something I didn't previously think was possible.
- mtlynch 1y agoAnother reader suggested a different way that achieves the same thing but avoids degrading the pool. You keep the raidz1 pool healthy, create a 5x8TB raidz2 pool with two fake disks, migrate the data, and then only pull the disks from the raidz1 pool when the data successfully migrates. Even if a disk dies during reslivering on the raidz2 pool, you still have 3 of your 4 disks in the raidz1 pool.
- benlivengood 1y agoAdministrative risk, mostly. If you accidentally wipefs the wrong disk when moving it to the RAIDZ2 pool or offline a real disk instead of a tmp disk or make some other simple mistake then a zpool might be unrecoverable. An alternative would have been to build a RAIDZ2 out of three new disks and two tmp files and then copy the data over and finally offline a RAIDZ1 disk and online it on the RAIDZ2 zpool. Two copies of the data in each pool would require an actual disk failure in both zpools to lose data during the resilvering (even though both were degraded), and when breaking the original zpool to add a replacement disk for the 5th device in the RAIDZ2 pool you'd have to lose two existing disks in that pool to lose data. No criticism; it's cool to be able to do moves with minimal resources and I've also thought about potential ways to upgrade zpools under weird constraints; especially no free SATA ports for example. I had thought about using the four SATA ports to copy data from half the source disks in a RAIDZ2 to half the destination disks of a new RAIDZ2 while the removed disks would still be a functional zpool on their own as a backup. But ultimately I found a cheap extra box and went for a complete upgrade to larger disks with the benefit of keeping the old box as a local mirror. My upgrade was from a single RAIDZ2 of 4x 4TB disks (8 usable) to a RAIDZ1 of 4x 14TB disks (42 usable) because once both pools existed I was comfortable running the old disks in a 12TB RAIDZ1 to receive snapshots from the primary zpool while I had <12TB used. Still requires 2 disks to fail to lose data, and now I do some offsite backups as well (rsync and s3backer) and have a test system to perform upgrades on before the main system.