Migrating from SnapRAID to ZFS

    • OMV 4.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Migrating from SnapRAID to ZFS

      Hi,
      My current setup is an HP Microserver Gen7 home server with 4 bays running ext4+SnapRAID+mergerFS in the following configuration:
      Data(3TB + 3TB + 2TB) + Parity (3TB)

      I have no way to backup the 7TB of data. These are mostly media files that I would rather not lose, but aren't valuable enough to justify another 8TB array for backup.

      The drives are 80% full and I'd like to upgrade the 2TB to 3TB and at the same time convert to ZFS (4x3TB in RaidZ1) without losing data.

      This is how I plan to do this:
      1) Wipe the Parity drive and format to ZFS Raid0.
      2) Copy contents of Data1 to new ZFS1.
      3) Wipe Data1 and format to ZFS Raid0.
      4) Copy contents of Data2 to new ZFS2.
      5) Wipe Data2 and format to ZFS Raid0
      6) Copy contents of Data3 to new ZFS3.
      5) Wipe Data3 and format to ZFS Raid0
      6) Format new drive to ZFS Raid0
      7) Finally create new zpool with all 4 ZFS drives

      Is this the correct way to do the migration ? Is there a better way ?
    • no.

      because in step 7 you lose all data in ZFS alone drives.

      good way:

      have a backup.
      destroy your pool
      create ZFS pool
      copy data from backup.
      OMV 3.0.96 x64 on a HP T510, 16GB CF as Boot Disk & 32GB SSD 2,5" disk for Data, 4 GB RAM, CPU VIA EDEN X2 U4200 is x64 at 1GHz

      Post: HPT510 SlimNAS ; HOWTO Install Pi-Hole ; HOWTO install MLDonkey ; HOHTO Install ZFS-Plugin ; OMV_OldGUI ; ShellinaBOX ;
      Dockers: MLDonkey ; PiHole ;
      Videos: @TechnoDadLife
    • other bad thing is that your desired config: Data(3TB + 3TB + 2TB) + Parity (3TB) is artificially reduced to 2TB+2TB+2TB=6TB of usable data, because you have only one 2TB disk in the Zpool.

      in fact if you replace this 2TB disk in the future , your pool grow automatically to 3+3+3= 9TB of usable data.


      please consider first to have a backup of your valuable data prior to migrate to any type of raid or ZFSPool.
      OMV 3.0.96 x64 on a HP T510, 16GB CF as Boot Disk & 32GB SSD 2,5" disk for Data, 4 GB RAM, CPU VIA EDEN X2 U4200 is x64 at 1GHz

      Post: HPT510 SlimNAS ; HOWTO Install Pi-Hole ; HOWTO install MLDonkey ; HOHTO Install ZFS-Plugin ; OMV_OldGUI ; ShellinaBOX ;
      Dockers: MLDonkey ; PiHole ;
      Videos: @TechnoDadLife
    • Nibb31 wrote:

      4x3TB in RaidZ1
      Not a great idea especially with older disks in Linux/OMV. Once a disk in your array dies you have zero redundancy any more. Replacing the drive the following resilvering will take ages since ZFS on Linux does not implement 'sequential resilver' but does this in a fashion that could be best described as 'worst case random IO scenario' possible. So when your fist disk died of age please be prepared that most probably another one will follow soon as a direct result of the resilvering stress...
    • raulfg3 wrote:

      other bad thing is that your desired config: Data(3TB + 3TB + 2TB) + Parity (3TB) is artificially reduced to 2TB+2TB+2TB=6TB of usable data, because you have only one 2TB disk in the Zpool.
      Thanks,
      Yes, I am planning to replace the 2TB (which is my oldest drive) with a 3TB.

      The valuable data (about 1TB) certainly is backed up. It's the media data that isn't. As I said, it would be a pain to lose it, but it isn't valuable enough to justify spending several hundred euros on a backup solution.

      tkaiser wrote:

      Nibb31 wrote:

      4x3TB in RaidZ1
      Not a great idea especially with older disks in Linux/OMV. Once a disk in your array dies you have zero redundancy any more. Replacing the drive the following resilvering will take ages since ZFS on Linux does not implement 'sequential resilver' but does this in a fashion that could be best described as 'worst case random IO scenario' possible. So when your fist disk died of age please be prepared that most probably another one will follow soon as a direct result of the resilvering stress...
      Isn't this true for any kind of RAID 1 or 5 ? Since my hardware only has 4 bays, I won't be using RAID6. This is a home server on a budget and I can't afford to "waste" 50% of my drive capacity.

      Also, the drives are various ages (1 to 4 years) and various brands (Toshiba, WD Green and Blue), which limits the risk of them having the same MTBF.
    • Nibb31 wrote:

      but it isn't valuable enough to justify spending several hundred euros on a backup solution
      A 8TB HDD is 200€ currently :)


      Nibb31 wrote:

      Isn't this true for any kind of RAID 1 or 5 ?
      No.

      With RAID-1 or any sort of (z)mirror there's not that much stress involved when replacing a failed mirror member. All that's happening is sequentially reading one disk and transferring the contents to the other disk (HDD are good with sequential IO but suck with random IO). This has also some benefits compared to running RAIDz1 or RAIDz2 that are worth the additional costs: jrs-s.net/2015/02/06/zfs-you-s…e-mirror-vdevs-not-raidz/

      With a traditional RAID5 it's a bit more stress than a RAID-1 and while a rebuild is running array performance degrades drastically. With a 4 disk RAID-5 when rebuilding data from 3 disks is read, parity information is recalculated and written to the new array member. Still in a linear/sequential fashion since the rebuild will simply read from block 0 to last block on all disks.

      With RAIDz on Linux it's different since ZFS resilvering is not looking at blocks (simply walking through the whole array) but the resilver process is processing filesystem metadata and walking along the btrees. The smaller your files, the higher disk fragmentation and the more snapshots the longer this can take then. See some reports and the referenced Issue at the end: github.com/zfsonlinux/zfs/issues/1110#issuecomment-10833258

      To my knowledge this still is an issue with ZoL. See how Solaris folks addressed this as this is also sums up nicely why it's so slow if not done in a more 'sequential' fashion: blogs.oracle.com/roch/sequential-resilvering
    • Nibb31 wrote:

      Also, the drives are various ages (1 to 4 years) and various brands (Toshiba, WD Green and Blue), which limits the risk of them having the same MTBF.
      The MTBF number is a statistical value and with just 4 disks you're not affected by statistics anyway. Any drive can die instantly or live much longer than some statistical average value would suggest. Statistics gets interesting once you use tens of thousands of disks since now those numbers start slowly applying to your installation.
    • Ok, I think I might have figured a way to do the migration without investing in an extra 8TB of storage (yeah, I'm cheap, and $200 is more than I want to spend on this data).

      Right now I have:
      3TB DATA1
      3TB DATA2
      2TB DATA3
      3TB PARITY

      Let's say I buy a 4TB drive to replace the 2TB. I also have a spare 1TB drive sitting around. This is the plan:
      1) Copy DATA1 and DATA2 to the new 4TB, the 1TB spare and what's left on the 2TB. This should cover it.
      2) Wipe DATA1, DATA2, and PARITY.
      3) Create a degraded ZFS RAIDZ1 using 3 drives (is this possible ?)
      4) Copy the backup drives to the RAIDZ1
      5) Wipe the 4TB, add it to the RAIDZ1 (using only 3TB but future proofing), and resilver.

      This plan relies on the possibility of creating a degraded RAIDZ1. Would this work ?

      The post was edited 1 time, last by Nibb31 ().

    • Nibb31 wrote:

      3) Create a degraded ZFS RAIDZ1 using 3 drives (is this possible ?)
      AFAIK not. When creating the pool the amount of members is fixed. Though you can immediately after creation offline one RAIDz1 member but then have no redundancy any more.

      As already said I still don't think RAIDz1 is a good idea for the simple reason that once the first disk fails the resilvering might kill another one. I would most probably use a multi device btrfs without redundancy than can be grown at any time. So you can add disk by disk to the btrfs even without the need to rebalance in between. Very low disk stress...

      And once RAID5/6 inside btrfs are considered stable you can add another disk and run a rebalance to have redudancy for whatever reason :)
    • I don't believe we'll ever see stable btrfs RAID-5/6 at this point. I'm not willing to commit to it now and cross my fingers that it will arrive next year or in 5 years or never.

      I also don't want to go without any redundancy at all, so a btrfs JBOD with no redundancy, as you suggest, is out. And I don't want to "waste" 50% of my disk space on replication like RAID1 or a full 9TB rsync backup. Remember, this is a home media server on a budget.

      Really, a 4-drive RAID5 is the sweet spot of data/parity ratio that I'm after for this application. I'm just wondering if there is a better option out there than the ext4+SnapRAID+mergerfs combination that I currently use.

      What do you think of mdadm RAID5 with a btrfs filesystem on top ? I think this is what Synology uses.
    • Nibb31 wrote:

      I also don't want to go without any redundancy at all
      How is your strategy when a disk dies? Are you willing then to buy a large drive first to backup your data or do you run full risk mode and try to resilver your RAIDz1? You have no redundancy then and resilver rates can be horribly low for the reasons already explained (no sequential resilver als Solaris does it). The probability that the setup wasting one disk for redundancy only ends up in total data loss is pretty high. With a btrfs multi device setup when a disk failure occurs you loose only the data on the affected disk. Since I deal with (failing) RAID now for over 2 decades I would choose the variant that allows for less data loss if no backup is existent.

      RAID-5 with btrfs allows for less disk stress in case a rebuild needs to be done but a lot of those nice features of modern attempts like btrfs and ZFS will simply not work (eg. when both fs run directly on top of the hardware they can deal much better with stuff like bad blocks).I wouldn't use RAID-5 anyway but have to admit that I'm totally biased here :)