Are Your Self-Hosted App Backups Consistent? Test the Database, Files and Restore Order

A backup can succeed while the application is still out of sync

A business application may store records in a database and uploads in a separate directory or storage service. Backups of those components can each be readable yet represent different moments in time. After a restore, a record might refer to a missing attachment, or a file might exist without the record that links to it.

The goal is to establish whether the application can be rebuilt from a compatible set of backups—not only whether backup files were created. A successful job report shows that a process ran; by itself, it does not prove the complete service can be restored.

• Pick a representative record with an uploaded attachment or other linked file.
• Identify where the record, file, and link between them are stored.
• Treat separate backup schedules as a question to investigate, not proof of either inconsistency or coordination.

Map what the application needs

Check the application’s documentation and deployment settings to identify what must be present for a restore. Do not assume the database is the whole service or that files are stored beside it. If you cannot inspect a component, ask the hosting provider to clarify its scope.

Application instructions can define backups as multiple parts. For example, Hudu’s self-hosted backup guide describes a complete backup as having two separate parts and identifies a PostgreSQL database as one of them. Use your own application’s instructions to establish which components it requires: [Hudu Support: Self-Hosted Backups and Restores](https://support.hudu.com/hc/en-us/articles/11653994397079-Self-Hosted-Backups-and-Restores).

• Database and persistent files, including attachments or other uploaded content.
• Configuration and any credentials, encryption keys, or tokens needed during recovery.
• External storage or services the application depends on.
• Application and database versions or deployment details required by the documented restore procedure.

Check how—and when—each component is captured

Ask whether related components are captured together or on independent schedules. Consider what happens if users are editing records or uploading files, or background tasks are changing data during a backup.

A technical article specifically cautions that copying the data files of a running database is not a reliable way to back it up: [Stackademic, “Self-hosting without panic (10/12): Backups that restore”](https://blog.stackademic.com/self-hosting-without-panic-10-12-backups-that-restore-the-only-kind-that-counts-e11c1d08c7d8). This warning is about copying live data files; it does not mean every database requires the same backup procedure. Follow the procedure documented for your database and application.

• Are database and file backups taken together or on separate schedules?
• If they are separate, how does the process ensure they represent compatible application state?
• How are active edits, uploads, scheduled jobs, and background processing handled during capture?
• Does the application document a backup or maintenance procedure to follow?

Confirm what the hosting provider handles

The word “backup” does not specify what a hosting provider includes. Confirm whether its process covers the database, persistent file storage, and other state the application needs, and whether related components are coordinated.

Airbip runs application instances as Docker workloads on Airbip cloud servers and offers configurable daily, weekly, and monthly backups. Those capabilities do not, by themselves, establish what a particular backup includes, how components are coordinated, or what a restore will recover. Confirm the scope and restore process for your instance rather than inferring them from the schedule.

Write down the provider’s answers and any recovery tasks you are expected to manage, including who requests a restore and who validates it.

• What data and storage locations are included, and what is excluded or handled separately?
• Does the provider coordinate database and file capture, and what consistency can it confirm?
• Who initiates a restore, supplies required application information, and checks the restored service?
• Where can you check the current backup schedule and applicable service terms?

Restore according to the application’s instructions

There is no universal restore order for every self-hosted application. Follow the application’s official restore instructions and the provider’s procedure. Confirm dependencies before starting, restore related components as a compatible set, and check when it is safe to start the application or reconnect users and background jobs.

Use an isolated test environment unless your plan explicitly calls for another approach. Keep restored data separate from production during the test.

• Confirm the target environment and the access needed to restore into it.
• Retrieve required configuration and secrets through the appropriate secure process.
• Restore the database and files using the documented procedure, preserving their intended relationship.
• Record components that must be recreated or reconnected rather than restored from backup.

Test linked records and normal application behavior

A restore test provides practical evidence that backups can be used. Choose a representative backup set and test it in an isolated environment. Check ordinary records and records with attachments, not only whether the database or application starts.

Compare restored data with known examples from the source environment, including recent changes expected in the selected backup. If something is missing, record the issue and investigate whether it relates to scope, capture timing, restore procedure, or an external dependency.

• Open representative records and verify that their attachments or linked files are accessible.
• Check recent records and edits expected to be present in the selected backup.
• Where the application makes it verifiable, check for orphaned files or records that point to missing files.
• Test a normal application workflow, not just a successful login.
• Record what was restored, errors or missing data, and any manual recovery steps.

Document and revisit the recovery plan

Keep a short backup record where recovery staff can find it. Distinguish confirmed details from assumptions and unanswered questions. A backup schedule describes how often backups may be made; it does not by itself establish retention, coverage, or consistency.

Revisit the record when the application, storage, configuration, or hosting arrangement changes, and periodically according to your operational needs. If a key detail remains unconfirmed, mark it as unverified and decide whether to get a documented answer or test it.

• Record confirmed coverage, exclusions, schedule, retention, and the process for accessing backup data.
• Name who contacts the provider, supplies application-level information, and validates a restore.
• Keep dated restore-test results, including failed checks and follow-up actions.
• After changes, recheck dependencies and repeat the relevant restore tests.