Migrate from Nextcloud-AIO to official Nextcloud docker

Hi,

I want to migrate from a working Nextcloud AIO instance to the official Nextcloud docker image both on the same server. Since AIO does a lot under the hood, which is not directly obvious to the user, I find it rather difficult to migrate everything, not just files, to Nextcloud docker and only found topics covering the other way around. Can someone help me out on this?

Thx and best regards

welcome back @smio0 :handshake:

you can always follow Migrating to a different server — Nextcloud latest Administration Manual latest documentation you might need to check your existing installation where the required parts are stored at the end but it is more or less always the same - move database, files and config and adjust access rights and your are fine.

P.S. AiO is the “most official” Docker installation. The microservices image located at https://github.com/nextcloud/docker is called “community image” and is developed somewhat independent…

5 Likes

Is the database migration the main thing you’re stuck on? Or the file part?

The generic approach (including caveats to watch out for) at a high-level is exactly the same as that described in the Admin Manual chapter mentioned by @wwe, but obviously needs to be adjusted into Docker specific ways of doing things (e.g. docker compose exec to run commands at the command line and figuring out which container names to exec into).

Migrations though are fairly straightforward:

  • Copy all files from the datadirectory to the target
  • Import database into the target

There are a lot of ways to copy files around and export/import databases. Nextcloud doesn’t much care which approach you take.

The main things to keep in mind:

  • bring up your fully functioning target environment first in whatever way you prefer (albeit without any of your existing data obviously)
  • target environment should be the same Server version (i.e. 28.0.5)
  • target environment needs to be PostgreSQL based (at least for the migration itself; you can always convert afterward)

You’ll be doing three things:

  • Bringing up a generic target environment (i.e. just a simple installation with the above constraints)
  • Exporting the database on the source environment and importing it into the target environment
  • Copying over the files
  • Mildly adjusting your config (e.g. dbhost)

The Admin Manual link provided by @wwe (which admittedly is intended for a generic bare metal installation), the AIO Migration doc (which you’ll sort of being doing in reverse), and the micro-services image’s generic Migration Doc, covers all of the steps between them (albeit not in a perfectly oriented way for the specific path you’re taking admittedly).

If you are stuck on a specific spot, I’m sure we can find a way to help coach you through it if you share where you’re stuck or most hung up.

P.S. Do keep in mind that the micro-services image is meant as a baseline image for expert users. It does not necessarily have everything you may want by default. For example, you’ll need to do a custom build (e.g. via a Dockerfile) to add things like SMB, ffmpeg, etc. to it if those are important to you.

If you are going to migrate, I suggest first getting a target environment up - using your desired image - that doesn’t have your data in it but otherwise meets all the requirements above (same Server version + PostgreSQL) and any other requirements you have (unless you’ve already done that of course!).

3 Likes

I see. I just have a few problems with AIO:

  • Only access via ports 443 and 80 seems to be supported, even with a reverse proxy in front
  • I don’t see a way for additional container hardening (removing capabilites, adding no-new-privileges, using different runtimes for strong isolation like Kata and gvisor and so on)
  • I am thinking about switching my docker containers over to podman (not 100% decided yet) and AIO does not seem to work well with podman

Do you think some of these points can be resolved with AIO?

Do I also need all the automatically created volumes of the different AIO containers?
These are the volumes AIO created:

local     nextcloud_aio_apache
local     nextcloud_aio_clamav
local     nextcloud_aio_database
local     nextcloud_aio_database_dump
local     nextcloud_aio_elasticsearch
local     nextcloud_aio_mastercontainer
local     nextcloud_aio_nextcloud
local     nextcloud_aio_redis
  • Can I simply reuse the database container volumes “nextcloud_aio_database” and “nextcloud_aio_database_dump” with a new postgres container or do I need to use the databases export functionality?
  • Where do I get the database usernames and passwords from AIO?

Hi, you might want to check out all-in-one/manual-install at main · nextcloud/all-in-one · GitHub

Also see GitHub - nextcloud/all-in-one: 📦 The official Nextcloud installation method. Provides easy deployment and maintenance with most features included in this one Nextcloud instance. regarding podman

1 Like

I don’t want to convince you for using AiO. Myself didn’t adopted it various reason so far. Definitely community docker image is far more flexible but also requires much more invest to make it running smooth. If you are skilled this might be the better path as you have more aspects of under control. If you decided to follow community image path some of your concerns are addressed in this guide: Nextcloud docker-compose setup with notify_push (2024)

Regarding 80/443 ports - even there is no technical reason to stick with default ports this is still best practice as many corporate networks and providers block non-default ports even in outgoing direction. I would recommend to use default ports whenever possible.

1 Like

Not unless you’re going to continue to use AIO.

Can I simply reuse the database container volumes “nextcloud_aio_database” and “nextcloud_aio_database_dump” with a new postgres container or do I need to use the databases export functionality?

I would export.

Where do I get the database usernames and passwords from AIO?

Your Nextcloud config.php. Just like any other Nextcloud environment.

2 Likes
  1. Convert containers to docker-compose (not the master-container)
  2. Comment out/delete from docker-compose.yml wherever you see hostname: ... and read_only=true.
  3. Then just docker compose up -d