Plenty of sites have backups. Fewer sites have a backup that someone has actually restored. Those are not the same thing, and you find out at the worst moment: after a hack, a bad update, or a deleted database.
A copy on the same server is fragile
If backups live only in a folder on the same hosting account, a ransomware-style wipe, a compromised admin, or a host disk failure can take the copies with the site. Store copies somewhere else too, such as a separate cloud bucket or a storage account the site itself cannot freely delete.
Restore on staging, then look closer
A restore that “comes up” is a start. Load the homepage, log in, submit a form, and for stores run through cart and checkout. Then check what the backup did not include: media offloaded to another disk, cron jobs, server cron, SSL, or rewrite rules.
External systems can fool you
WordPress often talks to tools outside the backup: an LMS, a CRM, a payment gateway, or an inventory API. A restored staging site may show pages and forms while API keys or endpoint URLs still point at production, or at empty sandbox credentials. The test should separate a staging-only configuration issue from a gap in the backup itself. Otherwise a green restore gives false confidence about production recovery.
Know how old a good copy is
If you discover malware from three weeks ago, yesterday’s backup may already be infected. Keep more than one generation and note when the site last looked clean. A backup plugin that never reports failures can also go quiet; glance at the logs now and then.
Testing restores is part of ordinary care, not a special project. I include this kind of check in WordPress care and maintenance work when I am asked to look after a site.