Payments are experiencing issues due to temporary restrictions in Russia. If your payment does not go through, please submit a support request.Our support team is available 24/7 — we are always here to help with hosting and server issues.We are now accepting requests for dedicated server rental and colocation services in our data center.Reminder: we recommend enabling backups for additional data protection.A new VPS/VDS lineup with NVMe storage and improved performance is now available.Maintenance work on some servers has been completed. All services are operating normally.
Article5 min readViews0

How to Verify an E-commerce Backup: RPO, RTO, and Test Restoration

Turn archive availability into a verifiable store recovery plan: define acceptable data loss, measure recovery time, and conduct an isolated test.

АльбинаCommunity author★ 114
Comments 0

Backup storage drives next to the server and a sealed order box without labels
In this article

A "backup created" email confirms only that the job started. It does not prove that the database, order files, configuration, keys, and uploads are in the archive; that the copy is intact; or that the team knows the recovery sequence. For an e-commerce store, verification requires a system restored in isolation and a recorded result.

Before the test, define two business boundaries. RPO determines how much data loss by time is acceptable, while RTO defines how long service recovery may take. These goals cannot be chosen based solely on disk size: an hour of lost orders and an hour of downtime carry different costs for different stores.

Break down the store into data with different change frequencies

Component

How it changes

What to check

Order and payment database

Continuous

Point in time, transaction consistency

Catalog and prices

Batch or via exchange

Link to import version and source

Product files

Irregular

Object completeness and access rights

Code and templates

By releases

Exact commit or deployment package

Configuration and secrets

Rare but critical

Secure separate storage and distribution method

Queues and sessions

Fast and temporary

Should it be recovered or recreated?

A single nightly archive may meet the RPO for images but not for paid orders. The database will require more frequent copying or change logging. However, file and database copies must correspond to a consistent point in time; otherwise, the database will retain references to objects that do not yet exist in the archive.

Select a failure scenario, not an abstract "backup"

Testing the deletion of a single file differs from recovery after a virtual machine loss, an update error, or account compromise. The scenario determines the required levels of independence.

  • A user error requires versioning and a convenient way to restore a single object.

  • Database corruption requires a verified copy, logs, and integrity checks.

  • VPS loss requires infrastructure, configuration, network settings, and data outside the VPS itself.

  • A compromise requires a copy inaccessible to the same account for writing and deletion.

  • A region or platform failure requires independent storage and a pre-defined recovery point.

The rule of multiple copies on different media is useful as a guideline, but it does not replace a threat model. If all copies are deleted by a single automation token or encrypted by the same malicious process, geographic distance offers no protection.

Create a recovery passport

A passport is a short document that allows another qualified specialist to begin work. It lists the responsible person, copy locations, access procedures, dependencies, checksums, startup sequence, expected stage durations, and stop criteria.

Secrets and actual passwords are not included in such a document. Instead, it describes where and by which procedure to obtain them. Contact information for the owners of payment integrations, DNS, and external services is recorded separately: a restored site is not ready if payment notifications go to an old address or if operations are recreated.

How to run a test without risking the live store

  1. Select an isolated network and resources that do not receive live traffic.

  2. Record the selected recovery point, start time, and copy composition.

  3. Deploy the infrastructure according to the documented procedure without copying active secrets unless necessary.

  4. Restore the database and files, then apply logs only up to the selected point.

  5. Launch the store with real payments, email campaigns, delivery, CRM, and 1C exchange disabled.

  6. Verify data integrity and run key user scenarios.

  7. Measure the actual duration of each stage and compare it against the RTO.

  8. Remove test data according to company rules and document any issues found.

Isolation is mandatory: a site copy may start sending emails, deducting stock, confirming old orders, or calling live APIs. Disabling only the domain name is insufficient if background processes have outbound access.

What to check in the restored store

Area

Control question

Problem indicator

Orders

Are there records before the selected point and none after?

Sequence break or duplicates

Payments

Do statuses and amounts match the event log?

Payment exists, but the order is unaware of it

Catalog

Do product cards and variants open?

Links to missing files

Permissions

Do roles work without excessive access?

All users became administrators

Background jobs

Did real notifications disappear?

Resend or external call

Configuration

Does the environment match the required version

Code and database schema are incompatible

An archive hash confirms the immutability of a specific file, but not the logical usability of the data. Successfully opening the main page is also insufficient. Select orders, authorization, the shopping cart, search, administrative operations, and verification of critical counters are required.

Calculate RPO and RTO based on actuals

If the last usable point was at 10:00 and the failure occurred at 10:23, the actual potential data gap is 23 minutes. If recovery started at 10:40 and acceptance testing concluded at 12:10, the operational recovery time is one and a half hours. The report must separately note the delay in detection and decision-making, as this also affects actual downtime.

After the test, adjust not only the backup schedule. The search for access, installation of the required version, or manual verification of integrations may have taken more time. Sometimes the most cost-effective way to improve RTO is to automate the environment and keep instructions up to date, rather than purchasing faster storage.

A backup can be considered verified only for a specific scenario and date. Changes to the CMS, database version, integration set, or storage schema require a new test. Regular restoration turns backup from a hope into a measurable capability to return the store to operation.

GENERAL IT

Help with your project

GENERAL IT

Read more on this topic

Discussion 0

Share your experience and ask questions. Comments without links appear after editorial review.

No comments yet. Start the discussion.