DevdwellIn short
A complete website backup is more than a copy of the files. Save the files, export the database if the site has one, write down the domain and DNS settings, and list the accounts the site depends on. Back up as often as the site changes, keep at least one copy away from your host, and restore a backup now and then to prove it works.
Why your host’s backups aren’t enough
Many hosts include backups, and they’re worth having. But they’re often kept for a limited time, stored with the same company as the site, and restorable only through that company. If the account is suspended, the host has a serious problem, or you need a version from further back than they keep, you may find there’s nothing to restore. Treat your host’s backups as one copy, not the only one.
What to back up
1. The site’s files
Every site has files: pages, stylesheets, scripts, images, fonts and downloads. On a site made of files, that’s the whole site. On a content management system, it includes the platform itself, its themes, its plugins and any uploaded media.
How to get them:
- For a site made of files, copy the project folder, or download it from your host as a zip.
- For a CMS, use a backup plugin or your hosting control panel’s backup tool, or download the files with a file transfer program.
- For a hosted builder, check whether it offers an export or version history. Some builders don’t let you export everything, which is worth knowing before you need it.
2. The database
Dynamic sites keep their content, settings, users and orders in a database, separate from the files. Copying the files alone doesn’t save any of that. Export the database through your hosting control panel or a backup tool, and keep it alongside the matching copy of the files. A file backup from Monday and a database backup from Friday may not work together. If you’re not sure whether your site has a database, see static vs dynamic websites.
3. Domain and DNS settings
If your domain settings are lost or changed by mistake, your site and often your email stop working, even though the site’s files are fine. Write down or export:
- where the domain is registered and when it renews,
- where DNS is managed,
- every DNS record: where the site points, mail settings, and any verification records for other services.
Many DNS providers let you export the records as a file. A screenshot is better than nothing.
4. Accounts and access
Keep a list (in a password manager, not a spreadsheet of passwords) of every account the site depends on: domain registrar, DNS, hosting, the CMS or builder, email, form or booking services, payment services, and anything else connected. Note who owns each account and who else has access. When something breaks, knowing where to log in is half the fix.
5. Anything else that would hurt to lose
Original design files, brand assets, photos in full resolution, and the written content if it lives somewhere outside the site.
How often to back up
Match the backup schedule to how often the site changes and how much you could stand to lose:
- Sites that change rarely, such as a brochure site updated a few times a year: back up after every change, and at least monthly.
- Sites updated weekly, such as a small blog: weekly backups, plus one before every significant change.
- Sites that change every day, such as a shop taking orders or a site with comments: daily database backups at least, files weekly or more.
- Always, before updating a platform or plugin, before a redesign, and before moving to a new host.
Ask the question the other way round: if the site broke right now, how many days of changes could you afford to redo? That’s the longest gap you should allow between backups.
Where to keep backups
A widely used rule of thumb is 3-2-1: three copies of your data, on two different kinds of storage, with one copy kept off-site. For a small website, that can be as simple as:
- the live site on your host,
- a copy on your computer or an external drive,
- a copy in a cloud storage account that isn’t with your host.
Keep a few older backups too, not just the latest. If a problem went unnoticed for two weeks, last night’s backup has the problem in it.
Common backup mistakes
- Backing up to the same place as the site. A backup stored only in your hosting account disappears with the account.
- Files without the database, or a database without the files it belongs to.
- Only one copy, overwritten every night. You need older versions too.
- Backups nobody checks. A scheduled backup can quietly stop running after a password change or a full disk.
- No note of how to restore. Write down the steps while they’re fresh, so someone else could do it in an emergency.
Test your restores
A backup you’ve never restored is a hope, not a plan. A few times a year:
- Take a recent backup.
- Restore it to a test location: a staging copy, a local copy on your computer, or a spare folder on your host.
- Check that pages load, images appear, and for a dynamic site, that the content and settings came back.
- Note how long it took and anything that was missing.
The first test usually turns up something, such as a folder that wasn’t included, a database that wasn’t exported, or a password nobody had. Better to find out now.
A simple backup routine
For freelancers and agencies looking after several sites, a routine beats good intentions:
- Monthly: confirm backups ran for every site; download an off-site copy; check domain renewal dates.
- Before every big change: take a full backup of files and database.
- Quarterly: test a restore for at least one site; review who has access to each account; export DNS records.
- Yearly: check that the account list is complete and up to date.
You can fold this into a broader website maintenance checklist, and do a full backup as step one of any website migration.
How Devdwell helps (and what it doesn’t cover)
Devdwell syncs each site’s files online with their full history, across your computers, so every saved change is kept and any of your computers can open the site. That gives you an off-site, versioned copy of the site’s files as part of your normal work. See sync.
It doesn’t back up databases, domain or DNS settings, or your hosting and registrar accounts. If your site uses a database, or depends on services outside its files, back those up separately using the steps above.
Backup checklist
- Site files copied, including uploads and media.
- Database exported, with the matching files.
- Domain registrar, renewal date and DNS records recorded.
- Account list kept in a password manager.
- Design files and original photos saved.
- Schedule matched to how often the site changes.
- At least one copy away from your host.
- Several older versions kept.
- A restore tested in the last few months.
Questions
What should a website backup include?
The site’s files, its database if it has one, a record of the domain and DNS settings, and a list of the accounts the site depends on. Original design files and full-size photos are worth keeping too.
How often should I back up my website?
At least as often as it changes. A site updated a few times a year can be backed up after each change and monthly; a shop or busy blog needs daily database backups. Always take a backup before updates, redesigns or a move to a new host.
Are my hosting provider’s backups enough?
They are a useful copy, but not enough on their own. They are often kept for a limited time and stored with the same company as the site, so keep at least one copy somewhere else that you control.
How do I know my backup works?
Restore it. Every few months, restore a recent backup to a test location and check that pages, images and content come back. It is the only way to find out what a backup is missing before you need it.