Can your Hong Kong business actually recover from its latest backup?

Decide what the warehouse can tolerate

For an established Hong Kong wholesaler, the useful backup question is whether staff could resume taking and fulfilling orders with trustworthy records. A green overnight backup status does not answer it. Ask your maintenance partner to restore the latest available backup into an isolated test copy, then have an order-processing colleague check it. The decision is whether the current recovery arrangement is acceptable for the next operating period, or needs a funded repair and another demonstration.

The owner sets two limits before the test: tolerable interruption to work, often called the recovery time objective (RTO), and tolerable loss of recent changes, the recovery point objective (RPO). Tie these to dispatch cut-offs, order volumes and whether staff can reconstruct orders from another record. As an illustration only, an owner might allow four hours to resume work and at most one hour of lost changes. Those are proposed business limits, not a recommendation for every wholesaler or a result achieved by a client.

AWS guidance on periodic recovery testing calls for checking data completeness, integrity and accessibility, and comparing recovery with the workload’s time and data-loss objectives. It identifies restoring infrastructure without retrieving data as a poor practice. The acceptance sheet below is an editorial application for a wholesaler; it is not an AWS product entitlement or a claim that a particular backup service meets your limits.

Buy a bounded rehearsal

With a modest maintenance budget, start with the order application, its database and the attachment store needed for dispatch. Ask for a fixed scope covering preparation, the isolated environment, staff verification, evidence and cleanup. A file-only retrieval is cheaper and useful for a missing document, but cannot establish whether the order application works. A full recovery exercise including every office system offers wider coverage and takes more preparation. Record the exclusions of this narrower rehearsal so that a successful order-system test does not become a claim about the whole business.

Have the partner identify the selected backup, its covered point in time, application version and required dependencies. Restrict access to the test copy and prevent outgoing customer email, live payments, courier bookings and production synchronisation. Use approved access to any real backup and retain only necessary evidence. Fictional records help explain the checks, but a demonstration using only a specially prepared dummy backup does not prove that the latest business backup is usable. Stop if isolation cannot be confirmed.

Use a restore acceptance sheet

Prepare expected counts and sample details from the same recovery point as the chosen backup, rather than from a live database that has since changed. Count orders by a defined date range and status, and compare quantities and totals as well as counts: two incorrect datasets can have the same number of rows. Select ordinary and awkward cases, including an amended order, a cancelled order and an order with several attachments. Open the records through the application with a normal staff role, not only through an administrator’s database viewer.

Keep identifiers and timestamps in the internal record; do not place passwords or unnecessary customer details on the sheet.

The recovery clock should include time spent obtaining access, preparing the environment and waiting for help, as well as restoring data and completing business checks. If you pre-stage those tasks, report that exclusion and measure the remaining delay separately. For data loss, verify recent committed transactions and surrounding records; the largest order number alone is not proof of a complete recovery boundary. If the system was idle, an old last-order timestamp also does not by itself prove that changes were lost.

A fast restore can still fail

Consider a fictional fixture with 120 orders and six attachments across three selected orders at the expected recovery point. The restored copy has all 120 orders, but one attachment will not open. That fails the attachment check even if the screen loads normally. Suppose the simulated outage is at 10:00 HKT, the latest verified recoverable transaction is at 08:30, and the fixture includes later committed transactions that are absent. The illustrated loss interval is 90 minutes. Against the illustrative one-hour limit, that also fails. A three-hour recovery would meet the four-hour time limit but would not override either failure. These are invented test values, not observed performance.

Use the failed row to choose the repair. Missing files may require attachment storage to be included and retested. An excessive data-loss interval may require a different backup schedule or recovery method that the partner must demonstrate on the actual system. Excessive elapsed time may instead come from access ownership or unavailable support. Obtain a scoped change estimate before buying a larger package. Where a limitation remains, record the exposure and temporary operating procedure; an owner’s decision to tolerate it does not turn the failed check into a pass.

Make the evidence repeatable

Agree a recurring cadence that fits the consequences of failure and the maintenance budget; a quarterly rehearsal is one possible starting proposal, not a universal requirement. Repeat after material changes to backup configuration, attachment storage or application versions. Keep the sheet, relevant logs, limitations and repair status so the next exercise can compare like with like. Arrange deletion of the isolated copy after review under the agreed handling plan. Passing a sampled exercise supports the tested scope and conditions; it does not guarantee every future recovery.

For the next maintenance discussion, name one business reviewer, write the two tolerable limits and send the partner this acceptance scope. Request a demonstration date and an itemised estimate including test-environment costs and cleanup. If nobody can establish who controls recovery access, use the broader security guide below to resolve that dependency first. The project brief resource can capture this small piece of work, its exclusions and its acceptance criteria without turning it into an ERP replacement project.