How to restore OMV 4.X from backup-plugin to system SSD

  • The non-ddfull options do not backup a large enough chunk for uefi or the RPi

    Is there any way to backup missing chunks for UEFI manually? I'm using an x86 motherboard, not a RPi.


    I assume you are using a large OS disk and putting data on it and that is why you don't want to use dd full?

    Yes, my SSD is 240GB, so ddfull occupies around 190GB and takes a lot of time to finish the job. Since there is no possibility for incremental backup in this case, it will require a lot of storage to keep these images. I don't know if I really need daily backups, but even performing backups on a weekly basis will end my free space very quickly.


    Images created by Clonezilla or fsarchiver are relatively small ~4GB since they contain only actual data. The disadvantage of Clonezilla is obvious since it allows only manual backups with the server restarted into the Clonezilla kernel. As I said earlier I managed to restore fsarchiver image only on a freshly installed OMV. Please note, that all tests were done on a VM on my working machine, I didn't want to interrupt my main server. Of course it started with a lot of errors, but still I could track all my dockers with some of them running correctly (the ones which don't require other disks).

  • Is there any way to backup missing chunks for UEFI manually? I'm using an x86 motherboard, not a RPi.

    Sure, just dd a larger portion of the beginning of the disk. I think it is normally 2MB but I need to check.


    I don't know if I really need daily backups, but even performing backups on a weekly basis will end my free space very quickly.

    That is why the plugin allows you to delete old backups. Set the keep backups to 1 day and you won't fill your drive.

    omv 5.5.17-3 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.4.2
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Sure, just dd a larger portion of the beginning of the disk. I think it is normally 2MB but I need to check.

    I found even more elegant solution using the sgdisk tool. It easily backups/restores GUID Partition Table disks. It contains only 18KBytes of data. It allowed me to restore the partition table, but further applying fsarchiver command did not restore the OS, each boot still ends in the EFI shell. Even after reinstalling grub manually.


    Set the keep backups to 1 day and you won't fill your drive.

    There are three problems I can see here:

    1. In my opinion 1 day backup is not enough for safety reasons.

    2. It takes a lot of time to copy entire disk, especially of a working OS. I think it took around 5 hours and stressed a lot of my weak processor. I'm not worried about the CPU itself, but other tasks that might be delayed during high load.

    3. I'm backing up the main drive to the same NAS (different disk) which is obviously a bad idea, unless I were not backing up this data to another storage afterwards. The problem here that my upload link is limited by 5Mbit/sec (bits, not bytes) and to upload an image of this size (190GB) will occupy all my bandwidth for a looong time. Keep in mind I have other disks being backed up (incrementally) on a daily basis . So I need a more elegant solution which occupies significantly less space.

  • found even more elegant solution using the sgdisk tool. It easily backups/restores GUID Partition Table disks. It contains only 18KBytes of data. It allowed me to restore the partition table, but further applying fsarchiver command did not restore the OS, each boot still ends in the EFI shell. Even after reinstalling grub manually.

    I was looking at sgdisk as well. I may add that on all backups because it doesn't hurt either way.


    There are three problems I can see here:

    1. In my opinion 1 day backup is not enough for safety reasons.

    2. It takes a lot of time to copy entire disk, especially of a working OS. I think it took around 5 hours and stressed a lot of my weak processor. I'm not worried about the CPU itself, but other tasks that might be delayed during high load.

    3. I'm backing up the main drive to the same NAS (different disk) which is obviously a bad idea, unless I were not backing up this data to another storage afterwards. The problem here that my upload link is limited by 5Mbit/sec (bits, not bytes) and to upload an image of this size (190GB) will occupy all my bandwidth for a looong time. Keep in mind I have other disks being backed up (incrementally) on a daily basis . So I need a more elegant solution which occupies significantly less space.

    I think borgbackup is the best option. It compresses and dedupes and is incremental after the first backup. I run it arm boards and the cpu load isn't bad.

    omv 5.5.17-3 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.4.2
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Do you think it will solve my issue with grub boot loader?

    No because borg is only backing up files. The boot loader stuff is the same. I just haven't had any time to do anymore work on this. Other than time, is there any reason restoring over a fresh install is not good enough?

    omv 5.5.17-3 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.4.2
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Finally succeeded in restoring the system with fresh install avoided!


    1) First of all one has to restore GPT table using, for example, sgdisk tool. Then fsarchiver tool has to be applied to both boot and main partitions accordingly to the archive structure.

    2) After that I tried to apply a restore process of boot loader according to Ubuntu help page.

    • I mounted the main system as /mnt, then the boot partition was mounted as /mnt/boot/efi.
    • Next I applied the following command: for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done which mounts the critical virtual filesystems (according to the help page).
    • Then I chrooted the OMV and applied grub-install. Actually I had to specify full path: /usr/sbin/grub-install, otherwise command was not found. Probably there were some problems with PATH variable.
    • After /usr/sbin/update-grub ended successfully I exited chroot and did a restart. Unfortunately system rebooted into EFI shell of virtualbox.

    Nevertheless I tried to run grub manually by entering the corresponding partition (EFI/debian) and locating grubx64.efi file. Running this file manually I managed to enter the boot loader and the system was able to start. In the terminal. I repeated last two short commands (without specifying full path) which resulted in restored grub loader. It seems that everything described in step 2 is not necessary at all and can be skipped.


    At the moment it can be considered as a win, I assume!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!