Urbackup Server Plugin Update

  • Hi,


    Urbackup Server Plugin issues the following message:

    Code
    Es ist eine neue Version des UrBackup Servers verfügbar (2.1.20). Download it [url='http://www.urbackup.org/download.html']here[/url].


    What do I have to do?
    Thank you und best regards.

    2 BananaPi, 1 OrangePiPC+, 1 OrangePiPC with OMV 6.0.x

    Einmal editiert, zuletzt von omavoss () aus folgendem Grund: typo

    • Offizieller Beitrag

    What do I have to do?

    Click Check in the Updates tab and install the update.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


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


    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

    Upgrade fails on OMV3


    The following packages have unmet dependencies: urbackup-server : Depends: libcrypto++6 but it is not installable Depends: libstdc++6 (>= 5.2) but 4.9.2-10 is to be installedE: Unable to correct problems, you have held broken packages.


    Is there a way to fix it?

    • Offizieller Beitrag

    Is there a way to fix it?

    I really need to stop updating OMV 3 packages... I will have to test.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


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


    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

    I had to remove 2.1.20 from the OMV 3.x repos. No way am I going to maintain a backports version of libstdc++6. It would probably break a lot of things. My only suggestion is to move to OMV 4.x or use docker.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


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


    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!

    Einmal editiert, zuletzt von ryecoaaron ()

  • I really need to stop updating OMV 3 packages...

    That would be really sad, at least as long as OMV 4 is not yet tagged as "stable". I don´t want to be a continous beta tester. Nevertheless I can understand your motivations.


    I would appreciate it if there would be a possibility to install a specific (older) plugin version which matches to a OMV major version to avoid such problems named in this thread here. But in the WebUI it is only possible to update to a version which is shown in the update management page. Maybe all this is possible with the right apt-commands. But I am scared about doing things wrong.


    Also a reference list would be useful, to document which latest plugin version fits to a certain OMV versions.


    Christmas wishes :)

    OMV 3.0.100 (Gray style)

    ASRock Rack C2550D4I C0-stepping - 16GB ECC - 6x WD RED 3TB (ZFS 2x3 Striped RaidZ1) - Fractal Design Node 304 -

    3x WD80EMAZ Snapraid / MergerFS-pool via eSATA - 4-Bay ICYCube MB561U3S-4S with fan-mod

    • Offizieller Beitrag

    I would appreciate it if there would be a possibility to install a specific (older) plugin version which matches to a OMV major version to avoid such problems named in this thread here.

    I think that is what ryecoaaron did. The version 2.1.20 is removed from the OMV3 repo. It does not show up anymore in the updates page of OMV3.

    • Offizieller Beitrag

    That would be really sad

    I just meant for urbackup. Nothing I can do if newer urbackup-server packages require dependencies not available on OMV 3.x.


    I would appreciate it if there would be a possibility to install a specific (older) plugin version which matches to a OMV major version to avoid such problems named in this thread here.

    This is a terrible idea. As soon as the user starts trying to determine which version should be installed, it would be very bad... That said, I did remove the incompatible package as macom said.


    Maybe all this is possible with the right apt-commands. But I am scared about doing things wrong.

    It is but I highly recommend against it.


    Also a reference list would be useful, to document which latest plugin version fits to a certain OMV versions.

    This shouldn't be necessary (and a nightmare to maintain). You should always run the latest version of OMV and plugins. If there is something wrong with the latest version, they should be fixed. If you are worried about the latest version, you should have a test setup to test the latest version before updating to it.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


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


    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

    Clear words

    Do you not think I justified my reasoning especially in my last paragraph? I'm not trying to be butthead but running old versions on purpose would really make it hard to figure out problems.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


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


    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!

  • Now it becomes difficult for me to find the right words for a reply as a non native English speaker. So please be lenient with me.


    Do you not think I justified my reasoning especially in my last paragraph?

    Yes, you justified it more than enough.

    I'm not trying to be butthead

    Of course I do not think so too! On the contrary.


    You should always run the latest version of OMV and plugins.

    I am not a friend of a system which is continously changing. If a new version brings new problems there is no easy way in OMV to go back to a previous working one. It is possible of course e.g. with Clonezilla images. But this is awkward. But maybe this is more dependent from Debian than from OMV.


    My personal impression is that any update (regardless wether it is OMV or a plugin or a combination of both) is always a gambling if it works or not. Therefore I try to reduce the number of amendments.

    OMV 3.0.100 (Gray style)

    ASRock Rack C2550D4I C0-stepping - 16GB ECC - 6x WD RED 3TB (ZFS 2x3 Striped RaidZ1) - Fractal Design Node 304 -

    3x WD80EMAZ Snapraid / MergerFS-pool via eSATA - 4-Bay ICYCube MB561U3S-4S with fan-mod

    • Offizieller Beitrag

    In this case, I'm glad I didn't update the Urbackup plugin. (Too conservative - an old habit.)



    I am not a friend of a system which is continously changing. If a new version brings new problems there is no easy way in OMV to go back to a previous working one. It is possible of course e.g. with Clonezilla images. But this is awkward. But maybe this is more dependent from Debian than from OMV.
    My personal impression is that any update (regardless wether it is OMV or a plugin or a combination of both) is always a gambling if it works or not. Therefore I try to reduce the number of amendments.

    This is "why" I boot for USB thumbdrives, and why I have 3 of them. (1 working and 2 clones.) I update one of them and wait a few weeks before updating the 2nd drive, and even longer before updating the master in my desk drawer. These clones makes it easy to go back to a known working configuration, in a few minutes.
    __________________________________________________


    At least UrBackup has a preconfigured Docker that's maintained by the UrBackup project (as opposed to a disinterested 3rd party). It looks like it's time to test it.

  • I update one of them and wait a few weeks before updating the 2nd drive,

    Hi @flmaxey but which one do you use in the meantime? The updated one or the old one? And how do you handle configuration changes of OMV which you have made to the thumb drive currently in use? I also can go back to an older Clonezilla image, but all intermediate changes then are lost (like creating new shares, modify access rights, changed plugin configuration and so on).


    The absence of a supported possibility to store or export the configuration settings of OMV does not improve the situation.

    OMV 3.0.100 (Gray style)

    ASRock Rack C2550D4I C0-stepping - 16GB ECC - 6x WD RED 3TB (ZFS 2x3 Striped RaidZ1) - Fractal Design Node 304 -

    3x WD80EMAZ Snapraid / MergerFS-pool via eSATA - 4-Bay ICYCube MB561U3S-4S with fan-mod

  • I am not a friend of a system which is continously changing. If a new version brings new problems there is no easy way in OMV to go back to a previous working one.

    Snapshots exist. :)


    My OMV installations live on SD cards, the filesystem of choice is btrfs (compressed but this doesn't matter, only speeds up things slightly). Prior to installing upgrades I take a snapshot and send it to a small partition on a data drive. There's also the first 2 MB of the SD card stored to be able to fully recover from a broken SD card in no time).


    If I realize that something's wrong after an update I simply revert back to latest snapshot and reboot. If the SD card completely dies, I boot the system from a pendrive or another SD card, write partition table and stuff with dd, do a quick partprobe that restores partitions and copy the last rootfs snapshot over. One reboot later everything is up and running again.


    Due to version requirements (btrfs code lives inside the kernel so you don't want to use btrfs with kernels older than 4.4 and the same partially applied to btrfs helper/userspace tools) this should only be considered starting with OMV 4 / Debian Stretch.

  • Thank you @tkaiser for the explanation of your approach.

    My OMV installations live on SD cards, the filesystem of choice is btrfs

    Ok, I understand. You are using btrfs for the root file system. Therefore you are able to take snapshots of it. But how do you bring btrfs to the root file system? I am not sure (I didn´t remember) if there is a possibility to select it during the (standard) installation of OMV (I hope I am not mistaken).

    OMV 3.0.100 (Gray style)

    ASRock Rack C2550D4I C0-stepping - 16GB ECC - 6x WD RED 3TB (ZFS 2x3 Striped RaidZ1) - Fractal Design Node 304 -

    3x WD80EMAZ Snapraid / MergerFS-pool via eSATA - 4-Bay ICYCube MB561U3S-4S with fan-mod

  • But how do you bring btrfs to the root file system?

    In my case (not needing a fat and wasting x86 box for NAS) it's easy: https://sourceforge.net/projec…s/Other%20armhf%20images/ (all those OMV images for ARM ship with their rootfs as zlib compressed btrfs using lzo in normal operation). But that's only possible since we switched all of them to more recent kernels in the meantime (whole work done over at Armbian).


    With OMV on x64 boxes you would need to install Debian yourself and then add OMV to it later. As said above using btrfs is nothing you want with outdated kernels or userspace tools (btrfs-progs package in Debian Jessie is 3.17 while 4.7.3 in Stretch) so as a general recommendation this is something worth a look starting with OMV 4 (with older OMV versions as experienced user you were of course able to switch to a backports kernel and packages but that's not an option for the majority users and that's also the reason why I kept my mouth shut and only now will start to propagate btrfs more and more :) )


    For me btrfs is save to be used starting with kernel 4.4 so it's impossible to do something wrong here with Debian Stretch OMV 4 is based on.

    • Offizieller Beitrag

    Hi @flmaxey but which one do you use in the meantime? The updated one or the old one? And how do you handle configuration changes of OMV which you have made to the thumb drive currently in use? I also can go back to an older Clonezilla image, but all intermediate changes then are lost (like creating new shares, modify access rights, changed plugin configuration and so on).
    The absence of a supported possibility to store or export the configuration settings of OMV does not improve the situation.

    When a version upgrade comes up (OMV 3.0.90 to 92 as an example), I update the active USB thumbdrive. Then it's, "wait and see" for a few weeks. If there are no ill effects, I update the second working drive by cloning the first one onto the second (testing the 2nd drive for errors before cloning onto it). After it's cloned, the second drive is rotated into the NAS and the first drive is now sitting on top of the case.


    With that noted, minor version upgrades don't go onto the 3rd drive, the master. The master is updated only when there's a configuration change (a share is added, deleted, etc.). Unless there's a major change in configuration or software, that would affect the overall operation of the NAS, the master remains untouched. (It's a fall back for an ugly consequence, with nearly no wear on it.)


    Is this an old tech - hands on - approach? Yep, but it's effective nonetheless.
    (Note that I am looking into a snapshot approach, which can be fully automated. Still, I can't imagine a recovery process that would be as simple as plugging in another USB thumb drive and booting up. It's fast, and clean.)
    ___________________________________________


    What I've found over the years is the majority of software changes tend to be minor, incremental changes and improvements, that have very little or no effect on the vast majority of users. Most of these changes sort out odd ball issues for a hand full of users - until something odd crops up in an upgrade with a consequence for a LOT of users. That appears to be the case here, with Urbackup.


    I have file and image backups for 6 clients, on a big drive that's dedicated solely to Urbackup. So, when prompted by the Urbackup server about the server upgrade, I ignored it because what I have now is thoroughly tested and getting the job done. (I have ver 2.1.19 installed.) There's no point in risking backup sets for 7 clients, taken during a span of several months. If I had taken the chance and upgraded Urbackup, the second I noted an issue, I would have inserted a clone to fall back.


    As it is: I'll keep the version of Urbackup I have until OMV 4.0 is a bit more developed or I'm comfortable with configuring and testing a UrBackup Docker.

  • I think only the explicit dependency on libcrypto++9 should be removed as urbackup already has the correct dependency depending on its version (old ones have libcrypto++9 and new ones libcrypto++6). Unfortunately I don't now how to change this on github and build new package.

Jetzt mitmachen!

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