Back up both your website files and database. Frequency should match how often the site changes: daily for most business sites, more often for stores that take orders. Keep copies off the server in at least one separate location, retain several versions over weeks, and test a full restore regularly. An untested backup is only a hope.
- Back up files and the database together; one without the other is rarely enough.
- Backup frequency should reflect how much data you could afford to lose.
- Store copies away from the web server, ideally in more than one place.
- Restore a backup to a test location at least a couple of times a year.
What exactly needs to be backed up?
A website is more than the pages you see. It usually consists of files, such as themes, plugins, uploaded images and configuration, plus a database holding posts, products, orders, users and settings. Restoring only one of these often leaves you with a site that looks broken or has missing content.
Do not forget the surroundings: DNS records, email settings, SSL details and any third-party integrations. These are not inside the site backup but are painful to rebuild from memory. Keep a simple document listing them, along with where your accounts are held and who has access.
How often should you back up?
Ask a practical question: if the site vanished right now, how much recent work could you afford to lose? A static company site that changes monthly can live with a weekly backup. A blog that publishes often needs daily copies, and a store that takes orders all day may need hourly database backups.
Match frequency to the rate of change and the cost of loss. Orders, form submissions and customer registrations are the hardest data to recreate, so the database deserves the tightest schedule. Files that rarely change, such as theme code, can be backed up less often than the database.
- Brochure site: weekly full backup, plus a backup before any change
- Active blog or news site: daily full backup
- Online store: frequent database backups, daily file backups
- Always: a fresh backup immediately before updates or redesigns
Where should backup copies be stored?
The most common mistake is keeping backups on the same server as the website. If the server fails, is hacked or is deleted by the host, the backups disappear with it. Store at least one copy somewhere separate, such as a cloud storage account under your own control or a different provider.
A widely used guideline is to keep multiple copies, on different kinds of storage, with at least one held off-site. You do not need elaborate setups for a small site, but you should be able to answer simply where copies are, who can access them and how they are protected. Encrypt sensitive backups and limit access.
How long should you keep old backups?
Retention matters because problems are not always noticed immediately. Malware can sit quietly for weeks, and a deleted page may only be missed later. If you keep only yesterday's backup, you may be restoring an already infected or damaged version.
A sensible pattern is to keep recent daily copies, several weekly copies and a few monthly ones, trimming older versions to control storage. If you handle customer data, think about how long personal information stays inside archived backups, and check current data protection requirements for your situation.
How do you test that a restore works?
A backup is only proven when you have restored it. Set up a test site or staging area, load the latest backup into it and check that pages open, images show, forms submit and logins work. Note how long the whole process takes and write the steps down for whoever will do it under pressure.
Repeat this a couple of times a year, and after any change in hosting or backup tool. Many owners find during a crisis that backups were failing silently for months, were incomplete or required a password nobody remembered. A calm rehearsal reveals these gaps when the stakes are low.
- Restore into a separate test environment, never over the live site first
- Check pages, images, forms, logins and checkout
- Record how long recovery takes and the exact steps
- Confirm backup alerts reach a person who will act on them
Who is responsible when something goes wrong?
Clarify ownership. Some hosting plans include backups but state that restores are best effort. Agencies may take their own copies, or none at all. If a provider manages your site, ask in writing what is backed up, how often and how quickly they restore it.
Keep your own independent copy where possible, particularly of the database and uploads. Combine backups with security basics such as updates and strong logins, because backups help you recover but do not prevent incidents. Together they turn a disaster into an inconvenience.
Frequently asked questions
Is my hosting provider's backup enough?
It is a useful layer, but you should not rely on it alone. Check how often it runs, how long copies are kept, whether you can restore yourself and whether copies live off the server.
Should I back up before updating plugins?
Yes. A fresh backup just before updates gives you a quick way back if an update breaks a page or checkout. Many backup tools can do this automatically.
Can a backup spread malware back onto my site?
It can, if the backup was taken after the infection. That is why keeping several older versions helps, and why you should find and close the entry point before restoring.
Are free backup plugins good enough?
They can work for small sites if configured correctly and sent to remote storage. Test them, and make sure failures produce alerts, because silent failure is the biggest risk.
Need help with this? See our Website Maintenance & Hosting service or talk to Yash Parikh.