"omv-regen backup" triggers unexpected version upgrades

  • chente the omv-regen script is great and plugs a big hole in official OMV features open since at least 2018 !


    Unfortunately the documentation doesn't mention that version upgrades are triggered even when only "omv-regen backup" is run.

    Reading current doc it sets from my view the expectation, that upgrades are only happening at time of "omv-regen regenera" due to "must be updated" actual fact seems "will be updated"!


    Because every upgrade has the risk of failing, there a chance to make currently working setup unusable.


    Therefore my questions:


    1. could the doc be clarified in this regard (happy to create a PR with my proposal)?
    2. Would working with Volker to integrated the script into OMV as a standard feature (including wiki doc) be a feasible approach?


    Current doc:"

    • OMV and plugin versions must match on both the original and new systems.

    As a consequence of the previous point:

    • The original system must be updated when you make the backup, do not wait a day to regenerate.
    • If an important plugin update is released during the process it could stop.
    • If the above case occurs, omv-regen will decide whether or not the installation of that plugin can be skipped."

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

  • I would like to put forward the option of selecting whether you want to run the update routing or not.


    On a server, sometimes it is a good idea to wait a while to update to avoid injecting bugs that may have crept into updates, so manual control is a good thing. However running the actual re-gen configuration snapshot regularly is good to avoid missing any configuration changes you may do.


    To that end, I think asking if you want to do updates when setting the re-gen configuration is a better option than forcing them.

  • I posted while the update still ran, now from script output it looks the defaults used for command line run should be changed to fix my issue.

    Instead of "Update system before making the backup ==> Yes"

    better would be "Update system before making the backup ==> No"


    Same applies to "Delete backups older than ==> 7 days" => No deletes


    <<< Backup to regenerate system dated 240108_154751 >>>

    >>> The current parameters set for the backup are:

    Folder to store the backup ==> /ORBackup

    Update system before making the backup ==> Yes

    Delete backups older than ==> 7 days.

    Optional folders to include in the backup ==>

    /home

    >>> Updating the system.

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

    Einmal editiert, zuletzt von mi-hol ()

    • Offizieller Beitrag

    chente the omv-regen script is great and plugs a big hole in official OMV features open since at least 2018 !

    Thanks mi-hol ! :thumbup:

    Unfortunately the documentation doesn't mention that version upgrades are triggered even when only "omv-regen backup" is run

    Reading current doc it sets from my view the expectation, that upgrades are only happening at time of "omv-regen regenera" due to "must be updated"

    Actual fact seems "will be updated"

    I hope there is no translation problem here. I use automatic translators to publish in English and I try to correct errors although I don't always succeed. This is explained in the help in the Backup options>Update the system section. The help is perhaps a little extensive, I wanted to do it this way to avoid possible confusion. After all, this script modifies openmediavault configurations and everything must be clear before starting to use it.


    The help also explains that if you intend to regenerate next, the system must be updated as otherwise the package versions could be different on the new system.

    By default the script has this option activated, since I suppose that the most common thing will be to use omv-regen to regenerate. To make backups there are more advanced options in the openmediavault-backup plugin.

    However, this script can also be useful simply for scheduling backups in the OMV GUI. Therefore there is the possibility of deactivating the automatic update function.

    Additionally, the omv-regen GUI warns you before running the backup about this particular configuration.

    Would working with Volker to integrated the script into OMV as a standard feature (including wiki doc) be a feasible approach?

    Well, so far votdev has never commented on omv-regen. Maybe when he reads this it will be time to say his opinion. For my part, I have no problem collaborating to integrate it into OMV or even handing over the script completely. Anyone can use and/or modify it freely, it is published on github with an open license.

    • Offizieller Beitrag

    I would like to put forward the option of selecting whether you want to run the update routing or not.

    The publications have been crossed.

    This already exists, it is explained in my previous post.

    I posted while the update still ran, now from script output it looks the defaults used for command line run should be changed to fix my issue.

    Instead of "Update system before making the backup ==> Yes"

    better would be "Update system before making the backup ==> No"


    Same applies to "Delete backups older than ==> 7 days" => No deletes

    The same, the publications have been crossed.

    The reason for the default configuration is explained in my previous post. Automatic updating is only a default setting, once you modify it it will be kept according to the chosen preferences until you modify it again.

  • The publications have been crossed.

    I'd believe language barriers are preventing us from understanding each others view and acting together.

    Above quoted statement uses words that very likely do not convey the purpose/intent you mean (to me at least).


    Rules I learned over a long time are:

    - long descriptions & explanations are never read or understood in the intended way

    - therefore defaults should prevent potential errors from happing


    As I tried to explain, current defaults can cause an unusable system as result of just executing "omv-regen backup".

    This issue should be fixed from my view.

    Are we in agreement about this proposal?

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

    4 Mal editiert, zuletzt von mi-hol ()

    • Offizieller Beitrag

    As I tried to explain, current defaults can cause an unusable system as result of just executing "omv-regen backup".

    This issue should be fixed from my view.

    Are we in agreement about this proposal?

    No, I'm not agree. In my opinion this is not a problem.

    Before using omv-regen it is necessary to read the documentation, as with any software. Then you will know that the first step will be to update the system. If you run omv-regen backup and the update fails you will see it in the CLI output. At that time, as always, if you know how to solve it you will solve it on your own, if you don't know how to solve it you will ask for help in the forum, just like with any other update.

    If an update fails in omv-regen it is because that update fails on that system in any case. omv-regen has nothing to do with this.


    If I set the default value of updating the system to NO the result will be users who wanted to regenerate, made the backup, the system was not updated and when they ran omv-regen regenera the regeneration could not be completed. Hopefully that user installed OMV on a new hard drive, if they read the documentation and followed the advice, and will be able to return to the initial system and make a new updated backup. If you are not lucky, that user has installed OMV on the same disk where he had OMV initially, he will not have been able to regenerate because the backup was done without updating and he will have lost his OMV configurations. In my opinion that is the worst possible path.


    So I'd rather have a system crippled by an update that didn't go well and can be resolved than a configuration lost because the user didn't read the documentation. Unfortunately this is the most common, many users do not read the documentation.

  • Reading current doc it sets from my view the expectation, that upgrades are only happening at time of "omv-regen regenera" due to "must be updated" actual fact seems "will be updated"!

    As said in first post I read the doc and summarized my conclusion in above.

    It is a major difference in meaning between "must be updated" versus "will be updated by the script automatically"

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

  • The publications have been crossed.

    This already exists, it is explained in my previous post.

    Correct you are. I forgot about that in the configuration.


    I personally have never had a problem with it doing the updates, and I also run an fsarchiver backup so I can easily restore from that or use the regeneration, so I really have 2 options, and the saved data from regen is even good on a for clean install to use as a feference for manually re-building.

    • Offizieller Beitrag

    Reading current doc it sets from my view the expectation, that upgrades are only happening at time of "omv-regen regenera" due to "must be updated" actual fact seems "will be updated"!

    As said in first post I read the doc and summarized my conclusion in above.

    It is a major difference in meaning between "must be updated" versus "will be updated by the script automatically"

    Well, I would say that in general people understand that phrase in the correct sense. The system must be updated before making the backup, no matter how you do it. You can update the system manually and make the backup. Or you can let the script do the system update for you. Perhaps you have taken this phrase out of context by not reading the rest of the help.


    Regarding the title of this thread, in my opinion it is incorrect. omv-regen does not trigger unexpected version updates. You can configure this parameter according to your preferences, therefore the result is expected.


    Thanks for your contribution anyway.

    • Offizieller Beitrag

    and I also run an fsarchiver backup so I can easily restore from that or use the regeneration, so I really have 2 options, and the saved data from regen is even good on a for clean install to use as a feference for manually re-building.

    I do the same thing as you for the same reasons. I have a backup scheduled with fsarchiver and another scheduled with omv-regen.

    It is always positive to have different options and omv-regen is not intended to be a backup utility, for that there is already the openmediavault-backup plugin that does it very well. The omv-regen utility is very different, moving the OMV GUI configuration from one server to another on a fresh installation.

Jetzt mitmachen!

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