Files and the database do different jobs
Files hold the theme, plugins and media. The database holds posts, settings and often orders. A copy of only one part may be useless for a full restore. You also need to know where email, third-party integrations and scheduled tasks run. A special case: moving to a new host.
List every component with where it's stored and who is responsible for it. Don't put credentials in a shared document. It's enough to note where an authorized person can get the access they need during a restore.
How often depends on how fast data changes
A static site and a busy online store can tolerate very different gaps between backups. If orders come in every day, restoring yesterday's database can wipe them out. Set the frequency by how much work you'd have to redo, not by the convenience of a single nightly run.
Before major updates , make a separate restore point. But it doesn't replace regular backups. Keep several versions: a problem may only be noticed later, when the newest archive already contains the broken state.
Restore to an isolated environment first
Deploy the backup to a test address that's blocked from indexing. Turn off real payments, emails and automatic notifications so the test doesn't trigger anything outside. Check that pages open, media is there and login works.
Check the date and completeness of the data, plus any dependencies on the main domain. A file that unpacks successfully is not the same as a working site. Write down the steps, how long they took and any problems you hit, so the next restore doesn't begin with a hunt for instructions. Regular restore tests are part of website maintenance.
Don't overwrite new data without a plan
Before rolling back the live site, save its current state. Compare which orders, inquiries or content appeared after the backup you picked. Sometimes restoring one file or setting is enough, not the whole database.
Write down the restore process before you need it: who restores, from which backup, and what happens to new orders. It's worth agreeing on this with your website technical support. And when choosing hosting, don't just ask "do you have backups?" Ask how many versions are kept, where exactly, and who will press the restore button.
