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.

    Thanks, I understand, but I have no way of backing up the 7TB of media data.


    If there is no other way, then I guess migrating to ZFS is not an option and I'll stick to my SnapRAID array.

    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.

    Zitat von Nibb31

    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...

    Zitat von raulfg3

    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.

    Zitat von tkaiser

    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.

    Zitat von Nibb31

    but it isn't valuable enough to justify spending several hundred euros on a backup solution

    A 8TB HDD is 200€ currently :)



    Zitat von Nibb31

    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: http://jrs-s.net/2015/02/06/zf…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: https://github.com/zfsonlinux/…110#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: https://blogs.oracle.com/roch/sequential-resilvering

    Zitat von Nibb31

    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 ?

    Zitat von Nibb31

    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.

    Zitat von Nibb31

    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 :)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden