Cannot connect to OMV7 web GUI: Rpi-clone is not cloning OMV7 nginx web server

  • I’m new to OMV7 and Rpi 5 but have it all working as a NAS and am now moving onto backup and restore of the OS and OMV (not user data as this is all sorted). This is a surprisingly fragmented area but the approach I have working is to take the Rpi offline and to clone the SD card on a Windows machine to another. If the SD card fails or the OS or OMV gets corrupted, I simply use the backup SD cards for booting. This has been tested fine.


    Obviously, this is very tedious and is only as current as the last offline clone so I want an online hands off solution that can run frequently. The “rpi-clone” utility now maintained by Jeff Gerling at https://github.com/geerlingguy/rpi-clone seems promising as it aims to clone the boot SD card and contents (such as OMV) to another SD card or USB thumbdrive and can be run as a crontab job. I aim to have an SD card sitting in a USB SD card reader running a clone of the OS boot disk every say hour.


    After cloning using rpi-clone and booting from the newly burnt SD card, all seems promising: I can ssh logon however the OMV web page at the same IP address will not connect so I can’t get into OMV. For disgnostics I run omv-firstaid from the ssh logon. Option 7 is ok – “The configuration status file is valid”. Option 8 is ok – “All RRD database files are valid.” But when running option 3 to Configure the OMV Workbench I return a number of nginx errors thus:


    Clearly, the rpi-clone utility is at fault and out of scope here but I'm hoping that someone could help with a suggestion for restarting / fixing nginx in this state? Or any recommendations for a better solution?


    Btw, I have tried other solutions such as native "dd" and the OMV clone plug-in with poor results.

  • chente

    Approved the thread.
    • Official Post

    "/var/log/nginx/error.log" failed (2: No such file or directory)\nnginx

    Maybe the content of /var/log/ is not part of the backup. You can try to create that file manually.


    BTW there is also a backup plugin. If you use "full disk dd" as method you get a compressed image of your SD card which can be flashed to an SD card using usbimager or Etcher.

  • Thanks macom for your input. I've decided on principle not to pursue any attempted fixes to this problem as it will not be reliable in the future. Clearly, rpi-clone was written just to get an OS image cloned and not necessarily the apps installed on the same disk, such as OMV.


    Your suggestion of using the "full disk dd" method of the "Backup" plugin (System > Backup) is useful as it is decribed as "dd full disk - use dd to clone the entire drive to a compressed image file" . However, the output is one compressed .zst file and 6 very small files and I'm struggling to work out how to tell etcher to burn it to a SD card, even after decompressing the .zst file. Rather than take this thread off topic I wil raise a new post.

  • larachantie - to help you with this...


    full disk dd creates a compressed file that etcher can not (yet) deal with. So you need to do the following from the shell/cmd.


    what I do and have tested this is:

    1. create the backup

    2. add destination disk to omv (e.g. using a usb card reader)

    3. run cmd below(with correct destination drive!!!) to burn the image to sd card

    4. power down omv. switch to new / burned omv disk (take out existing omv disk)

    5. confirm omv starts ok



    zstdcat /path/to/backup.ddfull.zst | dd of=/dev/sdX bs=1M status=progress


  • Thanks jata1 and macom. I was going to post a new thread with a better description of my problem rather than take this thread off topic. However:


    The dd full disk backup method confusingly outputs one large compressed file and several smaller files, so it's not clear what you do with them. I decompressed the large file using "zstd -d backup-omv-2024-08-11_22-12-01.ddfull.zst" and this output a large file (60 gb) called "backup-omv-2024-08-11_22-12-01.ddfull". I then used belina Etcher to image the latter (via Samba) to a blank SD card on a Windows 11 machine. The newly imaged SD card was then inserted into the SD card on the RPi5, with the bootloader configured to use SD first for boot. All seemed to work OK however on logging onto the OMV Workbench it was a virgin installation. No disks present, no file systems, no shared files and so on.


    Following your helpful suggestions, I tried again, this time using USB Imager. And it worked! The only issue is that the system time was that of the backup and for some reason the NTP time server had not (yet) kicked in. But this was easy to fix in System > Time & Date.


    I'm not sure why etcher failed and USB Imager worked. One theory is that there is no file extension on the file that zstd produced, which confused etcher? Anyway, I seem to have a working solution, though it does feel a bit fragile.


    Your suggestion jata1 looks very elegant. I won't pursue it though as I don't like the concept of two bootable OS disks residing at the same time on a Rpi5. There seems to be a bug in the way that the Rpi bootload works such that OMV will launch from the SD card in the SD slot, yet the OS will boot from a SD card in a USB card reader even if the bootload order is set to SD card, then NVMe and then USB. (Must be something to do with same UUID on two disks. I will log this on the RPI forum).


    As a newbie to OMV, I find that the documentation and forums tend to focus on backup and then tend to neglect restore. But at least I seem to have got there, so thanks again for the input, a) in confirming that I can ignore the six small files produced by the dd full disk method; and b) advising to use USB Imager rather than Etcher. I now plan to run the job on a daily basis using crontab, outputting the compressed file to a cloud file service so that on another machine it can be decompressed and burnt to SD card if a restore is needed (e.g. boot SD card failure; broken OS update; conguration error).

  • all good that you have it working.


    I did not mean to say that you should/could have 2x bootable disks at the same time - especially if they are cloned! This will cause issues for sure as both disks will have the same UUIDs. My method is just a quick way to create a disk with the cloned image. You then use this to boot the system but remove the live os disk first.


    The command below is doing the same as usbimager - burning the backup to a disk in one step - just from the shell.


    The main thing with any backup process is that you test the restore is working correctly. Sounds like you are good but I think it is strange that a few services that did not start.


    zstdcat /path/to/backup.ddfull.zst | dd of=/dev/sdX bs=1M status=progress

Participate now!

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