How to Backup Nextcloud: The Complete Guide

Nextcloud stores your files, not your backups. You need a separate backup strategy to protect your data, database, and configuration files separately. Start with the 3-2-1 rule: 3 copies on 2 different storage types with 1 off-site. Choose tools based on your deployment type (Docker, Linux, or Snap), then test every backup with a restore before you trust it.

Why Nextcloud Isn't a Backup (and What That Means for You)

Nextcloud is a file synchronization platform, not a backup system. This distinction matters. If you delete a file in Nextcloud, it syncs that deletion across all your devices within your retention window. If your server fails, you have lost everything unless you backed it up separately.

You might see the Nextcloud Backup app in the app store. Community forums report it works poorly or fails entirely for many users. The Nextcloud documentation itself recommends manual backup approaches over the GUI app. So we will not recommend it here. Instead, we will show you the approaches that work: command-line tools combined with proper automation.

Backup is not a single file. You must back up five separate components of Nextcloud. Each one requires a different strategy. Get one wrong and your restore will fail even if the others succeed.

The 5 Components You Must Back Up

Nextcloud depends on five components working together. Losing any one means losing data or functionality.

First: the database. Nextcloud stores metadata, user accounts, file ownership, sharing permissions, and calendar/contact data in a database. Your database is MariaDB, MySQL, or PostgreSQL depending on your installation. If you back up only the files and not the database, you restore orphaned files with no ownership or permissions. Size: typically 100 MB to 1 GB depending on user count and history.

Second: the data directory. This holds the actual files. On a Linux install, this is usually /data or /var/www/nextcloud/data. On Docker, it is a mounted volume. This directory can be many terabytes. Size: whatever you store.

Third: the config directory. Nextcloud reads from config.php at startup. This file contains database credentials, app settings, trusted domains, and security keys. If you restore data and database but not config, Nextcloud will not start. Size: just a few MB.

Fourth: custom apps. You may have installed apps beyond the bundled ones. Docker/AIO and some hosted versions do not let you add apps. Self-hosted Linux does. Size: 10 to 100 MB.

Fifth: themes and customizations. If you have created a custom theme or branding, back it up too. Size: under 10 MB typically.

Most backup failures happen because someone backs up files but forgets the database, or backs up the database but uses the wrong version of config.php during restore. This guide shows how to back up all five.

Preparing Nextcloud for Backup: Maintenance Mode

Before you back up, you must enable maintenance mode. Maintenance mode stops Nextcloud from accepting requests. This prevents users from modifying files while your backup is running, which would corrupt the backup.

Enable maintenance mode with the command: sudo -u www-data php occ maintenance:mode --on. Replace www-data with whatever user runs Nextcloud on your system (common values: www-data, www, nextcloud).

Wait for the backup to complete. Then disable maintenance mode with: sudo -u www-data php occ maintenance:mode --off. Do not forget to disable it. Users cannot access Nextcloud while maintenance mode is on.

If your backup takes longer than a few minutes, users will notice. Plan your backup for off-hours. Or use a tool like Borg that can back up a live system without locking, then enable maintenance mode only for the database dump.

The 3-2-1 Backup Rule

The 3-2-1 rule is the industry standard for backup strategy. It means: 3 copies of your data, on 2 different storage types, with 1 off-site.

Example one: Local backup on your server's disk (copy 1), external USB drive at the office (copy 2, different storage type), and cloud storage like Backblaze B2 (copy 3, off-site). Covers all three rules.

Example two: Live data on your server (copy 1), daily snapshots on the same server via LVM or ZFS (copy 2, same server but protected from corruption), and weekly exports to S3 (copy 3, different storage, off-site). This also works.

The point is: one failure should never destroy all copies. If your server burns down, copy 3 off-site still exists. If one backup tool corrupts a backup, the other two are unaffected. If ransomware encrypts your backups, at least one off-site copy is still clean.

Do not keep all three copies on the same server. Do not keep all backups in the same cloud account. Do not skip the off-site copy. Ransomware and data center disasters happen.

Backing Up Nextcloud Step-by-Step

Now we show three paths based on your deployment type. Choose one.

Option A: Docker/AIO + Borg Backup

If you use Nextcloud AIO (All-In-One Docker) or a manual Docker setup, Borg is the recommended approach in the Nextcloud community. Borg is a deduplicating backup tool with 13.9K GitHub stars. It compresses, deduplicates, and encrypts backups. One backup of 50 GB might consume only 12 GB with Borg due to deduplication.

Install Borg on your Docker host:

sudo apt-get install borgbackup

Initialize a Borg repository (where backups will live):

borg init --encryption=repokey /mnt/backups/nextcloud

Create a backup script at /root/backup-nextcloud.sh:

#!/bin/bash
CONTAINER_NAME="nextcloud-aio-master"
BACKUP_DIR="/mnt/backups/nextcloud"
DATA_DIR="/mnt/ncdata"  # Adjust to your data directory

# Enable maintenance mode
docker exec $CONTAINER_NAME sudo -u www-data php occ maintenance:mode --on

# Dump the database
docker exec $CONTAINER_NAME mysqldump -u root -p$(docker exec $CONTAINER_NAME grep MYSQL_ROOT_PASSWORD.env | cut -d '=' -f 2) nextcloud > /tmp/nextcloud-db.sql

# Backup with Borg
borg create $BACKUP_DIR::"nextcloud-$(date +%Y%m%d-%H%M%S)" $DATA_DIR /tmp/nextcloud-db.sql $(docker volume inspect nextcloud_aio_database | grep Mountpoint | awk -F'"' '{print $4}')

# Disable maintenance mode
docker exec $CONTAINER_NAME sudo -u www-data php occ maintenance:mode --off

# Cleanup
rm /tmp/nextcloud-db.sql

echo "Backup complete: $(date)"

Make it executable: chmod +x /root/backup-nextcloud.sh

Schedule it with cron. Edit crontab -e and add:

0 2 * * * /root/backup-nextcloud.sh

This runs the backup every day at 2 AM. Adjust to your timezone and traffic patterns.

To verify Borg is working: borg list /mnt/backups/nextcloud. You should see backups listed with dates.

Option B: Manual Linux Install + Restic Backup

If you installed Nextcloud manually on Linux (not Docker), Restic is a good alternative. Restic has 36.9K GitHub stars on GitHub and is faster than Borg for incremental backups. Like Borg, it deduplicates and encrypts.

Install Restic:

sudo apt-get install restic

Initialize a repository. For local storage:

restic -r /mnt/backups/nextcloud init

For remote storage (B2, S3, etc.), Restic supports many backends. Example with Backblaze B2:

restic -r b2:bucket-name:/nextcloud init

Create /root/backup-nextcloud-restic.sh:

#!/bin/bash
NCPATH="/var/www/nextcloud"
NCDATA="/var/www/nextcloud/data"
RESPO="/mnt/backups/nextcloud"
BACKUP_DATE=$(date +%Y%m%d-%H%M%S)

# Enable maintenance mode
sudo -u www-data php $NCPATH/occ maintenance:mode --on

# Dump database (adjust for your database type)
mysqldump -u nextcloud -p nextcloud > /tmp/nextcloud-db.sql

# Backup with Restic
restic -r $REPO backup $NCPATH $NCDATA /tmp/nextcloud-db.sql --tag nextcloud-$BACKUP_DATE

# Disable maintenance mode
sudo -u www-data php $NCPATH/occ maintenance:mode --off

# Cleanup
rm /tmp/nextcloud-db.sql

echo "Restic backup complete: $BACKUP_DATE"

Make it executable: chmod +x /root/backup-nextcloud-restic.sh

Schedule with cron:

0 1 * * * /root/backup-nextcloud-restic.sh

Verify: restic -r /mnt/backups/nextcloud snapshots. You should see a list of backups.

Option C: Snap + Duplicati (Extended from Kev Quirk Approach)

If you use Nextcloud Snap on Ubuntu, Duplicati is a good choice. Duplicati runs on Windows, Linux, and macOS, so if you need to backup to a Windows machine, this works. It has a web interface, so non-CLI users can manage backups.

Install Duplicati:

sudo add-apt-repository ppa:duplicati/duplicati-master
sudo apt-get update
sudo apt-get install duplicati

Start the Duplicati web UI:

sudo systemctl start duplicati

Once Duplicati is running, open your browser and navigate to localhost:8200 to access the Duplicati interface. Create a backup job:

1. Source: Add /var/snap/nextcloud/current/data (or wherever your Snap stores data)
2. Backend: Choose local folder, B2, or S3
3. Schedule: Daily at 2 AM
4. Retention: Keep 10 versions

Duplciati does not back up the database automatically. Create a separate task to dump the database:

mysqldump -u root nextcloud | gzip > /var/backups/nextcloud-db-$(date +%Y%m%d).sql.gz

Schedule this with cron before the Duplicati backup runs, then add /var/backups to your Duplicati job.

Testing Your Backup (Restore Verification)

An untested backup is not a backup. Many administrators create backups faithfully for months, then discover during a crisis that the backup is corrupted or incomplete.

Test your backup on a separate machine. You do not need full hardware: a laptop or a second VPS is enough. The goal is to verify the backup restores without errors.

For Borg, restore to a test directory:

borg extract -p /mnt/backups/nextcloud::latest /test/restore

For Restic:

restic -r /mnt/backups/nextcloud restore latest --target /test/restore

After restore, check: Do the database file and data directory exist? Are file counts reasonable (not zero)? Can you read a few files?

If you can, restore to a test Nextcloud instance. Start with a fresh Nextcloud install, then copy the restored database, data directory, and config files. Start Nextcloud and log in. If it works, your backup works.

Do this test at least once a month. Document the results. If restore fails, you will know immediately instead of during an actual disaster.

What Managed Nextcloud Hosting Handles for You

If you run Nextcloud yourself (self-hosted), all of the above is your responsibility. You must enable maintenance mode, run backup scripts, test restores, and manage off-site storage.

With managed Nextcloud hosting like Opsily's Nextcloud hosting, the provider handles the heavy lifting. Opsily manages daily snapshots, off-site replication, and database backups as part of the service. You do not write backup scripts or manage cron jobs.

You still control application-level concerns: file versioning policies, retention settings, and sharing permissions. You can explore managed hosting options to see pricing.

For most small teams, managed hosting eliminates the operational burden of backup management. For enterprises with specific compliance or data residency needs, self-hosted with custom backup tools offers more control.

Tools Comparison: Borg vs. Restic vs. Duplicati

All three tools work. The choice depends on your comfort level and infrastructure.

Borg is powerful but has a steeper CLI learning curve. Restic is more approachable and faster for most teams. Duplicati is the easiest if you prefer a web interface and are willing to trade performance for ease of use.

Choose the tool you will actually use and test, not the theoretical "best" tool. If you do not test your backups, the tool does not matter.

Frequently Asked Questions

Is the Nextcloud Backup app reliable?

The official Nextcloud documentation recommends manual backup methods over the Backup app. Community forums report frequent failures. If you want a GUI solution, use Duplicati with a separate database dump instead of relying on the Nextcloud Backup app.

How often should I back up?

Daily is the standard for production systems. For a small team server, daily is overkill. Weekly backups are acceptable if your data changes slowly. The frequency depends on your RPO (recovery point objective): how much data loss can you tolerate? If one day of lost files is critical, back up daily. If one week is acceptable, weekly is fine.

Can I back up while Nextcloud is running?

No, not safely. Some tools like Borg can back up a live filesystem, but Nextcloud's database will be inconsistent. Always enable maintenance mode before backing up the database. Maintenance mode takes a few seconds to enable and disable, so the impact is minimal.

What storage should I use for off-site backups?

Backblaze B2 costs $6 per terabyte per month. Amazon S3 costs $23 per terabyte per month. Google Drive for business is $20 per user per month with unlimited storage. Wasabi is $5.99 per terabyte per month. Choose based on integration with your backup tool and cost. Borg and Restic support B2 and S3 natively. Duplicati supports all four.

How do I know if my backup is working?

Test it. Restore to a test system monthly. Check the backup logs for errors. Verify that the backup size grows over time (if it stays the same for weeks, something is wrong). Set up email alerts in your backup tool to notify you of failures.

Should I encrypt my backups?

Yes. Borg, Restic, and Duplicati all encrypt by default or with an option. If your off-site storage is compromised (hacked S3 bucket, employee theft), encrypted backups protect you. The encryption keys should be stored separately from the backups.

Can I back up multiple Nextcloud servers to one storage location?

Yes. With Borg or Restic, create a separate repository for each server. With Duplicati, create a separate backup set. Deduplication will find common blocks across servers and save storage. This is one reason Borg's aggressive deduplication is useful in larger deployments.

How long does a Nextcloud restore take?

Depends on the size. A 100 GB restore to local storage takes 10-30 minutes with Borg or Restic. A restore to a remote VPS over a slow connection takes longer. Test your restore speed before you need it. Document how long it takes so you know the RPO (recovery time objective) if a disaster strikes.

The Bottom Line

Backup is not Nextcloud's job. You must separate your backup strategy into five components: database, data directory, config files, custom apps, and themes. Use the 3-2-1 rule to ensure resilience. Test your backup monthly on a separate system. Choose your tool (Borg, Restic, or Duplicati) and commit to testing it. If you prefer not to manage backups yourself, managed Nextcloud hosting handles this for you.