AI App Backups: Recover the Files Behind the Records

A customer signs into a recovered AI app. Their project appears, the document titles look familiar and the dashboard reports that restoration has finished. Then they open a source PDF and find that it is missing. The records have returned, but the material behind them has not. This fictional situation exposes an important question for a business owner: what does the backup actually cover?

For an app that works with uploaded documents, recovery should be defined around the job a customer needs to complete. A restored table or a running server is useful evidence about one component. The business still needs to establish whether its service can deliver the agreed task with the correct information and access controls.

Read the boundary around the backup

Supabase provides a concrete example. Its database-backup documentation explains that backups cover metadata about objects stored through its Storage API, but exclude the stored objects themselves. Restoring an older database backup therefore does not bring back objects deleted afterwards. That is a documented boundary around a particular backup service, and it matters when planning recovery for an application using those files.

The owner’s question is straightforward: which separate recovery process protects the files? Ask the person responsible for the application to show where the originals live, what copies exist and how those copies would be restored. Check the actual service and plan being used. A general statement that the platform has backups leaves these details unresolved.

Follow one document through the application

Consider a fictional training business with an AI tool that answers questions about course handbooks. Its database stores document names, customer ownership and file references. The original PDFs live in separate file storage. The application also uses a search index, instructions for answering questions and a configured AI model.

Suppose its only file backup is from 10:00. A new handbook is uploaded at 10:50, and a database backup runs at 11:00. An incident at noon requires recovery from these copies. The later database copy contains a reference to the new handbook, but the earlier file copy cannot supply it. Both backup jobs may have completed their intended work; together, these copies leave a gap in the customer’s project.

For this application, I would ask for a recovery map that connects each document record to its file and revision, identifies what the search index depends on, and records the instructions and configuration needed to use it. Where an index can be rebuilt, demonstrate that process and include its duration. Where it cannot, document how it is protected.

This develops one part of our broader AI product portability checklist: proving that the information and operational relationships needed by the product can be reconstructed. Here the immediate purpose is restoring service after a disruption.

Agree the data and time targets separately

NIST’s contingency-planning guide, published in May 2010 and updated that November, distinguishes two planning concepts. The recovery point objective, or RPO, concerns the point to which data must be recoverable and the loss the business can tolerate. The recovery time objective, or RTO, concerns the allowed unavailability of a system resource before unacceptable impacts occur. Data recency and recovery duration therefore need separate decisions.

In the fictional handbook business, management might propose a maximum one-hour window of lost changes and a two-hour target for restoring the agreed customer task. These are illustrative choices, not recommended targets for every business. The team would need evidence that its complete recovery method could meet them. A file copy two hours older than the incident would need particular scrutiny against that data-loss target.

Define the finish line in plain language. For this example, the test customer must be able to enter their project, open the correct handbook and obtain an answer supported by the intended source. Record any additional work needed before normal operations can resume. Decide how customers would be supported while that work continues.

Validate the recovered task

The distinction between restoration and validation also appears in AWS Backup’s restore-testing documentation. It describes an optional validation workflow triggered after a restore job reaches its completed state. The sample leaves the substantive validation logic for the implementer to supply. The documentation shows a mechanism for reporting a validation result; choosing and performing meaningful checks remains part of the application’s recovery design.

For the handbook app, the following is a proposed drill using an isolated test environment and fictional documents. Keep its connections separate from live customer messages, billing and other external actions. Set the expected outcomes before the restore begins:

• Recover the material. Compare the expected document records with the actual files and revisions. Open the files and check their contents; matching names alone would miss a replacement with different text.
• Check access. Use the intended test account to open its handbook. Use a second test account to check that another customer’s private material remains unavailable.
• Exercise the AI task. Ask a question whose answer is known from the fictional handbook. Inspect the supporting passage and source reference, and verify the configured model is available.
• Record the elapsed work. Include locating the copies, restoring components, rebuilding anything required and completing the agreed checks. Report infrastructure-restoration time separately where useful.

These checks demonstrate a bounded example. Extend the drill to the important document types, permissions and tasks the service promises. Record what failed as carefully as what passed, including any step that depended on undocumented knowledge or an unavailable person.

Name who can accept the recovery

Give the technical operator and the business owner clear responsibilities. The operator explains the recovery method and supplies the results. The owner decides whether the demonstrated service and any remaining gaps are acceptable against the agreed requirements. In a small business, one person may hold both roles, but the two questions still deserve explicit answers.

Keep a dated record of the selected copies, their coverage, the application configuration, the observed results and unresolved issues. Avoid putting live credentials in that record. State whether a limited service is available, what remains inaccessible and who will resolve the gap. Make any message to customers match that demonstrated position.

Use the drill to choose the next improvement

A useful recovery review should end with a concrete decision. In the handbook example, that might be adding a file-backup process, coordinating recoverable document revisions or reducing the time needed to rebuild search. Assign the change to someone and repeat the affected part of the drill after it is implemented.

Ask for the most recent evidence that a customer’s complete task was recovered, along with the age of the data and the work still outstanding. Those details give an owner something specific to improve and a firmer basis for describing what the business can recover.

Sources

Primary sources checked on 26 October 2026. The handbook business, timings, targets and drill are fictional examples and editorial proposals.

• Supabase. Database Backups. Living documentation; see the exclusion of Storage API objects.
• NIST (May 2010, updated 11 November 2010). SP 800-34 Revision 1: Contingency Planning Guide for Federal Information Systems, section 3.2.1.
• Amazon Web Services. Restore testing validation. AWS Backup developer documentation.