Posts by henfri


    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


    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.




    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:

    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.



    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.



    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





    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.




    thanks for your reply.

    So also that looks correct.

    So, that would be a bug, I should raise at ?

    Does it make sense, that the wrong prefix length is the cause for the "network unreachable" during my ping test?




    I have configured IPv6 like this:

    But this leads to

    eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
    inet netmask broadcast
    inet6 2003:cb:9722:xxxx:xxxx:xxxx:feaa:27bb prefixlen 128 scopeid 0x0<global>
    inet6 fe80::xxx:xxx:feaa:27bb prefixlen 64 scopeid 0x20<link>
    ether 00:22:4d:aa:27:bb txqueuelen 1000 (Ethernet)
    RX packets 51101574 bytes 4896156245 (4.5 GiB)
    RX errors 0 dropped 330892 overruns 0 frame 0
    TX packets 52828687 bytes 68346030934 (63.6 GiB)
    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
    device interrupt 20 memory 0xf7d00000-f7d20000

    You can see, that the prefixlen is wrong.

    This leads to 'network not reachable':

    connect: Network unreachable

    I also do not find this configuration in /etc:

    root@homeserver:/etc# grep -r "2003:cb:9722"
    hosts:22003:cb:9722:xxxx:xxxx:xxxx:feaa:27bb homeserver
    issue:eth0: 2003:cb:9722:aaaa:bbbb:cccc:feaa:27bb
    netplan/20-openmediavault-eth0.yaml: - 22003:cb:9722:xxxx:xxxx:xxxx:feaa:27bb/64
    openmediavault/config.xml: <address6>22003:cb:9722:xxxx:xxxx:xxxx:feaa:27bb</address6>

    What could be the reason for these issues?



    Many docker apps store frequently variable data and metadata. Perhaps in a database. This may lead to random writes. Examples are torrent download clients or media managers with frequently updated metadata.

    That has nothing to do with docker then, but with the application.

    Docker allows separating data and application (images).

    Anyway: SMR only suffers from without interruption. The applications you mentioned should be no issue.

    And it is the first time I hear the claim that Flash is more robust against writes than a HDD...