Multi-server applications: getting the database, files and index to the same recovery point

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.

An application that looks like one system is often several. A database knows which documents exist and who owns them. A file store or object storage bucket holds the documents. A search index lets people find them. A cache or job queue holds work in progress. Each part may live on its own server.

Each part can be backed up successfully and the restore can still fail in a quiet way: the database lists a file the store does not hold, or search returns results that open to an error. This guide is for application owners who need the parts to agree after a restore. It draws on what several vendors say about their own products, because they describe the problem plainly.

Why it matters

A backup of each component taken at a different moment captures each at a different point in time (our reading). If users kept working between those moments, the restored parts will describe slightly different worlds.

Vendors respond to this in three ways:

• Pause the application so nothing changes while the parts are copied.
• Treat some parts as rebuildable from the authoritative part after restore.
• Back up some parts separately, because the main backup tool does not include them.

Knowing which applies to each component is the core of a multi-server recovery plan (our recommendation).

Pause the application first

Nextcloud's manual lists five things to keep: "The config folder", custom apps, "The data folder", "The theme folder" and "The database". Before copying them it uses maintenance mode, which "locks the sessions of logged-in users and prevents new logins in order to prevent inconsistencies of your data."

Its database dump uses --single-transaction, which gives a consistent database copy. But the database and the data folder are copied separately, so maintenance mode is what keeps them in step (our reading).

GitLab describes a similar condition for its background job system. Its backup page says Redis holds "persistent data for our background jobs system, Sidekiq" and that "The provided backup command does not back up Redis data. This means that in order to take a consistent backup with the backup command, there must be no pending or running background jobs."

The general lesson is to identify every writer, including background jobs and integrations, and use the product-supported pause or drain procedure. Record its acknowledgement and keep the required writers quiesced until each component has established its consistent capture. The exact boundary depends on the product: a file copy may require a pause through completion, while an established snapshot can transfer asynchronously afterwards. Record capture and transfer completion separately, and check that every protected component ultimately succeeded (our recommendation). Measure the pause because it is downtime for users.

Know which parts can be rebuilt

Not every part needs a matching backup. Some can be regenerated from the authoritative store.

GitLab says of its optional search engine: "The backup command does not back up Elasticsearch data. Elasticsearch data can be regenerated from PostgreSQL data after a restore." In that design, the search index is not a source of truth; rebuilding it after restoring the database brings it back into line (our reading).

Elastic's own guidance, for clusters used as primary stores, is different. It recommends snapshots for "all Elasticsearch system indices and the cluster state, even if your data can be reindexed or recovered from other external sources." It is also firm about method: "Taking a snapshot is the only reliable and supported way to back up a cluster. You cannot back up an Elasticsearch cluster by making copies of the data directories of its nodes."

For each component, record (our recommendation):

An Elasticsearch snapshot is not one precise cluster-wide instant. Elastic states that each shard is captured at some point between the snapshot start and end times. Matching a snapshot filename or start time to a database backup does not prove that they agree. If cross-component consistency requires unchanged data, coordinate all writers over the necessary capture interval using a supported procedure; where the index is derived, rebuilding it from the restored authoritative data may be the clearer option.

Rebuilding takes time. A search index for a large application may take hours to regenerate, so its rebuild time belongs in the recovery time estimate (our understanding).

Find what the main backup leaves out

Several vendors are explicit that their built-in backup does not cover everything.

GitLab lists items its backup does not include, among them Redis, object storage, and "GitLab configuration files ( /etc/gitlab )". On object storage it says: "The backup command doesn’t back up blobs that aren’t stored on the file system. If you’re using object storage, be sure to enable backups with your object storage provider."

SharePoint Server's farm backup page says "The farm backup process does not back up any certificates that you used to form trust relationships." It also notes that it "backs up the Business Data Connectivity service external content type definitions but does not back up the data source itself." Microsoft recommends backing up "both the configuration and content", and warns: "You cannot back up the complete farm by using the SQL Server tools because you cannot use the tools to back up the farm's configuration."

Elastic notes that snapshots do not contain items such as "Node configuration files" and "Security configuration files".

Each separately protected item is backed up on its own schedule, so it has its own recovery point (our reading). The plan should state how those points will be lined up, or why it does not matter for that item (our recommendation).

Volumes taken together

When the components are disks on one cloud instance, a coordinated snapshot can help. AWS describes multi-volume snapshots: "By default, when you create multi-volume snapshots from an Amazon EC2 instance, Amazon EBS creates snapshots of all the Amazon EBS volumes that are attached to the instance." It also states: "If any one snapshot in the multi-volume snapshot set fails, all of the other snapshots enter the error state".

A multi-volume snapshot set does not by itself establish application consistency. AWS's snapshot guidance notes that a snapshot "does not include data that has been cached by applications or the operating system" and recommends: "To make sure that the snapshots are consistent and complete, we recommend that you pause writes to the volume before you create the snapshot." The same page points to application-consistent snapshots for Windows instances through AWS Systems Manager.

This EC2 multi-volume operation covers volumes attached to the selected instance. A database on one server and a file store on another still need application-level coordination. AWS distinguishes capture from transfer: the snapshot represents data written when requested, while transfer to S3 continues in the pending state. Its cited procedure permits remounting and resuming writes once that state is reached; verify the complete set eventually succeeds before counting it as a protected recovery point.

Restoring in the right order

After a restore, the components must be brought back so they agree. Nextcloud's restore page shows what can go wrong and how it handles it. It says "By default the Nextcloud server is considered the authoritative source for the data." If the restored server is older than users' devices, it recommends running maintenance:data-fingerprint, which "changes the logic of the synchronisation algorithm to try and recover as much data as possible." It says this "can also help in rare scenarios when the database is newer than the data directory."

This is a version-specific outdated-backup recovery procedure, not a repair for arbitrary mismatched backups. The same Nextcloud page warns of client conflict dialogues and difficulties deleting files, and recommends the fingerprint change only to prevent data loss when the backup was outdated. For its described database-newer-than-data case, a subsequent files:scan is required to update the database. With multiple application servers, the updated configuration and fingerprint must reach every instance. Read the complete procedure for the deployed version and rehearse with isolated test clients; do not reconnect production clients merely because a command completed.

The wider order is usually (our recommendation):

1. Restore the source of truth (the database) and the content store to matching points.
2. Restore configuration and secrets.
3. Rebuild or restore derived parts: index, cache.
4. Run the application's own consistency or scan tools.
5. Only then let users and connected devices back in.

Read-only checks

Review existing backup catalogues and application logs without changing the application. Use an authorised, protected copy of those records.

Build a capture timeline for every component. Record the backup or snapshot job ID, product-reported capture point or start/end interval, time zone, final success status and the protected output location. File modification timestamps and directory listings are discovery aids only: preserved timestamps, copy duration and different capture semantics make them unreliable recovery-point evidence.

Match capture boundaries to the pause. Record when each writer acknowledged pause or drain, when each consistent capture was established, and when writes resumed. A job merely starting inside the maintenance window is insufficient. Keep the required writers quiet through the boundary the product documents, then distinguish asynchronous transfer completion from capture. Check final success for every component and do not accept a partial set.

Record coverage. List authoritative, derived and external components, their protected copies or tested rebuild methods, and the order needed to recover them. Anything with no named protection or rebuild method is a gap.

These records establish the intended consistency boundaries. An isolated application restore still needs to prove that the components agree.

Safe restore rehearsal

Use an isolated test environment with no connection to production users, devices or sync clients (our recommendation). Restored applications may try to send mail, sync to devices or call other systems, so block outbound links first (our understanding).

1. Restore the database and file store from the same backup set into the test environment.
2. Restore configuration and secrets.
3. Rebuild the derived search index, or restore a supported snapshot whose capture interval was coordinated with the other components. Do not infer a common point from filenames or matching start times.
4. Run the application's scan or check tool, where the vendor provides one.
5. Compare with an expected recovery-point baseline or synthetic fixture. Sample twenty documents known to be present at that point and five known search items, then use the application's supported consistency checks. A sample is useful evidence, not proof that every record is correct.
6. Record elapsed time for each step, especially the index rebuild.

Diagnosing what you find

• Records exist but files will not open: the file store backup is older than the database; files live in object storage that was not backed up; or paths changed in the restored configuration.
• Files exist that the application does not show: the database is older than the file store; a scan step was skipped; or permissions on restored files differ.
• Search returns missing or stale results: the index was restored from a different time; it was not rebuilt; or the rebuild has not finished.
• Jobs run twice or never run: the job queue was captured mid-work; it was restored when it should have been cleared; or scheduled jobs fired on start in the test environment.

Worked example (illustrative)

The following is invented. A consulting firm runs a document portal: a database server, a file server and a search server. All three are backed up nightly, at 1 am, 2 am and 3 am.

In a rehearsal, about thirty documents uploaded between 1 am and 2 am by overseas staff appear on disk but not in the portal, and search finds documents the restored portal does not list. The team schedules a maintenance window, confirms that user and background writers have paused, and keeps them paused until the database and file store have both established their documented consistent captures. It records the capture boundaries, resume time and final successful job results, and switches the derived index to a rebuild after restore. The next isolated rehearsal matches the recorded recovery-point baseline; the index rebuild and validation time are included in the recovery estimate. A fixed one-hour window is not assumed sufficient without those measurements.

Risks and limits

• Each vendor's commands apply only to its own product and version.
• A maintenance window is downtime; agree it with users.
• Rebuilding derived data can take longer than restoring it.
• No command was run in a lab. Test first in an isolated environment.

Sources

All accessed 14 November 2026.

• Nextcloud, Backup (Administration Manual 36): https://docs.nextcloud.com/server/latest/admin_manual/maintenance/backup.html
• Nextcloud, Restoring backup: https://docs.nextcloud.com/server/latest/admin_manual/maintenance/restore.html
• GitLab Docs, Back up GitLab: https://docs.gitlab.com/administration/backup_restore/backup_gitlab/
• Elastic Docs, Snapshot and restore: https://www.elastic.co/docs/deploy-manage/tools/snapshot-and-restore
• Microsoft Learn, Back up farms in SharePoint Server: https://learn.microsoft.com/en-us/sharepoint/administration/back-up-a-farm
• AWS, Create multi-volume EBS snapshots from an EC2 instance: https://docs.aws.amazon.com/ebs/latest/userguide/ebs-create-snapshots.html
• AWS, Amazon EBS snapshots: https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html
• AWS, Create Amazon EBS snapshots: https://docs.aws.amazon.com/ebs/latest/userguide/ebs-creating-snapshot.html

Related future topics

• Recovery inventories: listing every component and its backup source
• Maintenance windows and measuring backup downtime
• Rebuilding search indexes after a restore

This article was originally published on 14 November 2026.