Migrate backup to a new OMV instance (same hardware)

    Hello community!


    I find myself in a precarious situation. The USB flash disk I used to boot OMV from died. When I realised this (fsck failed… usually run as read only, no swap partition) I tried do make a backup using dd but it failed. (at the drives 9GB location is got so slow that it took 48h to save 200MB… 7GB were to go. I cancelled the operation. Luckily I was able to make an rsync -a backup… shortly before the drive died altogether and cannot even be reformatted.

    However this backup does not include the in the MBR sector located grub2 BIOS loader, and obviously features the originals drive UUID in grub.cfg.

    How would I proceed now to restore my readily setup and previously working OMV installation?


    Thanks in advance.

    Best, Fabian


    *I do have an entire drives dd img from an older working state (older kernel & settings), if this helps.

    To reinstall grub into the MBR, you can copy the backup onto a new USB flash disk. Put it into your system. Then boot the Debian installer from another USB stick and choose the Rescue mode. Then you do basically what I described here. Also make sure to run dpkg-reconfigure grub-pc afterwards, because your debconf database will very likely contain the wrong entry now (because the boot device' UUID has changed).

    Thank you! I'm back booting again 😊 though not back running, as I cannot get the Web-Interface back up. Apparently the state I could save via rsync, was somewhat in between a failing update. Now I resolved all package configuration issues but one:dpkg --configure openmediavault


  • RastaFabi

    Hat das Label gelöst hinzugefügt.

  • RastaFabi

    Hat den Titel des Themas von „Migarte backup to a new OMV instance (same hardware)“ zu „Migrate backup to a new OMV instance (same hardware)“ geändert.
    Zitat von dleidert

    apt-cache policy salt

    sudo apt-get install -f

    I did install the required version of salt using this repo and this guide. However now it fails quite verbosely (shortened due to repeated sections and overlength) due to jinja. Sadly without stating a version requirement.


    aptreacts quite strangely regarding jinja2. Apparently it is somewhat available but it cannot be reinstalled, neither it can be found by apt install.

    PS.: Shall I move this to a new issue, so people might find it easier?

    Zitat von RastaFabi

    I did install the required version of salt using this repo and this guide. However now it fails quite verbosely (shortened due to repeated sections and overlength) due to jinja. Sadly without stating a version requirement.

    The salt package necessary here is available from the openmediavault repository! Remove the version you installed together with the repository and install the correct version:


    apt-get install --reinstall salt=3002.2+ds-1 salt-common=3002.2+ds-1


    Please don't use third party repositories except they get installed by omv itself (e.g. via omv-extras).

    Zitat von dleidert

    The salt package necessary here is available from the openmediavault repository! Remove the version you installed together with the repository and install the correct version:


    apt-get install --reinstall salt=3002.2+ds-1 salt-common=3002.2+ds-1


    Please don't use third party repositories except they get installed by omv itself (e.g. via omv-extras).

    This was the version which was installed beforehand. It did throw the error that it is not compatible and version 3001.1 was needed. I will revert to this nonetheless, as it did not solve the issue.

    The openmediavalt package depends on salt-minion (>= 3000.2) (maybe add salt-minion=3002.2+ds-1 to the command above as well) and:


    3002.2+ds-1 > 3001.1


    so these packages fulfill the dependency. I think you might have had the pristine salt packages from the Debian archives installed instead of the ones provided by openmediavault. That's why I asked you to enter the apt-cache policy salt command, to check which version is installed or will be installed based on your pinning.

    I got it to work, but it broke again, due to still being damaged. I pinned down most of the issues remaining (nginx not coming up, as well as this previously described issue) to having corrupted remains (salt, .sls, .so files) of the previously damaged filesystem remaining in the rsync backup. Those appear file regarding file size, but they are unreadable corrupted "data" files. I tried replacing those manually one by one to get to a working state but this apparently only intermediately helped. Now I cannot boot anymore due to some missing (damaged) fsck dependencies (unresolved symbols). If no-one has another idea the last hacky thing I'm gonna try now is to to reinstall the specific version of OMV I had, than resync/cp -a everything from the old backup which isn't there yet, and than fully sync any .sls and .conf files, as well os some specific files like fstab. If this does not work I will resort to reinstalling everything and setting it up again based on the infos I can read out of the backup. Sadly there still is no export configuration function as far as I know, which would allow me to save my setup, once I get it to a semi working state.


    Sad to see that even a backup does not help me, though I shamelessly need to say that I do not had enough of those... but even if I had there would be no way do determine which backup would have worked since the filesystem had to be severely damaged since quiet some time, though I might have realised earlier... Although I never got posted any error even though reporting via mail was set up.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden