Btrfs advice on Odroid HC1/HC2

  • Hi !


    I am setting up a new Odroid HC1 with a HDD and I need advice regarding BTRFS file system.


    My use case is this:


    I backup my laptop weekly on a QNAP NAS and I want the QNAP NAS backed up on the Odroid HC1.
    The Odroid will be in another location, connecting to QNAP through OpenVPN.



    I would prefer, if possible, to have snapshots on Odroid.


    My dilemma is what filesystem to choose for the Odroid disk: EXT4 or Btrfs ?


    I'm leaning towards btrfs, because it has checksums and snapshots.


    But I have a few questions regarding Btrfs :


    1. does it really support checksums and snapshots on Odroid HC1?


    2. If Odroid breaks, am I able to read the disk in another linux box and copy the data from it ?


    3. How would I set up notifications for data corruption, disk problems ?


    4. I have read on this forum that the file system can get corrupted beyond repair if the power goes down during write (because some USB controllers will report data being written to disk when it is in fact not). Is this a deal breaker? I don't plan on using an UPS.


    5. how would I configure weekly snapshots for Btrfs ?


    Thank you in advance for your help


    My setup is :


    Armbian 5.85
    Linux odroid 4.14.111-odroidxu4 #2 SMP PREEMPT Wed May 8 17:30:01 CEST 2019 armv7l GNU/Linux
    cat /etc/debian_version
    9.9
    OMV 4.1.22-1

    • Offizieller Beitrag

    From a data recovery or safety perspective there is no reason to prefer ext4 over btrfs. However ext4 may still be a little faster and have wider support. Since btrfs can do much more than ext4 you need to actually learn new stuff to actually make use of those extra features. I still use ext4 on my HC2s...


    If you often have problems with the power supply you should use a UPS. I don't. I have never had any problems with a corrupted filesystem after a power failure or after simply pulling the plug.


    Btrfs may be of limited use on the Odroid HC1/HC2. The reason is that the HC1/HC2 only supports a single hard drive. To take full advantage of btrfs you would like at least two hard drives so that btrfs can automatically fix errors. Without this redundancy btrfs can only tell you when it discovers errors and you will have to fix the bad file manually from a backup. I assume that it means that a file copy/move fail with an error and you will have to look in the logs to figure out exactly why and what file to restore from backup. You could still have duplicate/redundant data on half the single drive to automate this, but that reduces some of the ability to recover when the whole drive fail.


    I currently use ext4 and rsync scripts to create daily snapshot style versioned backups. In effect this is a copy of the original data at a specific time. Rsync can create updated snapshots that reuse the content, using hardlinks, that has not changed since the last snapshot. My script also selectively deletes old snapshots so that I only keep a certain number of monthly, weekly and daily snapshots. This is something that you can also use btrfs to do, only btrfs is much faster and much more efficient when creating snapshots. However you still need to write the btrfs snapshot to another drive to be protected from a hard drive failure and purge old snapshots sometimes.


    To provide full backups with automated bitrot protection using btrfs you would need 4 drives. Two drives to provide bitrot protection for the original data and two drives for the backup and bitrot protection for the backup.


    In principle it is perfectly possible to provide both backup and rudimentary automatic bitrot protection using only two drives, over the network. This can be done by using a database with file hashes and the backup snapshot as redundancy to fix bitrot errors in the original data, and the other way around as well. However at this point in time I am not awear of any backup utility that actually does this.


    I am working on a very simple rsync replacement, "BackBit", that besides creating rsync-style snapshots also can provide limited backup deduplication and bitrot detection and automatic correction for both the original data and the backup copy, using only two drives, possibly over the network, and a database with hashes for the files. It is primarily intended to replace my current rsync scripts running on my Odroid HC2s. But I will most likely be releasing it into the wild as well.


    BackBit would NOT be at all as good or safe as using btrfs to provide full protection. But it would be a great improvement to not providing any protection at all. And it would work fine and safely between single drive Odroid HC2s and HC1s running OMV and NFS. Hopefully...

    Be smart - be lazy. Clone your rootfs.
    OMV 5: 9 x Odroid HC2 + 1 x Odroid HC1 + 1 x Raspberry Pi 4

    2 Mal editiert, zuletzt von Adoby ()

  • 1. does it really support checksums and snapshots on Odroid HC1?

    Sure.


    2. If Odroid breaks, am I able to read the disk in another linux box and copy the data from it ?

    Sure.


    3. How would I set up notifications for data corruption, disk problems ?

    Monthly btrfs scrub and SMART selftest for example. If notifications are enabled you get results from cron jobs via email.

    4. I have read on this forum that the file system can get corrupted beyond repair if the power goes down during write (because some USB controllers will report data being written to disk when it is in fact not). Is this a deal breaker?

    AFAIK not with JMS578 and latest firmware upgrades applied (that's how I operate my HC1 and HC2). And it's not beyond repair since if you're running into this problem there's always the choice to try the usebackuproot option then to recover from such failures. See details here: https://github.com/openmediava…01#issuecomment-466966476


    5. how would I configure weekly snapshots for Btrfs ?

    https://digint.ch/btrbk/

  • Thank you @Adoby and @tkaiser for your help !


    I decided to go with btrfs, since it gives me a little peace of mind with checksums and I can also expand my knowledge.


    Two related questions:


    1. Regarding the snapshots:


    Instead of using btrbk, isn't easier to have a cron job that does something like:


    btrfs subvolume snapshot -r /srv/dev-disk-by-label-DATA/mydata /srv/dev-disk-by-label-DATA/snapshot-190610 ; delete snapshots older than xxx


    Do you see a problem with this approach?


    2. Regarding JMicron firmware:


    I have v173.01.00.01 and I want to update to latest v173.01.00.02. But I am not sure what options to use when doing fw update:


    -nNV – Update without NVRAM. This parameter priority over than “-t”
    -t – Auto spin-down timer. (Unit: minute)
    -u - Enable/Disable SATA Hot-swap function.



    Thank you again for advice !

Jetzt mitmachen!

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