I’d like to ask for some advice regarding my long-running Nextcloud AIO setup.
I’ve been running it for about three years without any reinstallation, but recently I’ve started to experience more and more issues — mainly frequent service crashes and the inability to reinstall or update certain apps.
Because of that, I’m considering a clean reinstallation of Nextcloud AIO (version 11.11.0) while keeping Nextcloud v31.0.10 on Ubuntu 24.04 (latest updates).
My goal is to preserve all user data, accounts, and settings, and basically reinstall only the “AIO engine” itself (Docker containers and system stack).
Currently, my backups are handled through Proxmox Backup Server, which is great for disaster recovery but doesn’t help with what I’m trying to achieve — a clean rebuild without bringing back existing issues.
So my question is: Is there any supported or recommended way to back up and later restore everything (database, config, users, apps, files) into a freshly installed AIO environment?
I’m aware that AIO includes an integrated BorgBackup feature, but I’ve never used it before and I’m not sure whether it’s suitable for this specific scenario.
Environment details:
Nextcloud AIO: 11.11.0
Nextcloud version: 31.0.10
Host OS: Ubuntu 24.04 LTS (latest updates)
Virtualized on Proxmox VE, with backups handled by Proxmox Backup Server
I might have overlooked this in the documentation, but could someone clarify what ownership and file permissions should be set on the directory where BorgBackup stores its data when running Nextcloud AIO on Linux?
I just want to make sure the container has the correct write access before I initialize the repository.
Usually any permissions are possible as long as root access is not prohibited. The backup solutions uses the root user to read and write the backup archive.
I ran a Borgbackup backup and then I read that I should have saved the Passkey as well, not just the encryption key.
This made me unsure, as I am not aware that I entered a Passkey.
I have the encryption key saved.
I’ve prepared a draft plan for how I intend to perform a clean reinstallation of Nextcloud AIO while keeping my existing BorgBackup repository ready for restore.
Here’s the outline of the procedure I’ve come up with:
Nextcloud AIO reinstallation – brief overview
Verify and back up current state (BorgBackup + Proxmox Backup)
Stop running containers (can be done via Portainer – Containers → Stop All or Nextcloud Admin settiongs)
Remove running containers (can be done via Portainer – Remove All Stopped)
Stop and remove mastercontainer (also possible in Portainer or docker compose down)
Verify Nextcloud functionality (Portainer – Logs / Health Status)
Clean up temporary or backup directories
Verify timezone and health status
Could you take a quick look at this plan and let me know if the order of steps looks correct, or if I’m missing anything important?
I’d like to make sure I follow the safest possible process before proceeding.
You’ve got a solid plan here, and the order of your steps is logical for tearing down an old instance and bringing up a new one on the same host.
However, to make this the safest possible process, I’ve identified one critical missing piece and a key refinement that will save you a major headache. Critical Missing Step: Mastercontainer & Caddy Configs
Your plan relies on the BorgBackup restore, which is great for your data. However, the AIO Borg backup does not back up the nextcloud-aio-mastercontainer configuration itself.
This includes:
Your domain name.
AIO-specific settings (like Borg schedule, etc.).
Your reverse proxy configuration (the Caddyfile, if you’re using Caddy).
If you just start a new mastercontainer and restore, it won’t know your domain or other settings, and Caddy (if used) won’t have its config.
What to do (add this before your current Step 1):
Find your old nextcloud_aio_mastercontainer volume.
You can find its location on disk with docker volume inspect nextcloud_aio_mastercontainer.
It’s typically at a path like /var/lib/docker/volumes/nextcloud_aio_mastercontainer/_data.
Manually back up these files:
config.json: This file contains all your AIO settings.
Caddyfile: (If it exists) This has your reverse proxy config.
You will need to manually place these files into the new mastercontainer’s volume after you start it for the first time but before you run the restore. Refinement to the Restore Process (Steps 8-11)
Your plan to “Set BorgBackup repository path” (Step 10) after starting the new container works, but it’s much safer and more reliable to mount the backup path when you start the new container.
Here’s the safer way:
When you get to your Step 8 (Start new AIO mastercontainer), modify the docker run command to include a bind-mount for your Borg backups.
Example docker run modification:
Add this flag to your command:
-v /path/to/your/borg/repo:/mnt/borg-backup
This maps your host’s backup folder (/path/to/your/borg/repo) to a folder inside the new mastercontainer (/mnt/borg-backup).
Then, in your Step 10 (Access AIO UI), when you set the Borg repository path, you’ll simply enter /mnt/borg-backup. This guarantees the container can see and access it correctly.
My Recommended “Safest” Plan (Revised)
Here is your plan with my safety additions integrated.
Pre-Backup (The Missing Step)
Find your current nextcloud_aio_mastercontainer volume location (e.g., /var/lib/docker/volumes/nextcloud_aio_mastercontainer/_data).
Manually copy the config.json and Caddyfile (if it exists) to a safe backup location (e.g., your home directory).
Verify Main Backup (Your Step 1)
Run one final BorgBackup from the AIO interface to ensure it’s 100% current.
Verify your Proxmox backup is also complete.
Tear Down Old AIO (Your Steps 2-7)
(Only necessary if you are re-using the same Docker host. If moving to a new server, skip this.)
Stop all running Nextcloud containers.
Stop and remove the nextcloud-aio-mastercontainer.
Prune unused images (docker image prune). A docker system prune is even more thorough.
Start New Mastercontainer (Your Step 8, Modified)
Run the official docker run command to start the new mastercontainer.
Crucially, add the bind mount for your Borg backup: -v /path/to/your/borg/repo:/mnt/borg-backup
(Optional but recommended) Also add a bind-mount for the new mastercontainer’s data so it’s easy to access: -v /some/path/on/host/aio-data:/var/lib/docker/volumes/nextcloud_aio_mastercontainer/_data
Restore Mastercontainer Config (New Step)
Access the new mastercontainer data folder you just created (e.g., /some/path/on/host/aio-data).
Stop the mastercontainer you just started (docker stop nextcloud-aio-mastercontainer).
Copy the config.json and Caddyfile you saved in Step 1 into this directory, overwriting the new, empty ones.
Start the mastercontainer again (docker start nextcloud-aio-mastercontainer).
Access UI and Restore (Your Steps 9-11)
Access the AIO UI (at your domain, which it knows from the restored config.json).
Log in with your AIO password.
Go to the “Backup” settings. Set the “Backup Directory” to the internal path: /mnt/borg-backup.
Enter your Borg encryption password and click “Restore a backup.” Select the snapshot you want.
Start and Verify (Your Steps 12-15)
After the restore finishes, go to the “Containers” page and start all the containers.
Verify functionality, check logs, and check the Nextcloud Admin “Overview” page for any errors.
Confirm your timezone and health status.
Clean up any temporary files.
This revised plan, especially by manually moving the config.json and Caddyfile, is far more robust and should result in a near-identical, fully functional new installation.
Would you like me to clarify any of those Docker commands or file locations?
Since I’m using NGINX Proxy Manager for domain and SSL management, those configs aren’t tied to the mastercontainer, and the BorgBackup setup already covers the relevant data paths.
I really like the complexity of your approach — it’s a thorough and fail-safe way to handle the process, especially for setups where the configuration is more tightly coupled with the container. I’ll keep this in mind for future deployments.
Still, your approach is definitely safer for setups that rely on Caddy, and I appreciate the clarification — it’s a useful note for others following the same path.
Is there any supported or recommended way to back up and later restore everything (database, config, users, apps, files) into a freshly installed AIO environment?
Nextcloud AIO reinstallation – brief overview
Critical Missing Step: Mastercontainer & Caddy Configs
Refinement to the Restore Process (Steps 8-11)