Pull backup from nextcloud aio

I’m looking for the most simple solution to backup a nextcloud-aio to a server that can’t be connected to directly. The backup server would need to pull the backup from the nextcloud.

  • can’t generate the backup locally on the nextcloud-aio (no disk space) and don’t like this idea, because I’d want to use append only to a protected backup server
  • can’t connect to the backup server from the nextcloud-aio backup client
  • would like a solution that well integrates with concepts and support for nextcloud-aio

Thinking about my options I came across the question how to initiate a backup from the backup server on nextcloud aio in a way recommended and supported?

Hi,
first, it’s important to clarify how you’re currently performing backups of your Nextcloud AIO instance:

  • Are you using the built-in BorgBackup (e.g., via the AIO web interface or backup.sh)?
  • Or do you rely on a custom/manual backup method?

If you’re using BorgBackup, a supported and clean solution is to:

  • Trigger the backup via the AIO interface (no local disk space needed long-term if downloaded immediately after),
  • and then pull the backup from the AIO host using your backup server via SSH + rsync.

This respects the design of Nextcloud AIO, avoids opening outgoing connections, and fits well with your goal of maintaining append-only backups on a protected remote server.


If you’re not using BorgBackup, feel free to share more details about your setup — that way, it’ll be easier to recommend something that matches your requirements.

1 Like

Thanks for your answer!

This is a new installation. I’m planning how to backup it. It’s not productive, yet. So there’s no backup, yet.

I do not have the disk space to copy all the data locally.

Furthermore the temporary local repository would not be protected against modification on the nextcloud server, right? (I’m new to borg and do not know how append-only would work if I sync the repository after creation).

Thanks for the update — based on your goals, there are two possible approaches you can consider, depending on your system setup and preference:


:blue_square: 1. Using the integrated BorgBackup in Nextcloud AIO

If you’re running Nextcloud AIO on a supported system (e.g., Linux with Docker), you can use the built-in BorgBackup system via the AIO interface. By default, the backup is created locally on the host.

However, you don’t necessarily need to keep that backup on the same disk.
You can configure the system to store the backup on:

  • a second internal disk,
  • an external USB disk, or
  • a network-mounted location (like NFS, SSHFS, or CIFS).

This way, you avoid filling up your main system disk, and the backup repository can be placed on a protected and possibly append-only destination.

So even though BorgBackup creates the backup locally, it can directly write it to your desired storage if it’s mounted correctly on the host. This keeps the backup workflow clean and fully supported by AIO.


:green_square: 2. Manual backup via SSH + rsync (my personal experience)

When I migrated my full Nextcloud AIO instance to a new disk, I chose not to use BorgBackup. Instead, I performed the backup manually via rsync over SSH.

This method works just as well for routine backups. It gives you complete control over what gets backed up and where, without relying on BorgBackup or the AIO interface.

:small_blue_diamond: I shared more details about this approach here:
:link: Backup files on Nextcloud managed object storage to local storage

:warning: Important note:
If you choose this method, it’s very important to use a compatible file system (like ext4, xfs, or another POSIX-compliant one) on the backup destination.
This ensures that file and folder ownership (e.g., www-data) is preserved correctly, which is essential for a proper Nextcloud restore later on.

You can still combine this approach with your own protection strategy on the backup server — e.g., snapshots or append-only file attributes.

1 Like

How do you handle backups of the postgres database and of any open files? Does Borg handle that?

I like rsync very much and use it a lot. The advantage I see in an integrated solution is that it’d hopefully take care of all the details…

Great question — and yes, that’s exactly where the integrated BorgBackup in Nextcloud AIO really shines, especially if you want a built-in backup solution that handles everything for you.


:white_check_mark: What BorgBackup in AIO handles for you:

When you trigger a backup via the AIO interface (or via backup.sh), it takes care of:

  • a consistent PostgreSQL dump,
  • Redis cache and active application state,
  • all Nextcloud data, config, and volumes.

This happens in a coordinated and supported way, producing Borg archives ready for restore, with minimal user intervention.


:hammer_and_wrench: My experience with rsync-based Docker volume backup

When I migrated my full Nextcloud AIO instance to a new disk, I used rsync to copy all Docker volumes — and it worked perfectly. Since PostgreSQL and other service data live inside these volumes, there was no need for a separate database dump.

:bulb: Important: The target filesystem must support full ownership and permission metadata (e.g., ext4, xfs, etc.), otherwise restoring ownership like www-data may fail.

:link: I described the migration approach here:
Backup files on Nextcloud managed object storage to local storage

And here’s my complete migration guide (in Slovak):
:page_facing_up: Migrácia Proxmox VM na nový disk
Even though it’s written in Slovak, you can easily translate it using AI tools like DeepL or ChatGPT.

It’s a global migration guide for multiple Docker containers and volumes — so it’s not only useful for Nextcloud AIO, but also for backing up or migrating other containers that may be running alongside it.

Although I originally used this method for migration, it can be partially adapted for regular backups as well — especially if you want more transparency or full control over what’s being copied and when.


:bulb: How I currently handle backups

Currently, my Nextcloud AIO runs inside a Proxmox virtual machine, and I handle backups at the VM level using Proxmox’s built-in snapshot and backup tools (vzdump).
This captures the entire system — OS, Docker, data — in one consistent backup, and it has worked reliably for me.


Summary:

  • :white_check_mark: BorgBackup: great built-in solution for most use cases.
  • :toolbox: Rsync + Docker volume backup: worked perfectly for me during migration, and can be reused as a backup method.
  • :desktop_computer: Proxmox-level VM backup: my current approach for full instance backup and disaster recovery.
  • :package: Multi-Docker support: the rsync + volume backup strategy also works well for other containers running alongside Nextcloud AIO.
1 Like

Well, that sounds like rsync (or rsync-time-backup.sh) would need a lot more work and an integration I’d need to maintain myself. I guess I’ll need to look into borg and try one of its ways to initiate the backup from the backup server using ssh.

Is that inside the mastercontainer? I found daily-backup.sh inside the containers root directory, but not backup.sh. I’d need to call it when I want to trigger a backup push over a ssh session from the backup server.

Yes, if you’re planning to explore Borg, I definitely recommend taking a look at the official Nextcloud AIO documentation, as it explains how backup.sh works and how it’s meant to be used.

Just to clarify — backup.sh is executed inside the nextcloud-aio-mastercontainer, not inside the main Nextcloud app container. So make sure you’re looking in the right place.

Personally, I don’t use BorgBackup in my setup — I rely on Proxmox VM-level backups and occasional rsync-based volume backups, so I haven’t explored the Borg approach in depth myself.

But if you’re going for a fully integrated solution with proper support and maintenance over time, Borg is a solid direction. Good luck with your setup — let me know how it goes!

Hi @ChriChri I would recommend having a look at GitHub - nextcloud/all-in-one: 📦 The official Nextcloud installation method. Provides easy deployment and maintenance with most features included in this one Nextcloud instance..

Haha, thanks - I’d read that before, but didn’t remember that there’s the command hidden to trigger a backup.

If I understood that correctly, I’d do that call after preparing that borg can reach the configured repository via a temporary path/connection (already read some in the borg documentation), right?

I started to try this variant of pulling a backup (instead of pushing): Backing up in pull mode — Borg - Deduplicating Archiver 1.4.0 documentation

The point I failed so far is using export BORG_RSH="sh -c 'exec socat STDIO UNIX-CONNECT:/run/borg/reponame.sock'" on nextcloud-aio to redirect the access to the repo to a local socket generated by ssh -R.

Looking at start.sh in ghcr.io/nextcloud-releases/aio-borgbackup I found that the variable is set there if BORG_REMOTE_REPO is set.

How would I achieve having the variable set to the value mentioned in the borg documentation?

generate the backup locally in a network-fs.
(to me, the other ideas seem over-complicated).
GOOD LUCK

Thinking about it a bit more I’ll try this:

  • use pull method for borg with ssh-agent (disadvantage if I understood the configuration correctly: double encryption - double cpu usage)
  • if this works I have a good starting point to get productive

To get rid of the ssh inside ssh overhead there’d be need to change BORG_RSH like for the socat method as well.

I’ll look into that later as an improvement. I’d think that I’m not the only person for whom the backup storage is located in a security zone with a higher security level that can’t be connected to directly, but from which the repo server could pull a borg backup.

The changes for aio should be minimal to offer this as an option to admins.

Update:

Above idea didn’t work - it needs changing the containers, too. This works without changing any container:

on the docker server running nextcloud aio

  • create /etc/ssh/sshd_config.d/GatewayPorts.conf containing GatewayPorts clientspecified which will allow a client to bind to a different IP than 127.0.0.1 for a reverse port forward using ssh -R
  • set via the aio mastercontainer web interface the backup target as ssh://borgbackup@172.17.0.1/path/to/repo - make sure that 172.17.0.1 is the IP of the bridge interface for the nextcloud-aio docker network

on the backup repo server

  • create a user borgbackup
  • create the directory /path/to/repo and give read/write/access to borguser
  • make directory ~borgbackup/.ssh
  • create ~/.ssh/authorized_keys containing the key shown in the nextcloud aio web interface. Prepend the key by command="<path to borg>/borg serve",restrict
  • ssh to your docker server running nextcloud aio using ssh -R 172.17.0.1:6666:127.0.0.1:22 <nextcloud-aio-docker-server>. 172.17.0.1 should be like mentioned above the IP of the bridge interface of the nextcloud-aio network. 22 is the port sshd is listening on your backup repo server on.

With the ssh connection from the backup repo server to the docker nextcloud-aio server still open you should be able to start the initial backup from the nextcloud aio webinterface.

nextcloud-aio will start the nextcloud-aio-borgbackup container connected to the nextcloud-aio network. borg inside the container will connect via ssh to the ip of the bridge interface of the docker network nextcloud-aio port 6666.

On the bridge interface port 6666 listens sshd for connections to be forwarded back to the backup repo server port 22 where sshd of that server will answer.

sshd on the backup repo server will run the command= command defined in ~borgbackup/.ssh/authorized_keys (which in my case is important, because borg cannot be found via the default path of sshd on the synology nas which is my borg backup server).

Disadvantages

  • not very secure (see borg documentation about pull backups)
  • double encryption: ssh connection inside already encrypted ssh port forward

Todo (update: done)

1 Like

I already considered that, but my setup is not ready for that.

I have two NAS in two different locations. The one in the same location with nextcloud-aio provides already an iscsi drive for nextclouds user data. It would be bad performance to write the backup to the same nas over network and I’d have to still copy it as a backup to the other location.

The nas in the other location doesn’t have the network connectivity to have a separated network segment for iscsi.

And if the nextcloud aio server gets compromised it would be possible to damage the backups that could be found in the local filesystem.

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