I have Nextcloud 12.0.3 running on a CentOS Linux server, and it’s running without issues. I have 8-10 users, and a total of about 130 GB of data among them. I’m using local LDAP authentication, which is also working without issues.
For a variety of reasons, I’m looking into migrating this instance to a different server. That system would still be running on a CentOS base, but using Active Directory instead. It will also have rather a different directory layout, but I don’t expect that to be a major problem.
My concern is that the user data directories in Nextcloud, both on the old system and the new, are using long hex numbers rather than the usernames (directory names like fe46de38-fa60-1034-85fc-210f940426a1 on the old system, B66D296C-43B2-41CC-8756-FAD170888067 on the new). I don’t expect that, even with the same usernames on the old and new systems, those IDs will remain consistent.
So, I have thousands of files, and about 130k rows in the database, that I’m going to need to account for. How would I go about making a migration like this?
Identify the UIDs on each system that correspond to each user
Migrate the data and the database from the old system to the new
For each user’s data, move it from (old UID) to (new UID) in the /data/ directory
For each user, replace (old UID) with (new UID) in the database
It sounds like a fairly manual process, which isn’t what I’d prefer, but at least I don’t have very many users to need to iterate through steps 3 and 4. And I expect phpmyadmin can make pretty quick work of the last step.
What am I missing here? Any insight on the first step?
OK, the first step turns out to be straightforward enough. Log in to Nextcloud as admin on the old server, go to the users page, and it will list the UUIDs with the corresponding full names. Do the same on the new server. A bit of copy and paste into a spreadsheet, and that’s sorted.
Step 3 isn’t hard. A little tedious, but not too bad with a handful of users.
On step 4, there are a lot of tables in that database. I can tell I’ll need to do the find/replace in oc_activity, and it looks like I’ll need to in oc_files_trash as well. It looks like I’ll need to copy over oc_filecache unchanged. What else should I leave alone/copy unchanged/copy and replace UUIDs?
Apparently nobody’s tried this before–or if they have, they don’t read here. For the sake of posterity, here’s what I’ve tried so far between a couple of test VMs.
Pretty much following the steps I outlined above. The Users page on the old and new Nextcloud installations made it simple enough to correlate the old and new UUIDs to their respective users. Midnight Commander made it fairly straightforward to move the data directories to the right place while renaming them appropriately.
My test source VM didn’t have anything in oc_files_trash, so I didn’t need to mess with that table. I replaced the UUIDs, one by one, in the user and affecteduser columns of oc_activity, and then copied that table over to the database for the new installation. I also copied over the oc_filecache table unchanged. I probably should have put Nextcloud in maintenance mode while doing this, but I didn’t for this test.
Result is that I’m able to log in to the new Nextcloud installation as any of the users who had files in the old installation, and see those files. This is looking like a success.
Would still appreciate any input into other tables that should be copied, with or without changes.
Edit: Well, I think I’ve found one other table. In the oc_share table, the same find/replace would be needed in uid_owner and share_with. Wasn’t an issue on my test install as I hadn’t shared anything.
Also in oc_share_external, the user column should be updated. Looks like the same is needed for the oc_uid column in both oc_storagecharts2 and oc_storagecharts2_uconf.