Getting rid of RAID1

    • Offizieller Beitrag

    I want to transform my RAID1 (ext4) to two individual disks. Doing do so I would like to avoid

    • copying data back and forth
    • having to adjust the configuration of shares, UrBackup and Crashplan (especially Crashplan is a pita)


    To do so, I would do following:

    • remove one of the disks of the array in the GUI; I will end up with a degraded RAID1
    • from CLI: reduce the size of the array to one disk with mdadm --grow /dev/md127 --raid-devices=1 --force
    • after a refresh the GUI of OMV should show a clean single-disk-RAID1 with the same mounting point as before (at least it did in a VM)
    • create a new file system on the second disk (probably BTRFS)

    Did I miss any issues I might face?

  • Re,


    yeah: you have to zero the superblock of the removed drive ... you can use this documentation:
    https://access.redhat.com/docu…raid-manage-removing.html


    Btw. i'm unsure, whether your command is working as you expect ... i would go with the RedHat-Docu, please adjust it for yourself to fit RAID1.


    EDIT:
    something was missing in the link above - so here is a better one:
    https://unix.stackexchange.com…g-reinstalling-the-system


    Good luck!


    Sc0rp

    • Offizieller Beitrag

    Thanks Sc0rp.
    If I create a new filesystem on the removed drive, removing the superblocks should not be necessary, right?


    On the remaining drive I cannot remove the superblocks. If I do so the mount point will be different, right?
    Currently my mount point is /media/<UUDI>
    if I unmount and mount will it stay like this or will it be mounted in /srv/dev-disk-by-id....

  • Re,

    If I create a new filesystem on the removed drive, removing the superblocks should not be necessary, right?

    May be, i would do it for safety anyway ... some HDDs have Problems with removing or adding superblocks (you can also zero the first Bytes via dd, this is the safest solution to get rid of ALL RAID-related data).


    On the remaining drive I cannot remove the superblocks. If I do so the mount point will be different, right?

    Nope ... but no, superblock is the DCB (disc controller block) of the software-raid implementation under linux (aka md), which stores (internal) information of a raid-array. Mountpoint can be part of this, but is likely overwritten by the OS (remember: often users ask for vanished raid-arrays, but they moved from /dev/md1 to /dev/md127 due to a bug).


    md_Arrays should be autodetected by Debian (or any other Linux), but the mountpoint is written in the /etc/fstab (using the UUID i hope :P).


    Currently my mount point is /media/<UUDI>

    The /media dir is used for "removable" drives ... and yes OMV changed his behavior to mount the data-drives from v2 (/media) to v3 (/srv) to met the FHS ...


    if I unmount and mount will it stay like this or will it be mounted in /srv/dev-disk-by-id....

    Depends on /etc/fstab !


    Sc0rp

    • Offizieller Beitrag

    Here is, what I did:

    • removed one of the disks of the array in the GUI (sdc in my case); I ended up with a degraded RAID1 --> ok at this stage
    • from CLI: reduced the size of the array to one disk with mdadm --grow /dev/md127 --raid-devices=1 --force
    • after a refresh the GUI of the GUI OMV showed a clean single-disk-RAID1 with the same mounting point as before
    • deleted superblock on the second disk with mdadm --zero-superblock /dev/sdc (if the superblock is not zeroed the single-disk-RAID1 will not be detected during reboot as there is a conflict between the two superblock information on the two disks)
    • create a new file system on the second disk


    Seems ok so far. All services seem to work as before.

    • Offizieller Beitrag

    I want to transform my RAID1 (ext4) to two individual disks. Doing do so I would like to avoid

    • copying data back and forth
    • having to adjust the configuration of shares, UrBackup and Crashplan (especially Crashplan is a pita)

    How has your experience with UrBackup been? What do you think? (Just curious.)
    ___________________________________________________


    For what I've been doing, I'm really happy with it. Full (bare metal) restorations are easy (even Windows on UEFI), no problems with file restores, decent security and network options, and it operates in the background on the client and server without killing performance on either end.


    I've seen high end commercial products that don't work as easily or as well.

    • Offizieller Beitrag

    Exactly. Fully agree with your evaluation. I like especially the background operation. You hardly notice when a backup is in progress. Positive is also the versioning of files. It is really easy to restore previous versions of a file.


    So far I have not tried to backup the backup to an external location (with own versioning). For that you would probably backup the "current" folder and make sure to follow the symlinks.

Jetzt mitmachen!

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