Nextcloud backup and disaster recovery guide

Nextcloud backup and disaster recovery: why the parts must be captured together

A Nextcloud backup must capture the data directory or object storage, the database and the config as one consistent set, and recovery is proven only by restore tests. If any one of those three comes from a different moment than the others, the restored instance can look healthy and still fail users in ways that are hard to trace. This section is for the team that runs Nextcloud today, or is about to, and needs to be able to say with evidence that files, shares and user accounts can be brought back after hardware loss, ransomware, a failed upgrade or accidental deletion.

A file-level copy of the data directory on its own usually fails. Nextcloud writes to the filesystem and the database continuously, so a copy taken over several hours can contain files that the database does not yet know about, or database rows that point to files copied before they existed. Share links, file versions, trash, activity and file locks live in the database, so their state depends on the matching files. The config file holds the instance secret and the database connection details, and if the instance uses server-side encryption, the keys and their settings must also be preserved. A copy that lacks any of these will restore to a state that Nextcloud may refuse to start from, or that silently loses access to encrypted files.

A formal plan becomes necessary when the data is regulated, when the instance spans more than one site or cloud region, or when users depend on external sharing for daily work. In those cases the questions are no longer only technical. You need written answers to who approves a restore, which data classes can be restored into which environment, how long backups are kept, and where copies are stored. Confirm these with your compliance owner and your data protection requirements before the design is fixed, because they change storage location, encryption and retention.

What makes this harder than it looks is that a backup job that finishes without errors proves very little. Maintenance mode must be entered before the snapshot and exited after it, otherwise the sets drift. Object storage buckets and local disks need their own consistency rules, and versioning or lifecycle policies on the bucket can remove data your restore expects. Restores also expose undocumented dependencies: apps, PHP extensions, the exact database version and custom configuration. Ask your team to restore into a separate environment on a fixed schedule, record how long each step took, and check that logins, shared links and a sample of encrypted files work afterward. The recovery time and recovery point targets should come from that evidence and from business owners, not from the backup tool's default settings.

Which Nextcloud components must be in the backup set

A Nextcloud restore is only as complete as the set of components it captures. Some items hold the only copy of user data and configuration, while others can be rebuilt from the software or are disposable caches. Working through each component tells you what must be backed up together so that files, database rows and instance settings still match after a restore.

Primary data directory or object storage

This holds the user files themselves. With local primary storage, it is the data directory on disk; with S3-compatible primary storage, the files live in the bucket and the local disk holds only instance metadata. Either way, files and database entries must come from the same point in time, because the database maps paths and file IDs to these objects. Confirm with your storage team how bucket versioning, replication or snapshots are configured, and whether they cover the whole bucket.

Relational database

The database stores users, shares, file metadata, versions, calendars, contacts and app data. Nextcloud 35 recommends MariaDB 11.8 or PostgreSQL 18, and supports MariaDB 10.11 to 12.3, PostgreSQL 14 to 18 and MySQL 8.4 or 9.7. Use the native dump or replication method for the engine you run, not a copy of raw database files taken while the server is writing. Check that your backup tool knows which engine and version is in use before a restore is needed.

Configuration file and instance secrets

The config/config.php file holds the instance secret, database connection details, trusted domains, and encryption-related settings. Without the instance secret and the correct configuration, restored data may not decrypt or authenticate correctly. Store a copy of this file separately from the data set, with restricted access, because it contains credentials. Record where the secret is held, since losing it can make restored content unusable.

Apps directory and custom apps

The apps directory holds installed third-party and custom apps, and the app configuration stored in the database must match these files after a restore. Include the directory in the backup set, along with a record of app versions and any locally patched code. Custom apps that are not in a public repository are only recoverable from your own copy, so treat them as source-of-truth items. Confirm that every installed app is compatible with the Nextcloud major version you will restore to.

External storage mounts outside the data directory

External storage mounts, such as SMB shares, NFS exports or other remote stores attached through the external storage app, keep files outside the data directory. Those files are not captured by a backup of the Nextcloud data directory alone. Build an inventory of every mount, its owner and its backup owner, and confirm that each one is protected by its own process. Mount configuration in the database must also be captured so that restored paths point to the correct locations.

Redis and APCu caches

Redis and APCu hold transient data such as file locking entries, memory-cached configuration and session-related state. Their contents are rebuilt when Nextcloud starts, so they are normally excluded from the backup set. Confirm that no critical state is stored only in Redis for your deployment, including locking data in a clustered setup. Document how the cache is flushed or restarted during a restore so that stale locks do not block users after recovery.

Which backup method fits the Nextcloud deployment

This table compares four backup approaches for a Nextcloud deployment: the BorgBackup component bundled in Nextcloud All-in-One, a custom script or host backup tool, storage snapshots with a separate database dump, and object storage versioning or replication. Read each row for the conditions where it fits, who owns the schedule and maintenance mode, and what it leaves uncovered. No single method protects the database, configuration and files together, so most designs pair one file-level method with a tested database dump.

Method	When it fits	Operational cost	What it does not cover
BorgBackup in Nextcloud All-in-One	Single-server All-in-One installs where the bundled backup container meets retention and recovery needs.	Schedule and retention are set in AIO. Confirm downtime and maintenance mode behavior for your version before relying on it.	Off-host copies, object storage buckets outside AIO, custom config files, and restore tests. Confirm the scope for your version.
Custom script or host backup tool	Teams that already run host-level backup tooling and want Nextcloud backups under the same policies and monitoring.	Your team writes and maintains the dump, copy and maintenance mode sequence, plus failure alerts. Step order drives consistency.	Restore testing, app and config drift, and verification that copies are complete and usable until someone restores them.
Storage snapshots with a separate database dump	Data directory on a volume that supports consistent snapshots, with the database dumped separately on its own schedule.	Files and database must be captured at a consistent point, often with maintenance mode. The storage team usually owns snapshot schedules.	Single-file restores, offsite copies, and database consistency with file state unless timing is controlled. Retention rules need separate sign-off.
Object storage versioning or replication	Primary storage is S3-compatible, so versioning or replication keeps copies of user data outside the Nextcloud host.	Versioning and replication rules are set in the storage platform. The database still needs its own dump and maintenance coordination.	Database, config.php and app data outside the bucket. Deletes replicate unless versioning is on. Confirm provider behavior.

How to build a consistent Nextcloud backup, step by step

This sequence produces one backup set in which the database, data directory or bucket, config.php and custom apps all describe the same point in time. Each step ends with a check so the team knows the backup can be restored before it relies on it.

Inventory the installation and record versions
The administrator records the installed Nextcloud server version, PHP version, database engine and version, web server, and every third-party app with its version. Confirm the running versions from the admin overview and the occ status command, then compare them with the system requirements for the release in use. Note where the data directory lives, whether primary storage is local or S3-compatible, and where config.php sits. This step is done when a written inventory exists and every component that must be restored can be named.
Choose a maintenance window or an online method
The owner decides between a consistent maintenance window and a method that avoids downtime. A window with maintenance mode enabled gives a database dump and file capture that match each other, but users cannot sync or share while it runs. An online method, such as storage snapshots combined with a database dump, shortens downtime but only works if the team can confirm that the database and file state are captured at matching points. The decision, the expected impact on users, and the restore point it protects should be written down and approved by the service owner. Check: a signed decision record exists before any capture begins.
Enable maintenance mode for the capture
If the chosen method needs a consistent capture, the administrator enables maintenance mode with the occ maintenance command before the database dump and file copy begin. Confirm that the status output reports maintenance mode as active so no user writes change files or the database during capture. When the capture finishes, disable maintenance mode and confirm the instance serves logins again and that sync clients reconnect. Check: occ status reports maintenance mode off, and a test login from an admin account succeeds.
Capture database, data, config and apps together
Within the same window, the administrator dumps the database using the native tool for the engine in use, copies the data directory or bucket contents, and copies config/config.php along with the custom apps directory and any theme files. All outputs go into one dated backup set with a manifest listing each component and its size. Check: the database dump restores cleanly into a scratch database, and the file count and total size of the copied data match the source. A mismatch means the set must be taken again before it is trusted.
Copy backups off the primary host
The team copies the complete backup set to a repository that sits outside the primary server, ideally in a separate cloud account, data center or storage system with its own access controls. A backup kept on the same host or in the same account as the server does not protect against loss of that host or its credentials. The copy should be verified after transfer. Check: a listing of the backup repository shows the newest set with the expected size, and a sample of files retrieved from the repository matches the checksums recorded in the manifest.
Encrypt backups and store keys separately
The team encrypts the backup set before or during transfer, and stores encryption keys or passphrases in a location separate from the backups, with access limited to named people. If the backup tool supplies its own repository encryption, such as BorgBackup in Nextcloud All-in-One, the key export must be stored apart from the repository and tested. Document who can retrieve keys and under what approval. Check: a restore test is run using only the key retrieved from the separate store, without access to the production host, and the restored data opens correctly.
Schedule runs and alert on failures
The team schedules the backup with cron, a systemd timer, or the scheduler built into the backup tool, and routes failure and missed-run alerts to a channel that someone monitors. The schedule should match the agreed recovery point objective, which the business should set rather than assume. Keep a record of the last successful run where operations staff can see it. Check: a deliberately failing job in a non-production environment produces an alert in the monitored channel, and the dashboard shows the date of the last successful backup.
Test a restore before every major upgrade
Nextcloud does not allow skipping major releases, so each upgrade moves one major version at a time, and the upgrade documentation requires a backup before every upgrade. Before starting a major upgrade, the team takes a fresh backup set using the steps above, restores it into a scratch environment, and confirms the Nextcloud instance starts and the data is readable. Third-party apps should be disabled until confirmed compatible. Check: the upgrade change record cites the backup identifier and the successful restore test, and both are linked before the upgrade begins.

What drives backup and recovery effort in a Nextcloud rollout

This table lists the factors that change how much work a Nextcloud backup and recovery design takes to build, run and prove. Each row names the driver, what it adds to the effort and how to keep it down. Read it before asking a partner or your own team for a quote, because most of these drivers should be settled in the design phase.

Driver	Why it changes effort	How to keep it down
Number of users and total data volume	Data volume sets backup window length, storage capacity and restore time. Every additional user usually adds files, versions and trash that the backup must hold and verify.	Set user-level quotas, define version and trash retention, and agree the expected data size with stakeholders before choosing a backup tool and schedule.
Number of storage backends and external mounts	Each external storage mount (SMB, NFS, cloud drives) may sit outside the main data directory, so it needs its own backup path, credentials and restore procedure. Files on mounts are not always captured by a data directory copy.	Limit mounts to those with a business need, document which backend owns which data, and confirm with the storage owner how each mount is backed up or can be rebuilt.
Object storage versus local disk	Local disk is usually backed up as a file-level copy of the data directory. Object storage needs versioning, bucket replication or snapshot settings, and the database must stay consistent with the object metadata at restore.	Choose one primary storage model where possible, confirm object versioning and replication features with the storage vendor, and test restore of both the database and the bucket together.
Database engine and size	The database holds file metadata, shares and permissions. Its engine determines the consistent backup method (such as dump, physical snapshot or replication), and its size affects dump time and restore duration.	Use a supported engine listed in the current system requirements, pick the backup method the engine supports well, and schedule database backups to match the file backup point in time.
Number of sites and off-site copies	Each site adds a replication or transfer path, bandwidth needs, separate retention and separate key management. Off-site copies must also be encrypted and tested for restore from the remote location.	Start with one off-site copy that meets the recovery target, reuse one backup platform across sites, and document the recovery order if a site is lost.
Retention and legal hold requirements	Longer retention multiplies storage and increases the number of restore points to manage. Legal hold may require preserving specific accounts or files beyond normal deletion, which needs a separate process.	Write retention periods by data class, confirm legal hold requirements with counsel, and avoid keeping every backup forever when a defined rule covers the obligation.
Compliance evidence needs	Assessors usually ask for proof that backups run, that restores were tested and that access to backups is controlled. Producing this evidence means logs, test records and change records are kept on a regular cycle.	Decide the evidence list early, automate backup job reports and log retention, and schedule restore tests with written results. DeployOpen prepares evidence; independent auditors issue any assessment outcome.
Number of environments (production, staging, test restores)	Each environment needs its own backup schedule or copy process, and test restores need a place to run that does not affect production. Restores into staging also need data masking if personal data is involved.	Keep staging small and refreshed on a set schedule, provision a standing restore test environment, and agree which environments are in scope for backup and for restore testing.

How backup and restore change across single node, clustered and Kubernetes deployments

On a single node, the web server, PHP-FPM, the database and the data directory usually run on one host or one tightly coupled pair of hosts. That makes consistency the main concern. Files and database rows must describe the same moment, or the restored instance will show file entries without matching metadata, or the reverse.

What to capture:

The data directory, including file ownership and permissions, captured at the same point as the database.
A database dump or physical backup taken while writes are paused, using maintenance mode through the occ command-line tool.
The config directory, which holds the main configuration file, secrets and instance identifiers.
Any custom apps, themes and web server or PHP-FPM configuration that the instance depends on.
The backup tool's encryption keys and repository location, stored apart from the backed-up host.

Restore order: restore the application code and configuration first, then the data directory, then the database. Run the file integrity and scan steps, confirm background jobs run, and only then leave maintenance mode.

Confirm with your environment whether the chosen backup tool captures the data directory and database in one run, and rehearse a full restore on a separate host before the first production backup is trusted.

How to protect backups, keys and restore access

Backups of a Nextcloud instance contain the same user files, shares and credentials as the live system, so they need the same protection and often more. The controls below cover who can read backups, who can restore them, where copies sit, and how every action is recorded.

Backup encryption and key custody

Decide whether the backup target encrypts data at rest and whether encryption keys are held separately from the backups they protect. Borg-based and other backup tools support client-side encryption, which keeps data unreadable to the storage provider. Confirm who holds the passphrase or key, where it is stored, and how it is recovered if the administrator who set it up leaves. A backup that cannot be decrypted during an incident is not a recovery plan.

Separate backup credentials from administrators

Use dedicated service accounts for backup jobs and object storage access, with write-only or append-only permissions where the tool supports them. Production administrators should not be able to delete or alter backup copies with the same credentials they use to manage the Nextcloud server. Review which people and automation accounts can reach the backup repository and remove shared or long-lived keys.

Immutability and write-once retention

Where the chosen backup target offers object lock, write-once retention or immutable snapshots, enable it with a retention period set by your recovery and legal requirements. This protects copies against ransomware that has gained administrator access to the source server. Confirm with the vendor how immutability interacts with deletion, lifecycle rules and storage costs, and test that a locked copy cannot be removed early.

Protect config.php secrets in the backup set

The config.php file holds the instance secret, database credentials, mail and integration passwords, and other values that let someone impersonate the server. Treat every backup that includes it as containing secrets. Restrict access to those archives, encrypt them, and plan how secrets are rotated if a backup set is exposed. Check that the backup job captures config.php consistently with the database and data directory.

Classify backups as sensitive data

Backups that include user files, shares, activity data and metadata carry the same classification as the source instance. Apply the same access reviews, retention limits, data residency rules and deletion obligations to backup copies, including copies held by a managed backup provider or in a second region. Record where each copy lives so that data subject requests and deletion commitments can be honored across backups.

Log backup and restore actions

Enable logging for backup job runs, repository access, key use, restore operations and changes to retention settings. Forward these logs to a system that the backup administrators cannot edit. During a restore, record who initiated it, which snapshot was used, the target environment and the outcome. Review these records regularly, and confirm that the Nextcloud audit log and backup logs cover the events your security team needs.

Restrict who can run restores

Limit restore rights to a named, small group that has been approved in advance, and require a second person to approve restores into production. Restores into a separate recovery environment should be possible without touching production credentials. Document the steps, the decision authority for restoring over live data, and the procedure for restoring a single user or share without exposing other users' data.

How to prove a Nextcloud restore works before you need it

A backup only counts once a restore from it has been tested. The test plan should restore the backup into an isolated environment running the same Nextcloud release as the source, because a restore onto a different release mixes two problems and makes failures hard to read. Start the instance, confirm the web interface loads, then log in with a dedicated test account that has known files and shares. Open one file and one share created by a different user, so you check that permissions and share records came back, not only the bytes on disk.

Next, compare the restored data with the source. Count files per user and per top-level folder, and compare checksums for a sample or, where the design allows it, for the full data directory. Confirm that the database and the data directory belong to the same point in time: the file cache and the database rows must agree with what is on disk. Then run the occ maintenance and integrity checks that Nextcloud provides, and confirm that background jobs resume and that the cron trigger runs. A restore that starts but leaves background jobs stalled will show up later as missing previews, failed sync and broken expiry rules, so record the result of each check in the test report.

Failure modes need their own tests because they are the cases a real incident produces. Test a backup taken while users are writing, since database and data directory snapshots taken at different moments can disagree. Test a restore with config.php missing, to see how long recovery takes and whether the instance secret, database credentials and trusted domains can be rebuilt from your records. Test a database restored without its matching data directory, and the reverse. Test a backup from an older release restored onto a newer one, and confirm that Nextcloud's upgrade path and app compatibility rules apply before you rely on that restore route. Label these as tests to run in your environment, not outcomes to expect.

Record the elapsed time for each restore test, broken down into copying data, restoring the database, starting the application and completing the checks. These timings describe what your environment actually did, and they are the only defensible input to recovery time targets. Agree the recovery time and recovery point figures with the business owner of the service, and write them down with the date and release they were measured on. This page does not supply target figures, because the right values depend on data volume, storage throughput, staffing and the business impact of downtime in your organization.

Ask any partner or internal team to hand over the restore runbook, the test report for each scenario, and the exact commands used to validate the instance. Repeat the test after each major upgrade, after changes to storage or database hosting, and at a regular interval set by the business owner. A restore test that has not been repeated after the environment changed describes the old environment, not the current one.

Questions teams ask before they hire help with Nextcloud backup

How much does a Nextcloud backup project cost?

The cost depends on the scope written into the quote, and DeployOpen does not publish a price list. Most of the cost is labor: design of the backup target and retention, configuration of the database dump, data directory or object storage copy, and maintenance mode steps, then restore testing that proves the backup works. Storage for backup copies, offsite replication and monitoring are separate cost lines, often paid to your cloud or data center provider. One-time work includes the initial build and the first restore test. Recurring work includes periodic restore drills, reviewing job failures and adjusting retention after upgrades. Ask any provider for a fixed-scope quote that lists each component, the environments covered, the restore tests included and who pays for storage and licenses.

How long does a Nextcloud backup and recovery engagement take?

Duration is set by the number of environments, the storage design and how many restore scenarios must be proven. A single instance with a local data directory and one database is simpler than a deployment with object storage, separate database servers and several app nodes. Other factors include whether a maintenance window must be agreed, how quickly storage targets and credentials are issued, and how many rounds of restore testing your data owners need to sign off. Ask for a timeline in the written scope with milestones for design, build, restore testing and handover, and confirm which dependencies sit with your team.

Can our internal team set up Nextcloud backups without outside help?

Yes, many teams can, provided they have people who understand Linux administration, the database engine in use, PHP and Nextcloud's occ command line tool, and scripting for scheduled jobs. The harder skills are consistency and recovery. Backups must capture the database, data directory or object storage and configuration together, with maintenance mode used where needed, and a restore must be tested end to end, not assumed. Check whether your staff have restored a Nextcloud instance before, and whether they can run the same test after each major upgrade.

What does the client need to provide for a Nextcloud backup project?

Expect to supply administrative access to the Nextcloud host, database and storage systems, along with credentials for any object storage or backup target. You will need a defined maintenance window for consistent backups and for restore tests on a non-production copy, plus approval for changes to production servers. Name data owners who can confirm restored content is correct before sign-off. Agree on recovery time and recovery point targets with the business, because these decide retention, frequency and where copies are stored. Confirm the storage location and any legal limits on where backup data may reside.

Is BorgBackup in Nextcloud All-in-One enough for our backups?

It depends on your recovery targets, your infrastructure and how much control you need. All-in-One is the official installation method and includes BorgBackup-based backups, which can meet some requirements for a single-server deployment. However, you should still verify the backup covers every component you run, that retention and offsite copies meet your policy, and that restores have been tested outside the default setup. All-in-One also limits customization, so an externally managed database, object storage or clustered design may need a different backup approach. Treat Borg as a candidate to evaluate against your requirements, not a settled answer.

Can DeployOpen certify that our Nextcloud backups meet a compliance standard?

No. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. DeployOpen can help prepare the systems, controls and evidence an assessor will review, such as backup configuration records, retention settings, restore test results and change logs. Ask your assessor early which evidence they expect, and confirm with them which control framework applies to your environment before scoping the work.

What should we ask a provider to include in a backup quote?

Ask for a written scope that names each environment, the backup targets and retention periods, the restore scenarios that will be tested and the acceptance criteria for each. The quote should state what is one-time work, what recurs, what is handled by your team and what is out of scope, such as storage capacity or licenses. Ask how restore tests are documented and who signs them off, and whether ongoing monitoring or drills are included. A fixed-scope quote lets you compare providers on the same deliverables rather than on hours alone.

How DeployOpen scopes, builds and hands over Nextcloud backup and recovery

DeployOpen treats Nextcloud backup and disaster recovery as one connected design covering the data directory or object storage, the database, configuration and maintenance mode. Each engagement is scoped in writing before work starts, then built, tested by restore and handed over with documented runbooks.

How we scope

Inventory where file data, database, config and app state live, including any object storage buckets
Confirm the backup method, such as BorgBackup in All-in-One or a separate tool, with your recovery requirements
Agree recovery time and recovery point targets with your business owners before choosing the design
Define the written scope, deliverables and timeline as a fixed-scope agreement before any work starts

How we build

Configure consistent backups that capture data, database and config together, with maintenance mode steps documented
Set up backup retention, encryption and off-site copies inside your own cloud accounts or data centers
Run full restore tests into a separate environment and record the measured time for each recovery path
Document each failure scenario, including partial loss, database corruption and a failed major version upgrade

How we hand over

Deliver runbooks for backup checks, restore steps, maintenance mode and verification after recovery
Walk your operations team through a live restore so they can repeat it without DeployOpen present
Provide monitoring and alerting guidance for failed backup jobs and stale restore points
Record the evidence of restore tests for your compliance assessors, who issue any audit opinion

How we support

Ongoing support, upgrades and recurring restore testing are available as a retainer
Retested backups after each Nextcloud major upgrade, since upgrades require a backup beforehand
Review of backup scope when apps, storage or database versions change in your environment
Confirm with us what response and coverage hours a retainer includes before signing

Nextcloud backup and disaster recovery