MySQL backups: what a restore exercise must verify

A successful job does not prove a usable service

A backup job can finish without errors and create a large file. During an outage, the team may still discover a missing encryption key, incomplete attachments or unavailable storage credentials. An illustrative customer portal needs both orders and their documents; restoring a table alone does not recover its functionality. A restore exercise should therefore end by completing a real application task.

List everything the service needs: the database, files, configuration, secrets, the required application version and external dependencies. Protect the backup from the same mistake or account that could destroy the primary data. A replica transfers changes and can transfer an unintended deletion too. Distinguish that function from retaining a recovery point to which the system can return.

RPO defines acceptable data loss; RTO defines recovery time

The Recovery Point Objective describes how far the recovered state may lag behind the incident. The Recovery Time Objective sets a target for restoring the service. These concepts belong to contingency planning described by NIST. The process owner must choose values based on the consequences of lost orders or an unavailable service.

An illustrative agreement might require data recovery no more than fifteen minutes behind the incident and service restoration within four hours. These are example requirements, not eWorks results or universal recommendations. A nightly backup alone cannot meet the first requirement. The second must include detecting the incident, preparing infrastructure, transferring data, restoring it and checking the service.

Point-in-time recovery needs an unbroken history

The MySQL 8.4 manual describes point-in-time recovery as restoring a full backup and then replaying the required changes from binary logs. Keeping those logs only on the damaged server is insufficient. Their retention and copying must connect to available backups without a gap between the base state and the requested recovery point.

The procedure must identify the corresponding log position or other identifier appropriate to the chosen method. An incident caused by an incorrect write requires a boundary before the unwanted change. Record the timezone and time precision used in the exercise. A production runbook must reflect the exact version, backup tool and transactional behaviour of the tables involved.

Run the exercise in an isolated environment

A restored application must not automatically resend old invoices, notifications or webhooks. Disable outbound integrations and configure test destinations before starting it. Isolate the environment through both permissions and networking. Real backup data remains protected data during a test; the exercise must not create a publicly accessible copy of the portal.

Use a procedure that a substitute colleague can execute. Record versions, required permissions and key locations without putting the secrets themselves in the runbook. Start timing from the agreed point. If an exercise skips server provisioning or downloading a large backup, its result must explicitly identify those omitted steps.

Check relationships and attachment state

Row counts and backup-file integrity are useful checks, but an order also needs correct items, totals and attachments. Create test reference records before and after the backup and verify which should exist at the restored point. For files, check both content and their database relationships. Restoring two stores independently can produce missing or orphaned attachments.

The team should test login, finding an order and downloading its protected document. Then verify that disabled outbound integrations remain disabled. An actual return to service requires a separate decision on events created after the recovery point, duplicates and reconciliation with external systems. Replaying every queued job without checking can repeat business effects.

Turn the exercise findings into specific repairs

The exercise record should identify the backup, achieved recovery point, measured time, functional checks and obstacles. Assign an owner to a missing permission or file and repeat the relevant part after repair. Schedule the next exercise around system changes and process importance. A recurring test without assessing its result provides little evidence.

• The backup and subsequent logs form a recoverable sequence without gaps.
• Keys and storage access remain available when the primary server is unavailable.
• Database records and documents recover to a mutually verified state.
• The exercise measures the agreed RTO scope and identifies omitted steps.

Put the topic into practice.