The dashboard says the backup finished, the file appears in storage and the routine continues. That is a good start. To know whether the store could resume operating, however, one practical question remains: has anyone restored that copy and checked the result?
Recovery involves more than opening the home page. Products, images, orders, settings and integrations need to form a consistent whole. A planned test shows what is protected, what depends on another provider and how much work remains before operations can resume.
Understand what the copy actually contains
In PrestaShop, a backup needs to cover files and the database. Images, themes and modules are files; keeping only the database leaves store components out. The official documentation describes these two parts. PrestaShop backup guide.
Create an inventory of your operation. Include the database, uploaded files, customizations, settings and resources stored outside the main server. Confirm that the strategy produces a consistent state across the database and files, even when the store receives changes during the backup. Also identify what is managed by the hosting company or external services.
Keep a record of the versions and dependencies needed to rebuild the environment. Document where domain settings, certificates, scheduled tasks and integration configurations are kept. Everything does not have to be in the same file, but every necessary component should have an owner and a known recovery path.
Define how much you can lose and how long you can wait
Two acronyms help turn a general intention into objectives:
- RPO is the maximum data-loss window the operation accepts.
- RTO is the maximum acceptable interruption before service recovery.
These objectives should reflect the business impact, not just the frequency offered by the tool. Definitions in the AWS Well-Architected Framework.
As a hypothetical example, imagine a failure at 3 p.m. with the latest recoverable point at noon. There is a three-hour window of changes to assess. This does not automatically mean three hours of permanent data loss: other records may help with reconciliation, but that work needs to be planned.
Recovery time includes locating the copy, obtaining access, preparing the environment, restoring, validating and deciding to reopen. Time the entire exercise. Measuring only the database import hides steps that also take time.
Protect the copy and access to it
A backup can bring personal data and commercial information together in one place. Restrict permissions to the people and processes that actually need it. Avoid files in public directories, open links and credentials shared in messages.
Plan copies protected against the loss or compromise of the main environment. CISA recommends encrypted, offline backups and regular availability and integrity tests. Implementation should reflect the operation's setup. CISA StopRansomware Guide.
Also check who can recover encryption keys and access credentials when needed. Document the procedure without putting secrets in the instructions themselves. A protected copy that the authorized team cannot access during an incident will not enable recovery.
Restore in an isolated environment
The first test should not replace the public store. Prepare a separate environment with its own database and storage, restricted access and clear identification that it is a drill.
Before starting the restored application, block external effects. Disable scheduled tasks and queue consumers; prevent messages and calls to production services. Replace credentials with test equivalents when the scenario requires an integration.
Pay particular attention to payments, webhooks, ERP, tax document issuance and carriers. A restored database can contain pending orders and old queues. Running them without isolation can repeat actions that already happened.
Use fictional or anonymized data for checks. If real data is essential, limit access and retention to what is necessary. The test should demonstrate recovery without creating a second exposure of the customer database.
Validate the recovered operation
Start with technical integrity: did restoration finish without errors? Are the expected components present? Is the application using the correct database? Are the versions and permissions appropriate?
Then check representative samples of products, images, customers and orders up to the selected recovery point. Compare values, statuses and relationships between records. Counts help, but alone they do not prove that the contents are correct.
Go through search, cart, login and administration. For checkout and payments, use only a sandbox and test payment methods, without placing a real order. Assess integrations in dedicated staging environments or with simulated responses, keeping production blocks in place.
Also record what was excluded from the exercise. An untested dependency should appear as an outstanding item, with an owner and a next step, rather than disappearing under a “backup validated” label.
Turn the test into a usable procedure
Save the copy's date and scope, test results, observed timings and necessary adjustments. Keep the instructions available outside the infrastructure they are intended to recover.
Repeat the exercise according to operational risk and after significant changes, such as migrations or new integrations. Check failure alerts, retention and storage capacity: a quiet routine can stop producing useful copies.
During a real recovery, preserve evidence and plan the reconciliation of changes made after the restored point. Any replacement of production requires an explicit decision and its own procedure, not an improvised sequence of deletions.
If you cannot yet describe that path, talk to AGTI about reviewing your store's backup and recovery process. The goal is to move from trusting a file to a recovery that the team knows how to perform and verify.