Posts by henfri

    Hello,


    yes, that is what popped into my mind when lying in bed yesterday... Sorry.

    So, I boot to systemrescuecd, then do a fsck, then a resize2fs.

    Then, I do a mdadm --grow /dev/md0 --array-size 31457216 to shrink the array.

    Then, with mdadm --grow -n 2 /dev/md0 I can reduce to two devices.

    Finally, with mdadm --grow -l 1 /dev/md0 I can change to raid1


    Correct?


    Alternatively... I have a backup (fsarchiver).

    I could wipe the array create a new one and restore into that.


    What would you recommend?

    The second option lets me (for the first time) check my recovery strategy... So I sympatize with it.


    Regards,

    Hendrik

    Hello,


    I had my root-filesystem as raid5. Now I want to switch to raid1.

    I have (had to) remove one drive already:


    Is it now possible to change from this degraded raid5 to a raid1?

    I tried this:

    Code
    mdadm --grow -l 1 -n 2 /dev/md0
    mdadm: Can only convert a 2-device array to RAID1
    root@homeserver:/home/henfri# mdadm --grow -n 2 /dev/md0
    mdadm: this change will reduce the size of the array.
    use --grow --array-size first to truncate array.
    e.g. mdadm --grow /dev/md0 --array-size 31457216

    But when I execute the suggested step, the system gives me an ext4 error.


    Regards,

    Hendrik

    Once I went for the HC4 I had made my mind up to have both backup and original drives on the single HC4 device. I'll just have to take my chance and hope nothing catastrophic happens that would take out both drives.


    It's not the perfect backup solution but I guess "perfect is the enemy of the good" for me on this. Hopefully it will be good enough.


    Thanks for your initial post. I did read it. It gives a good run through of a backup setup.

    Well, the only thing you are protecting against with your current setup is:

    a) One single HDD failure

    b) An accidental delete that you notice very quickly


    Scenarios that you do not protect against:

    1) power surge (e.g. lightning strike)

    2) accidental delete that you notice a year later

    3) Virus/Malware

    4) many others


    What you could improve:

    For 2) do versioned backups (borg-backup, rsnapshot)

    For 3) ensure that only one drive is accessible from other machines. Use different credentials for your linux machine in combination with (2)


    You could also later add an external drive and/or an offsite backup.


    But if your data is valuable, I would not say that what you do today can be deemed "good" (in the sense of the enemy of the better). It is close to no protection, in my view.


    Regards,

    Hendrik

    When when putting the Backup into the same Server as the Original risk of a common mode failure.

    And if you think about it most failures will effect of the original and the backup.


    Furthermore you must make sure that old copies of your data are archived.

    Imagine you accidentally delete files.

    After the next Backup the Backup drive will be synchronised to that otherwise.


    If your data is valuable to you, you must have a offsite Backup.

    An alternative could be an external drive and not all of them are smr (which would be fine for me for backup anyway). Then you must make sure that you manually connect the drive to your server and the power when the backup is run.

    Otherwise Malware or a power surge can kill the original and the backup at the same time


    Greetings,

    Hendrik

    Hello,


    SelfhostedPro

    Thanks for Yacht!

    Indeed I have a feature request (and I know it is a big one):

    The thing that makes portainer hard to use for beginners is:

    1) Docker Slang

    2) No access to Folder Structure of Host

    3) Not directly inside OMV User-Interface


    I have these suggestions:

    1) Maybe via internationalization provide an easy language

    Rather than "Port Mapping": "under wich port do you want to access the application"

    One could even suggest one. E.g. if the port in the container is 9000, check if 9000 is free and propose that as default. Otherwise take N+1 as suggestion

    Rather than "Volumes": "Where do you want to store the data known in the application as /config" (/config is one of the Volumes that the container defines)


    2) Provide Yacht also as *.deb so that it does not have to run as docker container

    - or - one would have to expose "/" to the container

    - or - /sharefolders (because in fact one should only use those)


    3) Would it be somehow possible to integrate Yacht in the GUI of OMV? I think something new is planned for OMV6.


    Regards,

    Hendrik