Questions about upgrade 2.x -> 3.x or fresh install on new system

Zitat von Linkinsoldier

I have bought a replacement server (in case hardware stops working) and I want to upgrade omv from 2.x to 3.x in the next month to upgrade my nextcloud - but I have never upgraded a Linux system with this big changes and I read many comments/Threads here and I am unsure on how to proceed and make sure everything works. Can somebody please tell me how exactly to proceed?

I've tried a few "in-place" version upgrades using omv-release-upgrade from the command line. I've not had one case where it worked without some sort of "less than ideal" outcome, ranging from plug-in problems to failing to be able to log into the Web interface. I'd strongly recommend a fresh installation.

However, if you want to give a release upgrade a try, be ultra cautious. When I tried it:

- I made sure to make an exact copy of my boot media.
- I tested the copy to be sure it booted correctly and would work with my existing data drives.
- Then I set aside the original boot media and worked with the copy.
- I disconnected my data drives. (I did this to be absolutely certain that the upgrade couldn't hijack my data drives. In your case, this is really important because you're running a RAID set.)
- I booted onto the copied boot media and did the release upgrade from the command line.

While the release upgrade may work for you, all of my outcomes had issues so I was relieved to know that my original boot media AND data drives were untouched.

If you want to play it safe, I'd do a fresh 3.X install on your new server, share the data on the old server to your network, and copy that data to your new machine.

Is this a less than adventurous approach? Absolutely, but you'll have a fall back position and you'll be avoiding what I call "The agony of delete".

Good Luck.

Zitat von Linkinsoldier

When I do a clean install, is there anything I have to do to keep the user-file correlation, or is this gone for good? Can I save any configuration or something?

I suppose that would depend on how you're using OMV. I'm running a Raspberry PI as a backup file server and as a client PC backup server. In my case, the R-PI is a disaster recovery tool where (other than client PC hard drive images) it is a layer of data redundancy. Since users are not involved, in the traditional client server sense, this set up is fairly simple to duplicate and merge.

If you're using LDAP or are creating users and hosting User Home directories on OMV, the complexity of transferring/migrating data and/or users is at another level.
____________________________________________________________

(**Maybe someone else on the FORUM has this kind of experience with OMV ? **)
____________________________________________________________

The answer is - it depends.
If you're running a domain and have an LDAP server that is not on OMV, you might be able to use LDAP to import users onto the new server.
Rsync could be used to transfer data, preserving existing permissions, etc. But this scenario is more along the lines of a small to medium business scenario. This is unlikely for a home LAN and would be quite an exercise.

Assuming you're hosting users with OMV:
After recreating users on the new server, you can import user data into their HOME directories and force an ACL from the top down. I use the GUI to do this sort of thing, with <Access Rights Management>, <Shared Folders>. Add a Folder, click on ACL, make your permission changes, use the recursive option to push permissions down to sub-directories, then delete the Shared Folder. (DO NOT use the delete shared folder + "contents".) Otherwise, when the shared Folder is deleted, the files, folders and ACL permissions remain.

The configuration, on your old server, can be found in /etc/openmediavault/config.xml However, it's a job to sort through it and, even if you rebuilt everything as you did in the old version, the old 2.0 config would not exactly match a new 3.0 build. While config.xml could be used as a reference, DO NOT try to transfer it.

Frankly, the safest bet with an assured outcome would be to start from scratch. In this way you won't waste a lot if time, trying to save time, if you know what I mean.

BTW: You're doing the right thing in buying and maintaining hardware for backup/redundancy. Most don't think of disaster recovery options, until it's too late.

Zitat von Linkinsoldier

I created the raid, created dedicated folders and set permission with acl and then activated samba. Then I used samba share with different users for me, my wife and media account and I could only read and write in the dedicated folders. Is it possible, that if I do the same thing on omv 3, I just have to create the same users, Mount raid again (how exactly?) and then do the acl (with subfolder?)

Regarding "media accounts". I'm guessing you have some sort of media server plug-in. You said "nextcloud" or something like that? Any user accounts associated with plug-in's are not likely to port over to OMV 3. (Unless there's some sort of trick I don't know about.) They'll need to be recreated from scratch.
When I saw "SAMBA", above, that gives me a better idea of what you have and what you may be trying to do.

To check on your RAID set:
In the left hand column of the OMV GUI:
You can go into <Storage>, <Raid Management> to look at your set. I imagine the level might be RAID 1, a mirrored set.

On importing a drive, or a RAID drive set into OMV3:

First;
Realize what OMV is. It's a collection of Linux command line programs for NAS and File Server operations. Custom code was written to get it all to work together, and to provide for the management of the collection through a Web GUI. The GUI is set up to script services you turn on, and to add numerous variables for each of those services to specific scripts.
If you import a drive, the scripts that resulted from turning on and adding features, and the variables that are set when you pick and configure services, are not in the newly built OMV. Even if a drive is successfully imported, the new OMV 3 installation is not aware of RAID, Shares, Samba, etc., that made the data available as you originally configured it on the old version of OMV. If you have a RAID set, the "set" will not transfer.
**I've never heard of importing a foreign Raid set, even with a hardware controller.**

Second;
Realize that you can't re-create users, in Linux. If you have a OMV user named "User" with a password of "Password" in OMV 2 a recreated user in OMV 3, with the same name "User" and password "Password", are not the same. Depending on the OS, if it's a secure OS, there are Hashes, Keys, Symbols, etc., that are randomly generated and attached to the User file when created, that make them all unique. This dovetails into permissions issues.

Keep in mind that users are not the same, from one to build to another, and that user permissions are assigned at the folder and file level. With that in mind, I have no idea of the permissions issues involved with importing a foreign disk volume, from one operating system to another, in Linux. (However I believe there is the potential for serious permissions problems.)

So again, the question you have to ask yourself is, are you saving time or are you headed into a blind alley?
_______________________________________________________

On transferring data:
- You said you have a new server. Do you also have new hard drive(s)? If you do, you could set up the new OMV 3 server and put it on your network. Then you could copy your data from the shares on your old server to shares on your new server. (This works fine because, in file copies, file permissions are inherited from the receiving server.)

- If you have a raid 1 set, a mirror, you could break the mirror. (There's some risk in this.) You could take one disk of the two in the set and try to import it on the new OMV 3 build and see what happens. Also, if you don't have new hard drives for your new server, you could use this disk in your new server for the initial network copy and build a mirror later.

((**I have yet to try to import an foreign volume in Linux, keeping folders and files intact, and trying to alter permissions throughout the drive. I'm not saying it's impossible, but I haven't done it. However, I have intentionally broken a RAID set (RAID 5) in OMV and healed the RAID set by wiping the disk I removed and reinserting it.**))

Frankly, I think you'd be better off to rebuild from scratch and copy your data, from the old server to the new one, over the network. There won't be any ugly surprises with this approach.

Finally note that RAID, (even RAID 1, a mirror) is not true backup. It would be wise to come up with a way to regularly copy your data to a second independent device.

While this may not be what you're looking for, I hope it helps.

Zitat von Linkinsoldier

Unfortunately I only have one set of hard drives and yes, it's a raid1.

You could break your RAID 1 set (since it's a mirror) by physically removing a drive. Leave one drive (of the two) in your old server and use the other one in your new server. You could re-establish the RAID set once data is copied over to the new server, but I wouldn't. I'd use the old server as a physically separate backup of the new server or, if something is wrong with the old server, get an R-PI and a drive dock, and use the second drive with the R-PI for backup. (There are inexpensive ways to have solid backup.)

Zitat von Linkinsoldier

Would buy a 5tb external and copy the folders via USB help? Or do I read it correctly, that I have to brake the raid and restore it.

You could do the copy with an external drive, but a network copy (with Rsync) wouldn't cost anything. If you want the performance advantage of an internal data drive, you'd still have to break your RAID set.

Zitat von Linkinsoldier

Would buy a 5tb external and copy the folders via USB help? Or do I read it correctly, that I have to brake the raid and restore it? And what exactly means "copy the files via network" - wouldn't this have the same permission issue?

I'm making an assumption in the following, and that is file/folder permissions "inheritance" works the way it does in Windows.

- You could copy data in, VIA a USB drive, onto your new servers' drive, because in an external drive to internal drive copy, the original permissions are replaced by (or "inherited" from) the gaining drive. Thus if the original permission on a file was "root:root" (remember this permission would be set for the root account on your old server) the gaining drive would set it as "root:root" for the root account on the new server. (This assumes, of course that the new "root" account did the copy.) On the new server, if a specific parent directories' permissions are set to "user:user", with the recursive option, everything copied into this directory and its' sub-directories would inherit the "user:user" permission for the user account on the new server.

- Network copies would work the same as the USB drive, without the expense. All you'd need to do is "share" the directories you want to copy from the old server, and copy (Rsync) their contents onto the new server. You could even make them Samba shares (copy and paste) if that makes it easier for you.

Zitat von Linkinsoldier

Also: I have different owners for the different folders: would changing chown user:user via root work on the new machine?

(Assuming OMV would allow a foreign drive import. I'd like to try it sometime.)

This is why breaking a RAID set and simply inserting the drive into the new server, with data and old permissions intact, might present permissions problems. I think, (I don't know for sure) that you'd have to use CHOWN at the root directory ( / ) and force "root:root" from the top down, recursively, to use the drive. Then, you'd have to reassign specific user permissions manually.
I did mention you could try this; "but" there may be some tricky permissions set on data folders for "behind the scenes system users" that are installed by server plug-ins and other supporting services (SQL for example), that you're not aware of. A brute force, top down, permission change would wipe all that out.

On the other hand, if you build the new server from scratch with your data drive attached, set up your plug-ins, users, etc., those questions go away. Afterward, when you copy data into new user directories with permissions set recursively, file permissions are inherited. While there's work in it, a positive outcome is much more likely. In the bottom line, you've done it before when you built your old server. You can do it again.

The only factor you can't get away from is a hardware consideration. Are you going to buy a new internal drive or break your RAID set?

If you end up with an extra drive at the end of this exercise, give the R-PI backup idea some thought. Remember "RAID" is not backup and note that any server can fail catastrophically, taking a RAID set with it. A physically separate full backup is preferred. I have an Raspberry PI running OMV ($29), booting from a 8Gig SD card ($6), with a 2 amp USB power supply ($3 Ebay), and a 4 TB WD "My passport" ($119) that is powered by it's USB port connection to the R-PI. This is the ultimate for fully independent back up that is both low cost and low power (about 12 watts, total).

Just a thought.