A backup is a promise until a restore works
The files, database, uploads, secrets and timing details to verify before relying on a WordPress backup.
A backup is a promise until a restore works begins with a practical question: how can a reader inspect restore evidence and recovery time without confusing a provider promise with a field observation?
Method for this question
Define the recovery object before evaluating a backup. For WordPress, that usually includes the database, uploads, themes, plugins, configuration, secrets and the version of the runtime that can run them. Record backup frequency, retention, off-site location, encryption, access control and whether incremental copies depend on an earlier archive. Then state the recovery point objective and recovery time objective in plain language. A job marked successful is only an attempt; confidence comes from reading an archive and restoring it into an isolated environment.
What to record
- database and uploads together
- off-site copy and retention
- restore environment
- measured recovery steps
A restore drill should start with a known backup ID and an empty target. Verify the archive opens, restore database and files together, repair the configuration deliberately and run homepage, login, media, form and scheduled-task checks. Measure time to a usable page, not just time to copy bytes. Compare the restored content date with the intended recovery point and look for missing uploads, broken URLs, incorrect salts or mail accidentally enabled. Record errors and the exact permissions needed; those details are often what make a real incident slower than a test.
Keep the observation, the interpretation and the recommendation in separate sentences.
A realistic failure pattern
An agency backs up a database nightly and files weekly. After a plugin incident, the latest database references media added after the last file archive, so the restored site contains broken images. The inventory should have flagged the mismatched cadence. A better plan aligns database and uploads or documents the acceptable gap, stores a second copy away from the host and tests the complete restore monthly. The result is a measured RPO and RTO with a named operator, not a storage screenshot.
Errors and boundaries
Never restore over production as the first test. A backup may be encrypted with a key stored on the same failed host, exclude large uploads, retain only one corrupted copy or depend on a plugin that no longer runs. A snapshot is not automatically a portable archive, and a provider’s disaster-recovery promise may not cover application-level mistakes. Keep credentials out of the backup where possible and protect the restore environment. The acceptable schedule depends on content change and business loss, so the policy must be explicit.
What this does not prove
A successful backup job does not prove the archive is complete, readable or quick enough to restore.
The Domain Host USA desk uses the documented fact, field observation, provider statement and editorial recommendation labels so readers can see what kind of sentence they are reading.
This note connects to the Infrastructure Field Desk, where the sample method and dated observations remain visible. Continue through Websites & WordPress for related decisions rather than treating one check as a complete review.
