Upgrading from 4.x (latest) to 5.x (latest) AND moving the system to ssd (a bit messy)

  • Hi, fellow OMV'ers!


    (Please bear with me if this post gets a bit lengthy - possibly incomplete tl;dr at the end.)


    Long time OMV user here: started many years ago with version 2 (I guess).

    OMV 4 is/was running happily on a power-frugal HP Microserver Gen7 with a lot of RAM.

    In addition to OMV and plugins, I have installed some 3rd party software on the system (wiki, caldav, carddav, octoprint, ecodms, ...) -> this part is important for the question.

    The system disk (hdd) showed a few relevant SMART errors, therefore I will replace it with a small ssd.


    What are my goals?

    • keep the HP Microserver :-)
    • replace the system hdd with a ssd
    • upgrade to the latest OMV
    • keep the OMV configuration (mainly users, SMB shares and NTFS mounts/shares)
    • keep the 3rd party software I installed
    • set up with a clean, fresh, shiny new OS install, due to the fact that the initial OS setup was ages ago and has only been upgraded over the years. There are remnants of old, no longer used software (e.g. Crashplan) that I can't clean out completely, I guess
    • ...



    What I already did, in chronological order - a bit messy, maybe:

    1. Plan A: backup 4.x OMV config and restore it to a fresh 5.x install
    2. took a backup of 4.x with the backup plugin (fsarchive format)
    3. removed the 4.x system hdd
    4. connected the new system ssd and installed 5.x from the official OMV ISO
    5. got stuck restoring the config, was unsure about version conflicts, got confused. consulted the forum, got more confused, decided to go for Plan B.
    6. Plan B: upgrade the OMV 4.x on the hdd to 5.x, backup the new config, set up the SSD with a 5.x ISO and restore the config.
    7. Removed unsupported plugins from 4.x
    8. upgraded using this post/thread by @ryecoaaron
    9. deleted the browser cache
    10. consulted the forum and deleted some more plugins from cli :-)
    11. deleted the browser cache
    12. logged in successfully and checked the OMV config
    13. PHEW!
    14. took a system backup, using the backup plugin (fsarchive)
    15. noticed that most 3rd party software is no longer working as it was depending on the NGINX-plugin (see #7)
    16. got some sleep

    So this is the status now:

    • The old system HDD has been upgraded to 5.x,
    • my 3rd party software is still 'there', but no longer running (needs some work, obviously)
    • the new system SSD has a clean 5.x install, but is switched off, currently
    • I have a backup! Two actually: one from 4.x and the current 5.x!


    Going forward, I have at least these options:


    option 1: Clone the HDD to the SSD.

    Go with the existing install and accept that I will possibly schlepp along some file remnants from 2.x...4.x.

    Then use the system on the SSD and repair the 3rd party software installations.

    What would be the best way to do this? Clonezilla? OMV backup (which bu type?)?


    option 2: restore the 4.x backup to the SSD and perform an in-place upgrade to 5.x on the SSD.

    I guess this has no benefit over option 1. I just wanted it to mention.


    option 3: restore the OMV 5.x backup to the fresh 5.x install on the SSD

    This has some unknowns:

    • what part of the fsarchive backup will I need to restore? I haven't found a documentation how to just restore the OMV "config" files (samba, nfs, syncthing,...) and be ready with the new install.
    • Will this move over the currently used 3rd party apps or do I need to re-install them?


    Any thoughts, any additional options? Have you been there as well? What did you do? How did it end?


    I'd appreciate your comments, especially in regards to the different future options and the fsarchive restore.


    Thanks for reading!



    ...and here it comes: ;-)

    tl;dr: I want to upgrade a messy and dated OMV 4.x installation with a few 3rd party apps and plugins to 5.x and move the system to an SSD. Got lost in the process and need to decide between several options.

  • OP here: As this seems to attract no specific interest from the community, and nobody seems to have a strong opinion about either of the options I was mentioning in my original post, I will outline what I did. I will also outline what I will do in the future and why this may not involve OMV at all.


    I took option #4: Install a fresh OMV 5.x (latest) on the SSD and set up everything from scratch, taking the old setup as a template.


    You may notice that this option was not mentioned in my original post. The reason for this lies in my own naivité: I thought there was a mature confg backup and restore, while there is 'just' a imaging tool available.

    Don't get me wrong: taking an image of your OMV install and being able to restore that to a same system is a good thing. Any backup is a good thing.

    it's just doesn't fulfill my needs and it's not comfortable. And from some of the frustrated comments here and on the 'net, I reckon I'm not alone.


    I'm quite happy with the reinstall: from a user perspective the Samba shares are much snappier altogether. This may have something to do with the system residing on a SSD or with the data partitions running on ZFS now (ext4 in the past).


    For the future, however, I will try a different product. I grappled with my decision to switch to FreeNAS right away, but the thought of switching to FreeBSD on short notice was a bit scary. I went with the cozy safety of a Debian Linux.



    Buckle up: this is going to be a long ride!


    Here's the reasons why I may turn away from the great product, I think OMV was: it isn't anymore. Not as a package.

    When I started with it (and if you read the original posting you know that was a while ago) I liked ease of use and the availability of many plugins. In the last years I used quite a few of them and enjoyed the simplicity of the integration into the dashboard.


    Along comes OMV 5 and the developers turning away from plugins and telling users (users!) to go and use containers instead.

    As an IT professional in my day job I understand the advantages a containerized system gives you. However this is on the system side only!

    Telling users to install formerly plugin-ized software as a container because "containers are so great and it's the way to go because *everyone* does it nowadays" is pure hubris!

    This is even more so, when you don't integrate the instructions to do so into the site. And I'm talking about good instructions for end users. Instructions that are being kept up to date in a world where systems like Portainer change their interface on a quarterly basis!


    I tried! Believe me: I tried hard!

    I tried installing and configuring the SyncThing container on Portainer. I found an instruction posted by a user on the forum. I followed the steps which were pretty well documented. However, I ran into at least two inconsistencies AND a major problem in the end.

    What was a 10 minute plugin-install in the past is now a 1-hour scavenger hunt, complete with adding lists of environment variables to docker configurations in Portainer.


    Ask yourselves: is this the user-friendly system OMV wants to be?


    Asking for the reason why the OMV developers turned away from the plugin system, we get the answer that there are no more developer resources for maintaining plugins. I have news for you: ignoring the complete and utter mess you are pushing users into with Docker configurations, is like laughing at their backs and the turning away!

    You factually took away easy third party software integration from users with OMV 5.

    I'm talking about users, not sysadmins who have time and motivation to tinker for hours with their home systems.


    It's still time to turn around the boat. If you are persistent to go the Docker way, you have to deliver good and up-to-date instructions in an accessible way so everyone can find and follow it.


    Serving files is something so many products can do well, nowadays. The real strength with OMV was always in the plugin integration!


    just my 2 cents.

  • Along comes OMV 5 and the developers turning away from plugins and telling users (users!) to go and use containers instead.

    There is only one plugin developer - me. I explained why here - RE: [Thoughts] OMV 5.x Plugin Ecosystem. Not every plugin is going to containers.


    Asking for the reason why the OMV developers turned away from the plugin system, we get the answer that there are no more developer resources for maintaining plugins. I have news for you: ignoring the complete and utter mess you are pushing users into with Docker configurations, is like laughing at their backs and the turning away!

    You factually took away easy third party software integration from users with OMV 5.

    I'm talking about users, not sysadmins who have time and motivation to tinker for hours with their home systems.

    Sorry, I suck. I guess I should add hours to my day to fix my "mess".

    omv 5.5.5 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • There is only one plugin developer - me. I explained why here - RE: [Thoughts] OMV 5.x Plugin Ecosystem. Not every plugin is going to containers.


    Sorry, I suck. I guess I should add hours to my day to fix my "mess".


    Thanks for reading and answering.


    I read that article you mention. It basically says you didn't port all those plugins to 5.0 because:

    • you either don't like them
    • don't know how they work
    • you think they're stupid anyhow (only on/off)
    • you hate them
    • or you think nobody will miss them.


    Your answer for most of them is that they're "better off in a container" anyhow.

    While this may or may not be true from an architectural p.o.v, it is quite arrogant in so many ways:


    - Yes, the "old" plugin system was offering "just an on/off button" for many of the plugins. However, it also offered a way for a user to install and control those plugins. OMV 5 took this lightness away from the user. Instead of simply selecting a plugin from the list, a user now has to Google the plugin, find the *right* docker image (Resilio is a perfect example for this, offering multiple images) and then go through the tedious process of configuring the container setup!


    - You assume implicitly that everyone who's able to install OMV is an admin or has the ambitions to be one. While this may be the case for some, it's certainly not true for the majority of users. Read the forum entries (not just about this topic) and think about the general level of proficiency.


    - If the development team has decided to switch to Portainer (like you did), the consequence IMO should have been to deliver an equally user-friendly install system like before: recommend concrete images, abstract the container setup further and create a step-by-step instruction that allows a 15-year old to set those systems up.


    What you (the team) did instead is to tell us: "There'll be no more plugins in the future - surprise!! But hey, there's that great thing called containers and you'd be stupid not use them. Besides - you don't have any choice -- get over it!"


    The SyncThing plugin/container is a perfect example: you wrote, you don't think there's "too many people complaining about this".

    I think there's nothing better than having the option to sync your Android phone to a personal storage - especially when I have just set up a local NAS!!! Setting up the plugin was a breeze (thanks for the work, then)! Setting up the container is hell. Even with the setup guide I found via this piece.



    If there are no resources for the plugin maintenance, there should have been a call for developers/maintainers!

    From a product view, OMV 5 has lost a lot of of attraction!



    Regarding your last comment: the "mess/messy" part was in relation to my old setup. Remember: this thread was originally intended to be a call for ideas for my migration journey. It just became an opinionated piece.



    Cheers,

    ohuf.

  • If there are no resources for the plugin maintenance, there should have been a call for developers/maintainers!

    From a product view, OMV 5 has lost a lot of of attraction!

    A comment like this is to be expected from someone who has just only now shown up on the forum. There have been many such requests that I have seen in my more than five years with this product and on this forum.


    It's simple. If you don't like the product don't use it. If you can't contribute to the project technically, then stop complaining about the lack of technical contributors.


    This project is open source. Feel free to develop and maintain any portions of it you wish. Feel free to share your changes and additions via pull requests, or not.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 5.x on ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.

  • Cheers,

    ohuf.

    “Cheers”? Really? How irksome. :thumbdown:

    RAID is NOT a backup and not useful for most home users. Rsync makes true backup and restoration stupid easy, and it's built right in to OMV. Use this command in a Scheduled Job: rsync -av --delete /srv/dev-disk-by-label-NAMEofSOURCEdisk/ /srv/dev-disk-by-label-NAMEofDESTINATIONdisk/

    Hardware: OMV 5 (current) - NanoPi M4: Nextcloud, Plex, & Heimdall - Acer Aspire T180: backup - Odroid XU4: Pi-Hole (DietPi) - Odroid HC2, Raspberry Pi 3B+, and HP dx2400: testing.

  • A comment like this is to be expected from someone who has just only now shown up on the forum. There have been many such requests that I have seen in my more than five years with this product and on this forum.


    It's simple. If you don't like the product don't use it. If you can't contribute to the project technically, then stop complaining about the lack of technical contributors.


    This project is open source. Feel free to develop and maintain any portions of it you wish. Feel free to share your changes and additions via pull requests, or not.


    I guess that's fair -- to a degree!


    The reason why I have almost never been on this forum, and the reason why I have never contributed to it is simple: up to this point in time my OMV setup simply worked the way I'd expect it to do. If there was the occasional hiccup (sometimes during upgrade), I was able to fix it.


    The reason why I'm offering an inconvenient opinion now can be found in my contributions up here.



    You're writing:


    "If you can't contribute to the project technically, then stop complaining about the lack of technical contributors."


    That's just another way to say: "only developers are given a say in how the future product will look like.

    It means the technical contributors (developers) continue to tinker along, without an input from the users. But not everyone is a developer.


    This is 2020 - it's time to ask the users what they want from a product and give them a way to make an informed decision. It's the main benefit of agile, XP, or DevOps...


    And don't get me wrong: I'm not offended by the switch to containers. I'm appalled by the lack of proper user documentation in this area and maybe the lack of a tool/interface that further abstracts the container configuration from the user (no, Portainer just doesn't cut it).


    I love OMV! I adore the sleek interface and the way it lets me change the config.

    I used to like the plugins - especially the way they were integrating into the system!

    Technically OMV is still good -- From a user perspective one just has to know what to want.

  • ohuf you can twist what I said all you want. I understand some people won't like my decisions. I tried to justify them. If that isn't enough, not sure what to tell you. If I have unlimited time, I might have ported them. You realize I spent a lot of time writing and maintaining them. I don't like to throw work away but I had to.


    I only said I hate one plugin - plex. And I know how all the plugins work. I'm just not the one to maintain plugins I don't use if I can't test it. And I do listen to non-developers all the time. Telling me not to use docker and keep maintaining all of the plugins isn't a suggestion though. I didn't write the original docker plugin but docker is becoming a very popular way to do things in the Linux world. It saves me a ton of time and allows me to properly maintain the plugins that are still in the repo as well as help people on the forum.


    I still maintain 26+ plugins. People act like all of the plugins are gone. If documentation is horrible, you don't need to be a dev to contribute in that area. And don't tell me docker documentation is bad because it is all over the internet. And while I don't use portainer (I use the command line), I think portainer is very good.


    I would also love to hear some ideas how to get more devs because nothing has worked.

    omv 5.5.5 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • You put your Radarr in

    Your Radarr out

    Stop, Start, Stop, Start

    You mess it all about


    You do the porty shuffle

    And you’re banging your head

    That’s what it’s all about


    Woah the porty shuffle

    Woah the porty shuffle

    Woah the porty shuffle

    F* that

    Too hard

    Where’s the f*ing docs


    Couldn't resist that :)

Participate now!

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