How to move AIO to new server; help please

ℹ️ Support 📦 Appliances (Docker, Snappy, VM, NCP, AIO)
1

I’m trying to move my AIO system to a new server. So I read a bunch of the documentation and decided to make a “backup” using the master container UI. The backup seemed to succeed. I chose /mnt/backup where it then created a borg directory. The logs said that it backed up into /mnt/borgbackup though. No idea what was going on there.

Next I used “rsync -avz” to copy the data from /mnt/backup/* (the whole borg directory) to the new server (/mnt/ncdata/backup).

I went to restore on the new system, entered the borg backup password and /mnt/ncdata/backup which succeeded. Then hit restore. As soon as it started to restore files it apparently tried to use rsync? All I got were errors like:

rsync: [sender] send_files failed to open "/tmp/borg/nextcloud_aio_volumes/nextcloud_aio_nextcloud_data/blah/blah/blah.gif": Socket not connected (107)

It ends with nothing restored and this:

2025-07-02T01:31:33.703551848Z Number of files: 46,542 (reg: 40,347, dir: 6,037, link: 158)
2025-07-02T01:31:33.703560875Z Number of created files: 739 (reg: 739)
2025-07-02T01:31:33.703567127Z Number of deleted files: 744 (reg: 740, dir: 4)
2025-07-02T01:31:33.703573153Z Number of regular files transferred: 741
2025-07-02T01:31:33.703567951Z rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1338) [sender=3.4.0]
2025-07-02T01:31:33.703579093Z Total file size: 6.72G bytes
2025-07-02T01:31:33.703601320Z Total transferred file size: 3.44G bytes
2025-07-02T01:31:33.703608706Z Literal data: 1 bytes
2025-07-02T01:31:33.703614609Z Matched data: 0 bytes
2025-07-02T01:31:33.703620190Z File list size: 0
2025-07-02T01:31:33.703626050Z File list generation time: 0.021 seconds
2025-07-02T01:31:33.703631703Z File list transfer time: 0.000 seconds
2025-07-02T01:31:33.703637214Z Total bytes sent: 1.34M
2025-07-02T01:31:33.703642796Z Total bytes received: 3.93M
2025-07-02T01:31:33.703648779Z 
2025-07-02T01:31:33.703654253Z sent 1.34M bytes  received 3.93M bytes  84.26K bytes/sec
2025-07-02T01:31:33.703660000Z total size is 6.72G  speedup is 1,276.66
2025-07-02T01:31:33.704432383Z Something failed while restoring from backup.
2025-07-02T01:31:33.708300126Z sending incremental file list
2025-07-02T01:31:33.709238164Z delta-transmission disabled for local transfer or --whole-file
2025-07-02T01:31:33.709255029Z rsync: [sender] send_files failed to open "/tmp/borg/nextcloud_aio_volumes/nextcloud_aio_mastercontainer/data/configuration.json": Socket not connected (107)
2025-07-02T01:31:33.709954344Z total: matches=0  hash_hits=0  false_alarms=0 data=0
2025-07-02T01:31:33.831127816Z 
2025-07-02T01:31:33.831181609Z sent 74 bytes  received 102 bytes  352.00 bytes/sec
2025-07-02T01:31:33.831240907Z total size is 1.82K  speedup is 10.32
2025-07-02T01:31:33.831178696Z rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1338) [sender=3.4.0]
2025-07-02T01:31:33.831611045Z Something failed while restoring the configuration.json.

Then the entire borg directory is emptied.

So I created a soft link from /mnt/ncdata/backup to /mnt/backup because /mnt/ncdata is the 10TB volume that has the space for all of this. I rsync’d the whole borg directory back again. Same program, no files, deletes all of the data.

I don’t have space for 3 copies of all of my data on the old server so I deleted the data in the borg directory and tried to start over. I guess that was bad because now I get:

2025-07-02T01:39:49.613825478Z /mnt/borgbackup/borg is not a valid repository. Check repo config.
2025-07-02T01:39:49.718061357Z Initializing repository...
2025-07-02T01:39:50.794233711Z using builtin fallback logging configuration
2025-07-02T01:39:51.269757769Z 33 self tests completed in 0.48 seconds
2025-07-02T01:39:51.286188286Z Initializing repository at "/mnt/borgbackup/borg"
2025-07-02T01:39:51.509821558Z Key in "<Repository /mnt/borgbackup/borg>" created.
2025-07-02T01:39:51.509887050Z Keep this key safe. Your data will be inaccessible without it.
2025-07-02T01:39:51.533324144Z check_free_space: few segments, not requiring a full free segment
2025-07-02T01:39:51.533378450Z check_free_space: calculated working space for compact as 0 bytes
2025-07-02T01:39:51.533459786Z check_free_space: required bytes 169138, free bytes 588971159552
2025-07-02T01:39:51.602170517Z security: previous location file /root/.config/borg/security/bd8a11bf774b1895d9247edd54c3f0c907f91826c255ec887602791577fc4f48/location not found
2025-07-02T01:39:51.602218387Z security: manifest timestamp file /root/.config/borg/security/bd8a11bf774b1895d9247edd54c3f0c907f91826c255ec887602791577fc4f48/manifest-timestamp not found
2025-07-02T01:39:51.602280815Z security: determined newest manifest timestamp as 
2025-07-02T01:39:51.602358118Z security: remembering previously unknown repository
2025-07-02T01:39:51.602531565Z security: saving state for bd8a11bf774b1895d9247edd54c3f0c907f91826c255ec887602791577fc4f48 to /root/.config/borg/security/bd8a11bf774b1895d9247edd54c3f0c907f91826c255ec887602791577fc4f48
2025-07-02T01:39:51.602608777Z security: current location   /mnt/borgbackup/borg
2025-07-02T01:39:51.602698725Z security: key type           5
2025-07-02T01:39:51.602756947Z security: manifest timestamp 2025-07-02T01:39:51.509676
2025-07-02T01:39:51.629116925Z security: repository checks ok, allowing access
2025-07-02T01:39:51.631461875Z Synchronizing chunks cache...
2025-07-02T01:39:51.631880609Z Archives: 0, w/ cached Idx: 0, w/ outdated Idx: 0, w/o cached Idx: 0.
2025-07-02T01:39:51.633241189Z Verified integrity of /mnt/borgbackup/borg/index.1
2025-07-02T01:39:51.633270489Z Done.
2025-07-02T01:39:51.633461993Z security: saving state for bd8a11bf774b1895d9247edd54c3f0c907f91826c255ec887602791577fc4f48 to /root/.config/borg/security/bd8a11bf774b1895d9247edd54c3f0c907f91826c255ec887602791577fc4f48
2025-07-02T01:39:51.633530190Z security: current location   /mnt/borgbackup/borg
2025-07-02T01:39:51.633647708Z security: key type           5
2025-07-02T01:39:51.633690951Z security: manifest timestamp 2025-07-02T01:39:51.509676
2025-07-02T01:39:51.675644888Z 
2025-07-02T01:39:51.675687583Z IMPORTANT: you will need both KEY AND PASSPHRASE to access this repo!
2025-07-02T01:39:51.675695620Z 
2025-07-02T01:39:51.675701356Z Key storage location depends on the mode:
2025-07-02T01:39:51.675707231Z - repokey modes: key is stored in the repository directory.
2025-07-02T01:39:51.675739944Z - keyfile modes: key is stored in the home directory of this user.
2025-07-02T01:39:51.675748343Z 
2025-07-02T01:39:51.675754116Z For any mode, you should:
2025-07-02T01:39:51.675760378Z 1. Export the borg key and store the result at a safe place:
2025-07-02T01:39:51.675766207Z    borg key export           REPOSITORY encrypted-key-backup
2025-07-02T01:39:51.675772170Z    borg key export --paper   REPOSITORY encrypted-key-backup.txt
2025-07-02T01:39:51.675777976Z    borg key export --qr-html REPOSITORY encrypted-key-backup.html
2025-07-02T01:39:51.675783867Z 2. Write down the borg key passphrase and store it at safe place.
2025-07-02T01:39:51.675789778Z 
2025-07-02T01:39:57.596045298Z Repository successfully initialized.
2025-07-02T01:39:57.596091459Z Performing backup...
2025-07-02T01:39:57.598950355Z Starting the backup...
2025-07-02T01:39:59.442233310Z Creating archive at "/mnt/borgbackup/borg::20250702_013957-nextcloud-aio"

Note that the paths are wrong again and now I guess I lost my backup key?

Is there really no way to move from AIO to AIO cleanly without using a third party backup system?

What is my best path forward at this point?

I apologize profusely for my frustration, but I’ve used ownCloud all the way up through this latest Nextcloud. Throughout MANY versions and a handful of servers I’ve always been able to easily migrate, but this AIO system is arduous at best.

2

Hi ,

I read through your situation and I’m confident my migration guide covers exactly what you need. I recently migrated my Nextcloud AIO (Docker) setup (along with other Docker apps) to a new server and documented the process here:

:backhand_index_pointing_right: Migrating Nextcloud AIO Docker server from ext4 to XFS

In that post, I describe:
:white_check_mark: What containers and paths must be saved for local backup of my Docker data.
:white_check_mark: The recommended filesystem for the target disk: XFS — this is critical, because XFS ensures that permissions and ownerships are preserved correctly during migration. I deliberately avoided NTFS (which breaks permissions) and even ext4, because I wanted to be 100% confident about ownership and rights integrity.
:white_check_mark: The exact rsync command I used, which ensures that owners, groups, permissions, symlinks, and hardlinks are all transferred correctly.

:warning: Important:
Make sure your local backup disk is also formatted with XFS. If you use NTFS (or similar filesystems that don’t fully support Linux permissions), you will lose ownership and rights data.

I didn’t use the built-in Borg backup of AIO, because my goal was to migrate the whole Docker stack cleanly in one process.

1 Like
3

I’ll submit a bug for this, but the issue is that you cannot have the backup in the same directory as your data. If you do this the restore process begins by deleting the backup. :roll_eyes:

4

Hi,

I think you misunderstood the point of what I wrote.
I’m not creating the backup in the same directory as the data on the server.
The backup goes over LAN to a completely different machine (my desktop) where I have an XFS data disk. That’s why there’s no situation where the backup would be in the same directory and get deleted during the restore.

I wanted to show that I handle AIO (Docker stack) migration outside of the built-in Borg backup system, because this way there are no issues with permissions, ownerships, or unnecessary data deletion.
XFS is key here because it preserves ownership and rights during the rsync transfer.

5

Sorry!

What I did, as listed above, put the backup in the same directory as the data directory.

Your path looks great and I do like your path a bit better. I didn’t stumble on it before I found szaimen’s instructions which promote the use of Borg. Since I was part way through with the Borg solution I finished on that path after figuring out that Borg deletes the backup as part of the restore.

Either way, migration should be a LOT smoother IMNSHO.

6

I cannot help You with Your problem, sorry, only report that I executed about ten migrations of my instance between different platforms - own hardware items and vps - via

with not a single issue. Ergo not all hope is lost :innocent:

2 Likes
7

Thanks brother! It did finally work as I noted, just didn’t expect Borg to delete the backup as part of the restore.

1 Like
8

This was fixed today. See restore process deletes backup · Issue #6607 · nextcloud/all-in-one · GitHub

1 Like
9

I saw that and thanked you! Just for reference here; Thank you very much again! Really appreciate it.

1 Like
10

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.