Website backups: how often to run them and where to store them
Your site can break after an update, your host can go down, a script can corrupt the database, or an attack can wipe everything. Without a backup, recovery takes days or becomes impossible. Here's how to set up backups that actually protect you, not just create the illusion of safety.
What goes into a complete site backup
Site files are code, images, stylesheets, scripts. They live in a folder on your host, accessible via FTP or SSH. Size depends on the project: a landing page is a few megabytes, an online store with thousands of products can be several gigabytes.
The database holds content, settings, orders, users. It lives separately from the files and you download it as a dump through phpMyAdmin, command line tools, or your hosting panel. Usually smaller than the files but more critical - without the database, the site won't start.
Email accounts on your domain and SSL certificates are rarely backed up, but if you use corporate email or a paid certificate, add them to the list. Losing correspondence or having to reissue a certificate adds complications during recovery.
How often to back up
Frequency depends on how often content changes. If you publish news daily, back up the database daily. A static corporate site that gets updated once a month can be backed up weekly.
An online store taking orders needs daily database backups, otherwise a crash means lost orders and payments. Product files change less often - back them up weekly.
In practice, the right balance is: database daily and automated, site files weekly or after updates. If you're updating the design or installing a new plugin, make a manual backup before the change even if the automatic one ran yesterday.
Where to store backups and how many versions to keep
A backup on the same host where the site lives doesn't protect you. If the host goes down or deletes your account by mistake, the backup disappears with the original. This is a common mistake: the hosting panel offers auto-backups, the owner thinks they're protected, but the copies sit in the same place.
A minimally safe setup: one copy on the host for quick recovery, a second on external cloud storage (Google Drive, Dropbox, or a separate server). If you work with critical data, keep a third copy on an external drive you control.
Keep the last 7-10 database backups and 3-4 file backups. This lets you roll back not just to yesterday but to a week ago if you didn't notice the problem right away. Delete old backups automatically or you'll run out of space.
Automation: scripts and plugins
On WordPress, install UpdraftPlus or Duplicator. Set the schedule, point it at cloud storage, and the plugin does everything. The free versions handle most needs.
If the site runs on a custom engine or the host gives SSH access, write a bash script using mysqldump for the database and tar for files. Run it via cron. The script is 10-15 lines - examples are in your host's documentation.
Don't rely only on automation. Once a month, verify that backups are actually being created: check the cloud, look at the date of the last file and its size. If the database size suddenly dropped in half or the date hasn't updated, the script broke.
Test restoration - without it, backups are useless
A backup you've never tried to restore doesn't work half the time. The file is corrupted, the database dump is missing a table, config paths are wrong. You find out when the site is already down and you need to recover urgently.
Once a quarter, restore a backup to a test subdomain or local server. Check that the site opens, pages load, forms submit. If something doesn't work, fix the backup process while there's still time.
Keep restoration instructions. Three months later you'll forget the order for uploading files and database, which config settings to change. Write down the steps in a text file and keep it with the backups.
Common backup mistakes
Backing up only the database or only the files. The site won't work if you restore just one: the database references image files, the code connects to the database structure. You need both.
Keeping only one backup version. If it got corrupted or you realize you need to roll back two weeks instead of one day, you're stuck. Keep at least three versions with different dates.
Not encrypting backups with sensitive data. If you're uploading a database with passwords and payment information to public cloud storage, that's a security hole. Use encryption on the plugin side or archive with a password before upload.
What it costs to set up backups
If the site runs on a popular CMS and the host supports plugins, you can set it up yourself in half an hour for free. You'll only pay for cloud storage if the free tier isn't enough - a few dollars a month for 100 GB.
For a custom project or non-standard configuration, a developer will write a script for a few hundred dollars. Set it up once and it works for years. At EFIMOV DEV we include this as part of ongoing maintenance if you have it, or as a separate fixed-price task.
Hosts with managed backups charge a few dollars a month for automatic copies. Convenient, but check where they store the files - if it's on the same server, the protection is incomplete.
Frequently asked
My host makes backups automatically - is that enough?+
Depends on where the host stores them. If they're on the same server as the site, that's no protection from a host failure. Check the terms - some hosts really do store backups on a separate system, but most keep them locally.
How can I tell if a backup works without fully restoring it?+
Check the file size and creation date. If the database weight suddenly dropped or hasn't changed in weeks while the site was updated, the backup is incomplete. You still need to do a full test by restoring to a test domain once a quarter.
Can you recover a site if there are no backups at all?+
Sometimes, if the host made service disk snapshots or copies survived in search engine caches and web archives. But it's slow, expensive, and not guaranteed. Easier to spend an hour setting up backups now.
How much space do site backups take?+
A landing page with images is 50-200 MB, a corporate site is 500 MB to 2 GB, an online store starts at 3 GB. The database is usually 5-10 times smaller than the files. If you keep 7 versions, multiply by seven and add some margin.