Last reviewed: 29 August 2026.
A backup and rollback strategy for high-traffic weeks should define recoverable copies, a known-good state, decision authority and a rehearsed restore. For WooCommerce 10.8 and later, WooCommerce server recommendations advises backing up the site and files before server changes. WordPress also recommends keeping 3–5 recent backups in different locations.
Backups protect data; rollback protects an operating service from a bad change. Treat them as connected procedures, not as two names for the same button.
What should a backup and rollback strategy recover?
Map the state that would prevent the store from operating if it were lost or corrupted. For WordPress and WooCommerce, that normally includes the database plus the files, uploads, plugins, themes and configuration required to recreate the site. Include infrastructure configuration that lives outside WordPress, such as web-server settings, environment variables, firewall rules or deployment definitions, if those would delay restoration.
Do not assume that every provider snapshot captures every volume or external service. Document the boundary of each backup mechanism and where the copy resides. If the same incident can damage production and its recovery copy in the same failure domain, you do not have independent recovery. The goal is to know which copy survives each failure scenario before campaign pressure makes the distinction expensive.
How should you separate backup from rollback?
A backup answers “what data can we recover?” Rollback answers “how do we return the service to a known-good state after a bad release, configuration change or data event?” A deployment rollback might restore code without restoring the database. A database recovery might restore data while leaving an incompatible application version in place. Write the sequence for each likely failure rather than assuming one restore operation solves all cases.
Keep a known-good deployment artefact and the configuration needed to run it. Record schema-migration implications before a release: if a newer application changes the database in a way the older build cannot understand, a code-only rollback may fail. High-traffic readiness is stronger when application, database and infrastructure rollback are tested together in the order your stack actually requires.
Where should backup copies live?
The WordPress backup handbook recommends keeping at least 3–5 recent WordPress backups with copies in different locations. The practical point is failure-domain separation. A copy on the same server can be convenient for a quick restore, but it should be complemented by another recovery copy outside the server, account, storage pool or credential failure domain.
Choose locations so a single operator error or infrastructure failure cannot remove every recovery point. Restrict write and delete access, and make sure the people responsible for recovery can reach the copies during an incident. Encryption, retention and access logging should match the sensitivity of the store data being protected. Document who can restore, not just who can create a backup.
| Recovery asset | Failure it helps with | Verification |
|---|---|---|
| Database backup | Corruption or unwanted data change | Restore into an isolated environment |
| Files and uploads | Deleted or broken application assets | Compare required paths and permissions |
| Known-good release | Bad code deployment | Redeploy and run smoke tests |
| Configuration record | Misconfiguration or host rebuild | Recreate service from the documented state |
How do you rehearse a restore?
- Select a recovery point and copy it into an isolated test environment.
- Restore the database, files and configuration required by the chosen scenario.
- Start the service and verify critical paths such as login, catalogue, cart and checkout behaviour.
- Check logs for errors that a superficial homepage test would miss.
- Record the manual steps, credentials and decisions that delayed the recovery.
- Update the runbook and repeat after material platform changes.
The objective is not a theatrical disaster drill. It is to expose hidden dependencies while the team has time to fix them. A restore that depends on an undocumented secret, one administrator's laptop or an unavailable DNS account is not yet operationally ready. Treat each rehearsal as a way to remove one source of uncertainty from the campaign period.
What should trigger rollback?
Define a small set of observable conditions tied to the change: sustained checkout errors, a clear latency regression, data-integrity symptoms, failed health checks or an unrecoverable dependency mismatch. Avoid the instruction “rollback if needed” because it moves the decision into a stressful incident. Name who can make the call and what evidence they need.
Link rollback to monitoring. The team should be able to compare the release timestamp with error and latency changes and quickly distinguish a deployment problem from a broader traffic or provider issue. The Diwali load-testing guide helps establish the pre-event baseline, while the festive capacity plan ties recovery to infrastructure readiness.
What should be on the recovery checklist?
- Database, files and infrastructure configuration have named backup methods.
- At least one recovery copy is outside the primary failure domain.
- Credentials and access paths are available to the on-call recovery owner.
- A known-good application release is retained and deployable.
- Restore and smoke-test steps are written in the order they must run.
- Rollback triggers and decision authority are explicit.
- Monitoring remains available while production is being restored.
According to WooCommerce's server guidance, you should back up the site and files before changing server settings. Apply that discipline to planned festive changes as well as emergencies. Recovery work is easiest when the last known-good state was captured before the team touched the system.
How should recovery ownership work during a traffic event?
Assign recovery roles before the campaign window begins. One person should have authority to call a rollback, another should execute the recovery procedure, and someone should keep customer-facing or internal stakeholders updated. On a small team, one person may hold more than one role, but the responsibilities should still be explicit. The point is to avoid a production incident in which several people can change the system while nobody owns the decision about which recovery path is active.
Protect the recovery path from the same pressure affecting production. Confirm that the required credentials, backup locations, deployment artefacts and documentation are reachable without depending on the failed service. Keep an incident log of changes made during recovery so later troubleshooting does not confuse emergency actions with the original fault. After service is stable, capture what delayed the restore and update the runbook while the details are fresh. Recovery maturity comes from reducing ambiguity each time the procedure is exercised.
Frequently asked questions
Is a provider snapshot the same as a full recovery plan?
No. Provider snapshots can be one recovery mechanism, but you still need to know what it covers, where it is stored, who can access it and how the application is restored around it.
How many WordPress backups should I keep?
The WordPress handbook recommends at least 3–5 recent backups in different locations. Your own retention can be longer when business, security or regulatory requirements justify it.
What is the difference between backup and rollback?
A backup is a recoverable copy of data or files. A rollback is the operational act of returning from a bad change to a known-good application and data state. A rollback may use a backup, snapshot, deployment artefact or database recovery method.
What is the minimum acceptable outcome?
You should be able to name the copy you would restore, the person who can access it, the sequence that returns service, and the condition that tells you restoration succeeded. If any of those answers depends on memory or an untested assumption, schedule the rehearsal before the high-traffic week begins.