Magento backup and restore testing before an upgrade

Before approving a Magento upgrade, ask for a completed restore test that connects the backup to a working storefront, usable order data and the correct application release. A successful backup job proves that a job ran; it does not establish that your team can recover the business within its maintenance window.

This guide is written and reviewed by Magento Patches for merchants running Magento 2 or Adobe Commerce on cloud infrastructure. It focuses on recovery readiness. Use the patch checklist for patch selection and installation, and the wider security checklist for access, checkout scripts and incident preparation.

The steps below are a suggested acceptance process, not a recovery-time promise. A merchant can agree priorities and review evidence; the developer and hosting provider should perform restores with authorised access. Practise on an isolated target before considering any production restore.

Agree two business limits. The recovery point objective is how much recent data you can afford to lose. The recovery time objective is how long you can tolerate the service being unavailable. Write them in terms of orders, fulfilment and customer service, then ask the technical team whether the available backups and recovery process can meet them.

Include access approval, backup retrieval, infrastructure preparation, import, application checks and sign-off when measuring a rehearsal. Timing only the database import hides the delays that decide whether recovery fits the window. Record an observed result separately from a target; one test does not guarantee the next restore will take the same time.

Ask the owner to list what each backup contains and what must be retrieved elsewhere. A database export cannot replace missing product images, private extension packages or deployment configuration. Record the backup timestamp with its timezone and match it to a known code revision and dependency lock file.

Adobe distinguishes shared deployment configuration in app/etc/config.php from environment-specific settings in app/etc/env.php. Recovery must account for both, while handling secrets securely. Do not publish environment files, database exports or recovery credentials in a ticket or public repository.

On a self-hosted store, ask the hosting provider or database administrator which supported backup method matches the database engine, file storage and application workload. Adobe documents the built-in Magento backup feature as deprecated and disabled by default. Do not make enabling that legacy feature your new recovery strategy.

For Adobe Commerce Cloud, check the plan and environment. Adobe's manual snapshots cover persistent service data and mounted files, while application code is retained separately in Git. The manual snapshot workflow applies to Starter and Pro integration environments; Pro Staging and Production have a different disaster-recovery workflow.

Adobe describes regular live backups for Pro Staging and Production. Its guidance directs customers to request a specific backup through Support with the date, time and timezone; it also states that Adobe does not restore the environment from that automatic backup. Confirm the actual retrieval and restoration responsibilities for your project rather than treating hosting coverage as an automatic application rollback.

A backup that exists but cannot be retrieved by the recovery team is not ready for the maintenance window. Check its identifier, storage location, retention, access route and the date of the last successful retrieval. Confirm that older recovery points remain available long enough for your business to discover a problem.

Protect backup access and avoid depending on the same account or machine for every copy. NCSC guidance recommends knowing how to restore important data and protecting online backups with two-step verification. Ask your provider how its controls apply to your store, rather than assuming that every hosting plan includes the same protection.

Adobe warns against placing backup output in public web directories such as pub/media or pub/static. Use an approved private location. Share backup references in the evidence record, not customer data or secret values.

Prepare the test environment before loading the backup. A clone can retain live credentials and integrations, so changing its hostname alone is not enough. Restrict access, protect copied customer data and check that outbound connections cannot reach production destinations without explicit approval.

Keep scheduled jobs and consumers controlled until their destinations are reviewed. Use sandbox payment credentials and an email capture service or disabled outbound mail. Check custom jobs as well as standard Magento configuration: an extension may use its own connection settings.

Select a representative recovery point, retrieve the artefacts and restore them with the method approved for that environment. Match the application release to the database state; do not assume that a code revert reverses schema or data changes. Note every manual intervention, missing package and access delay.

For Cloud database exports, Adobe's ece-tools db-dump procedure captures database data rather than the complete environment. It enters maintenance mode and controls cron and queue consumers, so schedule it appropriately and follow the documented environment-specific instructions. This guide deliberately avoids a universal production restore command: the target and data-loss implications need to be checked first.

Start the timer before the retrieval request and stop it after the agreed acceptance checks. If the rehearsal reveals a gap, assign an owner and repeat the affected check after remediation. Keep the result as Action needed until that evidence exists.

Use this suggested acceptance list to agree what recovery means for your store. Choose representative products, store views and order records before the rehearsal so the team is comparing against something concrete. Perform transaction tests only with approved test accounts and sandbox services.

Restoring an older database can remove newer orders from Magento even though a payment provider or warehouse still holds the corresponding transaction. Before a production rollback, identify what changed after the recovery point and who will reconcile it. A working checkout does not settle the financial or fulfilment state of those orders.

Write down how new orders, payment captures, refunds, stock movements and integration messages will be reviewed. Assign separate owners where necessary. Do not automatically replay queued messages or create replacement orders until the team understands which actions have already reached external systems.

If the recovery follows a suspected compromise, use incident-response guidance to establish a trusted recovery point. The newest backup may contain the same malicious code or data. Preserve evidence and coordinate investigation before destructive cleanup.

Store this record with the release plan and restrict it to the people who need access. Populate it with observed evidence, not assumptions or a copied provider promise. A pass should identify the scope actually tested; an untested integration stays untested.

Repeat the relevant rehearsal after material changes to hosting, storage, deployment, payment modules or recovery ownership. Set a recurring review based on business risk. Before the upgrade window, confirm that the chosen recovery point and package access are still available.

Ask for the recovery set, the last restore-test record, the measured duration and the unresolved issues. If the answer is only a backup schedule, the team has described availability rather than demonstrated recovery. Make the missing evidence part of upgrade planning.

Prepare your edition and version, hosting plan, intended change and existing backup documentation. Share identifiers and responsibilities first; use a secure channel for any access required. A clear recovery plan makes the decision to release, pause or roll back easier to defend.