My first Raspberry Pi project.

    • Offizieller Beitrag
    Zitat von chente

    Maybe a preflight check would fix it. If the user has not previously formatted this drive and it is not empty, the restore process does not start. It ends with a "Drive must first be formatted" message, or something similar.

    If someone formats the wrong drive, anyway ...

    I would probably use the same function that populates the list of drives when adding a new filesystem (which means they should be wiped). I will just have to test what kind of issues would be created since the filesystem label and uuid would be the same as the running system.

    omv 7.1.0-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.5 | scripts 7.0.7


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


    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
    Zitat von ryecoaaron

    I would probably use the same function that populates the list of drives when adding a new filesystem (which means they should be wiped). I will just have to test what kind of issues would be created since the filesystem label and uuid would be the same as the running system.

    Yes, I had already thought that. This unit should be dismounted after the restoration is complete, if possible automatically, and the user should be warned that the unit must be removed to anticipate problems with a reboot.

    • Offizieller Beitrag

    Thinking about this problem, I came up with a couple of ideas. I know there are systems (DSM) that have the OS on one partition of each data disk. This allows one of the partitions to be "stopped" and quietly made a copy while the system is running with the other disks. I don't know if there is any way to do something similar.

    Maybe a Raid 1 running OMV. At some point you can disassemble a unit. The Raid would continue to run in degraded mode. You make the copy. Add that unit back to the Raid.

    • Offizieller Beitrag

    If this were possible, an SSD disk could for example be divided into two partitions and create the mirror. While one partition continues to run the system, the other is stopped and can be copied. Then the second partition is mirrored with the first one again.

    While we are discussing backup strategies, may I propose a completely different approach:


    Don't do a backup at all, but create a new OS / boot disk taking the information what to installed from the list of packages in the real OS and copy the config files to the new device. Then install grub onto it.


    Do you ryecoaaron think this is an idea worth to follow up on?

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

    Zitat von Zoki

    Don't do a backup at all, but create a new OS / boot disk taking the information what to installed from the list of packages in the real OS and copy the config files to the new device. Then install grub onto it.

    Exactly what do you mean by "copy the config files to the new device"?

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    I mean, if you do a clean install you do not have the config.xml nor other /etc/... files. Others need to be checked.

    dd creates an identical copy of the boot device and my idea was to create a look-alike which is not a 1:1 copy (UUID, ...) but has the same functionality.


    The more I think about it:

    1. partition the USB-stick
    2. rsync -a /current/boot/partition /new/usb/to_be/boot/partition --exclude= /dev /proc/run /...
    3. install grub

    You get a new bootable USB-stick with your current settings, ...

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

    • Offizieller Beitrag
    Zitat von Zoki

    Do you ryecoaaron think this is an idea worth to follow up on?

    That would be a challenge since just copying config files does not install packages. And unless the user installs the same package versions as the backup, you might run into other issues. This is what has prevented OMV from just recreating a system from config.xml.

    omv 7.1.0-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.5 | scripts 7.0.7


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


    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!

    Don't you have the list of packages available when you do this from a running omv (dpkg -l)

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

    • Offizieller Beitrag
    Zitat von Zoki

    Don't you have the list of packages available when you do this from a running omv

    Yep. You may not be able to get the same version (not in repos) as the backup especially if it is old. I looked into this years ago (hence why the package list file exists). I kept running into issues. That is why the backup plugin started initially as just rsync. To restore, you would install new and then rsync the backup over the new install.


    It would be interesting to re-architect OMV plugins to be saltstack (or better yet - ansible :) ) code instead of .deb packages. Then you could run the "playbook" and it would install the packages and configure everything. That would make things easier.

    omv 7.1.0-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.5 | scripts 7.0.7


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


    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!

    I am not completely with you: If you create the backup boot disk from an updated running OMV, you should be able to get (at least most of*) the packages installed on the system. My approach is different from just copying some config files for later use, it will create a boot disk similair to what dd would do.


    So the process would be (from a running OMV installation)

    1. apt-get update && apt-get upgrade
    2. partition the USB-stick
    3. rsync -a /current/boot/partition /new/usb/to_be/boot/partition --exclude= /dev /proc/run /... (exclude some more)
    4. mount some dirs (/dev /sys/ run, ...) into /new/usb/to_be/boot/partition
    5. chroot into /new/usb/to_be/boot/partition
      1. apt-get update && apt-get upgrade
      2. install grub
      3. exit
    6. unmount the dirs


    * packages installed from

    - downloaded deb files or

    - repos which have been removed from sources.list.d or

    - repos which do not have the installed package any more

    will fail.

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

    I still don't get the point of what it is you are trying to do here.


    I have used dd to make a backup of my live running OMV every single day for more than the last five years. I have repeatedly tested these backups to be sure that they work and I have never, not even once, had a restoration that had any type of problem.


    What are you expecting from your idea that a dd image doesn't deliver?

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    • Offizieller Beitrag
    Zitat von Zoki

    I am not completely with you: If you create the backup boot disk from an updated running OMV, you should be able to get (at least most of*) the packages installed on the system

    Ah, I missed the boot disk part. This would help people who can't boot. But for those who wrecked their system on an upgrade or ran a stupid chmod or accidentally uninstalled/purged the openmediavault package (seen them all), it wouldn't be as useful. This also wouldn't work on arm devices.

    omv 7.1.0-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.5 | scripts 7.0.7


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


    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!

    Zitat von gderf

    What are you expecting from your idea that a dd image doesn't deliver?

    Zero downtime "click-in-GUI" creation of a OS backup disk / stick usabel for those who run windows and can not work with the image file.

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

    dd doesn't require output to an image file. You can output dd directly to another disk or stick.


    As for "click-in-GUI" it may be possible to come up with something that can be added into OMV easily. But I'd just ssh in and execute a script that had the dd one liner in in it.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    • Offizieller Beitrag

    I like the idea of a "clone os disk" option in the backup plugin. I could even make it generic and allow the source and destination disk to be selected for a full disk clone. I suppose it could have some other options like method to clone (dd, etc).

    omv 7.1.0-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.5 | scripts 7.0.7


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


    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!

    Gefällt mir 1
    Zitat von ryecoaaron

    I like the idea of a "clone os disk" option in the backup plugin. I could even make it generic and allow the source and destination disk to be selected for a full disk clone. I suppose it could have some other options like method to clone (dd, etc).

    I think this would be welcomed. Will you be able to make the output disk selection bulletproof such that there is no possibility of unintentionally overwriting the wrong disk?

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    • Offizieller Beitrag
    Zitat von gderf

    Will you be able to make the output disk selection bulletproof such that there is no possibility of unintentionally overwriting the wrong disk?

    I would use the disk select function already in OMV that the create new filesystem feature uses. So, nothing that isn't wiped should show up.

    omv 7.1.0-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.5 | scripts 7.0.7


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


    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
    Zitat von ryecoaaron

    I like the idea of a "clone os disk" option in the backup plugin. I could even make it generic and allow the source and destination disk to be selected for a full disk clone. I suppose it could have some other options like method to clone (dd, etc).

    That would be very helpful. It would end with the typical thread: "How can I make a backup of my system?"

    A question. In case the operating system is on a disk connected by sata, could it be cloned to USB drive and fix boot? And the opposite, from USB to sata?

    • Offizieller Beitrag
    Zitat von chente

    In case the operating system is on a disk connected by sata, could it be cloned to USB drive and fix boot? And the opposite, from USB to sata?

    The cloning process wouldn't care what bus the source/destination disks are on. Whether you can boot from it is up to the hardware.

    omv 7.1.0-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.5 | scripts 7.0.7


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


    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!

    Gefällt mir 2

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden