Urbackup Server Plugin Update

    • OMV 4.x (GIT/pre-alpha)

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Urbackup Server Plugin Update

      Hi,

      Urbackup Server Plugin issues the following message:

      Source Code

      1. 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.

      The post was edited 1 time, last by omavoss: typo ().

    • 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?
      BananaPi - armbian - OMV4.x | Asrock Q1900DC-ITX - 16GB - 2x Seagate ST3000VN000 - 1x Intenso SSD 120GB - OMV3.x 64bit
    • 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 4.0.14 arrakis | 64 bit | 4.13 backports kernel | omvextrasorg 4.1.0
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!

      The post was edited 1 time, last by ryecoaaron ().

    • ryecoaaron wrote:

      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.90 (Gray style)
      ASRock Rack C2550D4I - 16GB ECC - 6x WD RED 3TB (ZFS 2x3 Striped RaidZ1)- Fractal Design Node 304
    • cabrio_leo wrote:

      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.
      BananaPi - armbian - OMV4.x | Asrock Q1900DC-ITX - 16GB - 2x Seagate ST3000VN000 - 1x Intenso SSD 120GB - OMV3.x 64bit
    • cabrio_leo wrote:

      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.

      cabrio_leo wrote:

      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.

      cabrio_leo wrote:

      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.

      cabrio_leo wrote:

      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 4.0.14 arrakis | 64 bit | 4.13 backports kernel | omvextrasorg 4.1.0
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • New

      cabrio_leo wrote:

      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 4.0.14 arrakis | 64 bit | 4.13 backports kernel | omvextrasorg 4.1.0
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • New

      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.

      ryecoaaron wrote:

      Do you not think I justified my reasoning especially in my last paragraph?
      Yes, you justified it more than enough.

      ryecoaaron wrote:

      I'm not trying to be butthead
      Of course I do not think so too! On the contrary.

      ryecoaaron wrote:

      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.90 (Gray style)
      ASRock Rack C2550D4I - 16GB ECC - 6x WD RED 3TB (ZFS 2x3 Striped RaidZ1)- Fractal Design Node 304
    • New

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

      cabrio_leo wrote:


      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.
      Good backup takes the "drama" out of computing
      ____________________________________
      OMV 3.0.90 Erasmus
      ThinkServer TS140, 12GB ECC / 32GB USB3.0
      4TB SG+4TB TS ZFS mirror/ 3TB TS

      OMV 3.0.81 Erasmus - Rsync'ed Backup Server
      R-PI 2 $29 / 16GB SD Card $8 / Real Time Clock $1.86
      4TB WD My Passport $119
    • New

      flmaxey wrote:

      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.90 (Gray style)
      ASRock Rack C2550D4I - 16GB ECC - 6x WD RED 3TB (ZFS 2x3 Striped RaidZ1)- Fractal Design Node 304
    • New

      cabrio_leo wrote:

      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.
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • New

      Thank you @tkaiser for the explanation of your approach.

      tkaiser wrote:

      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.90 (Gray style)
      ASRock Rack C2550D4I - 16GB ECC - 6x WD RED 3TB (ZFS 2x3 Striped RaidZ1)- Fractal Design Node 304
    • New

      cabrio_leo wrote:

      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: sourceforge.net/projects/openm…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.
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • New

      cabrio_leo wrote:

      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.
      Good backup takes the "drama" out of computing
      ____________________________________
      OMV 3.0.90 Erasmus
      ThinkServer TS140, 12GB ECC / 32GB USB3.0
      4TB SG+4TB TS ZFS mirror/ 3TB TS

      OMV 3.0.81 Erasmus - Rsync'ed Backup Server
      R-PI 2 $29 / 16GB SD Card $8 / Real Time Clock $1.86
      4TB WD My Passport $119
    • New

      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.