“The host takes backups” is a useful starting point. But if your website disappeared tomorrow, would you know where the latest copy was and how to get it working again?
That's what I'd want a backup plan to answer. You don't need an elaborate system for every website. You do need copies that contain the right information and a recovery process someone has checked.
Make sure you're copying the whole website
A copy of the visible pages may leave out something important.
A WordPress site normally needs its files and database. Uploaded photos, settings and any configuration kept outside the main folder may matter too. A custom application can also depend on background jobs, separate file storage and external services.
For a static website, keep the source, build instructions, required configuration and a working export. Check separately whether forms or other features rely on a database elsewhere.
Ask the person managing your site to list what's needed to restore it. Keep domain and service settings documented securely as part of that recovery information.
Decide how much you could afford to lose
Imagine the last usable backup is a day old. What would be missing?
For a rarely edited brochure website, it might be one small text change. For a shop, it could be a day's orders. That difference should guide the backup schedule.
Back up changing data often enough for the business, and take a recovery point before significant updates. Automated backups help, but their frequency needs to match what happens on the site.
Keep older versions too
You might not notice a problem straight away. If each new backup replaces the previous one, an unwanted change can end up in your only copy.
Keep several recovery points, including some older ones. Daily copies with weekly or monthly checkpoints can be useful, but agree the retention period around your site, storage and data requirements.
Synchronising a folder isn't the same as keeping versioned backups. A deletion or damaged file may synchronise too.
Store a copy separately
If the website and every backup are in one hosting account, a problem with that account can affect all of them.
Keep an independent copy outside it, with appropriate access controls. Protect the backup account with a unique password and multi-factor authentication where available. Use encryption where appropriate, and keep recovery details accessible to the business.
Backups can contain customer information. Give them the same care as the live database, and don't retain personal data indefinitely just because storage is cheap.
Check that the automatic jobs are working
Look at the last successful run, not only the original setup screen.
Watch for failed jobs, full storage and files that are unexpectedly small. Send failure notices to someone who will read them and knows what to do next.
It's also worth checking whether a backup can be downloaded when the hosting dashboard itself is unavailable.
Try a restoration before you need one
A controlled restore is the clearest way to find a missing database, unavailable password or incomplete instruction.
Do the test in a separate environment so you don't overwrite the live site. Make sure it can't send real customer emails or take live payments during the test.
Check the pages, images and important features, then record how long it took and anything that was missing. New Zealand's National Cyber Security Centre also recommends testing backups as part of a recovery plan.
Make the plan usable by someone else
Record where the copies live, who can access them and who to contact. You shouldn't have to rely entirely on one person's memory when the website is down.
If you're unsure what your current backups cover, ask me to look at the setup. I'll help you identify what's there and what still needs checking. You can also read about ongoing website care.