Ask your hosting provider when they last restored a backup for your environment. Not created a backup. Restored one. The answer will tell you more about your actual data recovery capability than any SLA document.
Backup systems fail silently. A backup process that completes without error can still produce a corrupted archive, an incomplete snapshot, or a file set that cannot be restored to a working state. The only mechanism for detecting these failures is restoration testing. Most hosting environments do not perform it.
The Three Ways Backups Fail
Backup corruption is the most common failure mode. Files are written to backup storage with errors that go undetected until restoration is attempted. Compression errors, storage media failures, and interrupted transfers all produce archives that appear complete but cannot be restored.
Incomplete backups are the second failure mode. A backup process that runs while the database is under heavy write load may capture an inconsistent state. A file system backup that does not include database dumps, or that includes them but captures them mid-transaction, produces a backup that cannot be restored to a consistent application state.
Restoration environment mismatch is the third failure mode. A backup created on a server running PHP 7.4 and MySQL 5.7 may not restore correctly to a server running PHP 8.1 and MySQL 8.0. The backup is technically complete. The restoration fails because the environment has changed.
What a Proper Backup Test Looks Like
A proper backup test restores the backup to a separate environment, verifies that the application starts and functions correctly, confirms that the data is consistent and complete, and measures the time required to complete the restoration. This is the Recovery Time Objective test. It answers the question: if we needed to restore from this backup right now, how long would it take and would it work?
The answer to this question should be documented, reviewed regularly, and compared against the business requirement for recovery time. If the measured recovery time exceeds the business requirement, the backup architecture needs to change. Better to discover this during a planned test than during an actual disaster.
The Frequency Question
How often should you test backups? The answer depends on how often your data changes and how much data loss is acceptable. For a high-transaction environment, weekly restoration tests are appropriate. For a lower-activity environment, monthly tests may be sufficient. The key is that testing happens on a schedule, the results are documented, and failures trigger immediate remediation.