Omv backup

  • How many threads do I have to make without answer - before I get an answer to how to backup my odroid xu4 emmc / omv4 installation? It's not fun to put it all over again because the emmc fails and I can not get a response How do I backup?!

    • Offizieller Beitrag

    I can make a suggestion:
    Booting from a device that's not easily replaceable (without a cloned spare in hand) is not a good idea. Because, as you've noted, rebuilding/reconfiguring is not anyone's idea of fun.


    Personally, I don't own an Odriod so I don't know what their idiosyncrasies are. Regardless, "IF" an Odroid will boot from a USB thumbdrive, this guide has easy to follow instructions you could use for cloning USB boot drives. This could provide you with solid OS backup.


    (For follow up purposes, I'll be out of town until next week end, starting tomorrow.)

  • Thanks for the guide :) I have an Emmc card that I can put in usb card reader as I have but the problem is that if you use Win32DiskImager on a 16 gb emmc it will not be possible to write that backup on an SD card of 16 gb when they vary in size despite both of which is 16 gb I have heard? - It's a bit inconvenient to copy the entire card both blank and data: / :(


    There is a bit about the problem here with a size difference of 2 sd cards of 16 gb:


    https://openenergymonitor.org/forum-archive/node/5079.html

    • Offizieller Beitrag

    At 8GB (or even less), the majority of space on an OMV boot drive is unused (in most cases). If you down load Gparted live, and burn it to a CD, you can boot onto the CD at a standard workstation with USB slots. Gparted will resize partitions and consolidate empty space on solid state devices such at your emmc, USB thumbdrives, SD-cards, etc.


    With Gparted to resize partitions, reducing them somewhat, the contents of your emmc (and the resultant image file) should fit on the destination USB thumbdrive (or whatever you want to use) of a roughly similar size. From the guide on cloning: if the sizes are only slightly dissimilar, Win32Diskimager can ignore the difference. (There's a dialog prompt - select "ignore".)


    However, after you get the contents of your emmc onto a USB drive (and the clone successfully boots up), future cloning will be much easier if reading and writing images to identical devices.
    The path of least resistance would be to have two devices of the same brand and size for cloning and if they're at least slightly "larger" than your emmc, there shouldn't be any problem at all. For example, if your emmc is 16GB and your USB thumbdrives are 32GB, you'd be fine.
    ______________________________________________________________


    Lastly, and you may hate these ideas:
    - If your emmc is removable/replaceable, you could buy the identical item. Cloning the two, with a USB adapter, should be a breeze (But, as I've noticed, Odroid emmc's seem to be a bit on the expensive side. )
    - With two identical USB thumbdrives in hand, if you had to rebuild, you'd only have to do it one last time.
    I''ve been using the cloning process documented in the guide for a few years. While I've swapped out a non-booting SD-card or two over that period (they were cheap generic's - not worth a dime), I've NEVER had to rebuild, and having cloned backups on hand has allowed me to gracefully back out of package additions that fouled things up and software upgrades that went sideways.


    In any case, if using emmc's, USB thumbdrive's, SD-card's, etc.:
    If you want your solid state boot media to last, you should install the flashmemory plugin. There's detailed instructions for that in the guide as well.


    Let us know how it goes.

  • if you use Win32DiskImager on a 16 gb emmc it will not be possible to write that backup on an SD card of 16 gb when they vary in size despite both of which is 16 gb I have heard?


    Your question is not related to OMV at all but deals with one layer below: Armbian today for all OMV images.


    In Armbian I switched two years ago from partitioning the whole device to an approach leaving a small spare area (5% with 4 GB cards, 2% with 8GB and 1% above). For the simple reason to allow cloning of such cards since as you already mentionend: 16 GB are never the same when using different products. If the destination is smaller in size (very unlikely when the source was eMMC) you'll get an error message but since the partition will fit you can ignore the error.


    With OMV we use Armbian's behaviour to control the size of the partition: the OMV images from early last year only resized the main partition to 3.9GB, the later ones to 7.3 GB. Cloning such an installation will therefore work with every 8GB SD card or larger.


    In other words: the problem is already solved when you use an OMV image that is somewhat recent. But there's another problem with the XU4 eMMC: these eMMC modules contain the bootloader on a hidden partition you can't access from another host (e.g. your Windows machine where you want to use Win32DiskImager). In theory it should work to clone the whole eMMC since our images contain the bootloader again at another location. But I never tested this (and I really wonder why you don't test this on your own?)


    My attempt is a different one: I always create compressed images. There exist tons of threads over at Armbian forum where this is covered, e.g. https://forum.armbian.com/topic/7332-image-backup-how-to/ (you better join Armbian forum for such 'low level' stuff since here you get highly misleading answers due to many OMV users not familiar with SBC -- or only crippled/weird variants like the Raspberry Pi)

  • If you want your solid state boot media to last, you must install the flashmemory plugin


    Active by default on all SBC OMV images. The whole 'different size' problem is none.


    ODROID XU4 can not boot from USB (this will never change since the Samsung SoC can only deal with MMC but not with SPI flash so unlike most other SBC where you can put the bootloader on some cheap SPI NOR flash this will never work with ODROID XU4/HC1/HC2)

  • But now I have found a solution that works well on "odroid devices":


    forum.odroid.com/viewtopic.php?f=52&t=22930


    Good luck. The only definition of a 'working backup' is a TESTED restore that worked flawlessly. Funnily the majority of people forgets about this and does backup for no reason. Also 'live backup' is IMO just asking for troubles (it's stupid trying to clone partitions where a running OS lives on without something like snapshots to freeze the filesystem. And even with snapshots open files like databases can't be cloned in a sane way. Without special precautions -- see https://en.wikipedia.org/wiki/Shadow_Copy for an example what's NECESSARY -- this will only result in slight data corruption that won't get noticed until it's too late).


    My personal recommendation (and how I do it personally): Offline cloning of SD cards or eMMC since 'live backup' is a great way to fool yourself. I never did offline cloning with Win32DiskImager since I'm not using Windows (so I don't know how limited this tool is wrt assumptions about the size of source and destination -- als already explained above with appropriate tools you can clone your OMV installation easily to every SD card of 8 GB in size or larger).


    Using ddrescue on macOS or Linux doing this is pretty easy.

  • Nor did I take a live backup I made a sd card with a clean debian stretch installation and then booted on it and used the script to backup emmc card that way it's not active :) - I do not have mac but only a machine with windows 10 :)?

    • Offizieller Beitrag

    How many threads do I have to make without answer - before I get an answer to how to backup my odroid xu4 emmc / omv4 installation?

    Really? The xu4 is not different than other systems. Just because a backup solution does not say "xu4" does not mean it won't work.


    The developers of Omv should focus on making an easy way via the interface to back up their system, it's quite essential that you can do that - so fun it is not to install Omv4 over and over again.

    There has been plenty of advancement in this area. OMV 5 should have a good way to restore a config but I added fsarchive as an option to the OMV 4.x version of the backup plugin. This avoids the "problem" of the restore problem when cards are slightly different sizes (not sure why you are restoring to different type of media though). There are a few posts describing the restore. Windows doesn't have a config restore option nor would the media size problem be fixed either.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    Is the " flashmemory plugin" installed by default on Omv4 or should I do it?

    @tkaiser pointed this out, previously. The flashmemory plugin is installed by default, in SBC images. It's there and working when OMV boots up. (While I was aware of this, since your Odroid is an SBC, I err'ed in mentioning it in your scenario,.)

Jetzt mitmachen!

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