Website Backup Guide: What Agencies Hide

Here is a question that stops most business owners cold: if your website disappeared right now, how quickly could you get it back? Do you know where the backups are? Do backups even exist? Have they ever been tested?

Most businesses cannot answer these questions. They assume their hosting provider or web agency handles backups. Sometimes that is true. Often it is not. And even when backups exist, they are frequently untested, incomplete, or stored in a way that makes them useless when you actually need them.

This guide covers everything you need to know about website backups, written for business owners who want to stop hoping their site is backed up and start knowing it is.

The Questions Your Agency Should Have Answered

If a web agency built your site, they should have provided clear answers to these questions. If they did not, ask them now:

Are backups being made? Of the entire site, not just the database or just the files.
How often? Daily? Weekly? Monthly?
Where are they stored? On the same server? A different server? A different provider? Offline?
How long are they retained? Can you restore from last week? Last month? Six months ago?
Have they ever been tested? Has anyone actually restored a backup to verify it works?
Who is responsible? Is it the hosting provider, the agency, or you?
What is the restore process? How long does it take? Who do you call? What is the cost?
What happens if the agency relationship ends? Do you have access to the backups? Can you take them with you?

If your agency cannot answer these questions clearly and immediately, you have a problem. Not a future hypothetical problem. A problem right now, because your site could go down tomorrow and you would have no recovery path.

Hosting Backups vs. Real Backups

Many hosting providers include "automatic backups" in their plans. This sounds reassuring, but there are significant limitations:

What Hosting Backups Typically Offer

Daily snapshots of your files and database
Retention of 7-30 days (varies by provider)
One-click restore through the hosting control panel

Why Hosting Backups Are Not Enough

Same location: Hosting backups are typically stored on the same server or the same data center. If the server fails catastrophically, or if the hosting provider has a major outage, your backups go down with your site.
Ransomware vulnerability: If ransomware encrypts your server, it often encrypts the backups stored on the same system. Attackers specifically target backup directories.
Short retention: 7-14 days of retention means that if a hack goes undetected for three weeks (which is common), there is no clean backup to restore from.
Provider lock-in: If you want to leave the hosting provider, you may not be able to take the backups with you.
No guaranteed SLA: Most hosting providers state in their terms of service that backups are provided on a "best effort" basis and they accept no liability if backups fail.
You do not control them: You cannot verify that backups are running, test restores independently, or manage retention policies.

Hosting backups are a convenience feature, not a disaster recovery solution. Think of them as a nice-to-have supplement, not your backup strategy.

The 3-2-1 Backup Rule for Websites

The 3-2-1 rule is a proven framework for data protection. Applied to websites:

3 copies of your website data (the live site plus two backup copies)
2 different storage types (e.g., server storage plus cloud storage, or server storage plus external disk)
1 copy offsite or offline (stored in a different physical location or disconnected from the network)

Why Each Number Matters

3 copies: Any single copy can fail. Hard drives fail, cloud storage has outages, human error deletes files. Having three copies means two things have to go wrong simultaneously for you to lose data. The probability of two independent failures is dramatically lower than one.

2 storage types: If all your backups are on the same type of storage (e.g., all on the same cloud provider), a single type of failure can take all of them out. Using different storage types (local disk plus cloud, or two different cloud providers) protects against this.

1 offsite/offline: This protects against scenarios that affect everything at a single location: fire, flood, ransomware that spreads through the network, a rogue administrator deleting everything. The offsite or offline copy survives because it is physically or logically separated.

Practical 3-2-1 Implementation for a Website

Copy 1: The live website (your server)
Copy 2: Automated daily backup to a cloud storage service (AWS S3, Google Cloud Storage, Backblaze B2) in a different region
Copy 3: Weekly backup download stored offline (external drive) or with a separate cloud provider

Backup Frequency: How Often Is Often Enough?

The right backup frequency depends on how often your site changes and how much data you can afford to lose.

Recovery Point Objective (RPO)

RPO answers the question: "How much data loss is acceptable?" If your RPO is 24 hours, you need daily backups. If your RPO is 1 hour, you need hourly backups.

Website Type	Recommended Frequency	Why
Static brochure website	Weekly + after every change	Content changes rarely; losing a week of data means little
Blog or news site	Daily	New content published regularly; losing a day means lost articles
E-commerce store	Multiple times daily (or real-time database replication)	Orders, customer data, inventory change constantly; losing even hours of data means lost orders and customer data
Web application with user data	Hourly or real-time	User-generated content, transactions, and data change continuously

When to Make Extra Backups

Always create a backup before:

Updating the CMS (WordPress, Joomla, etc.)
Installing or updating plugins
Making significant content changes
Running database migrations
Changing hosting configuration

What to Back Up

A complete website backup includes more than just the files. Here is the full list:

1. Website Files

All files on the web server: HTML, CSS, JavaScript, images, documents, CMS core files, plugin files, theme files, uploaded media. Everything in the web root directory.

2. Database

For CMS-based sites (WordPress, Joomla, Drupal, Magento), the database contains most of the actual content: pages, posts, products, users, orders, settings, and configuration. Without the database, the files are useless.

Database backups should be SQL dumps (using mysqldump, pg_dump, or equivalent). Binary database copies are less reliable for restores.

3. Server Configuration

Web server configuration (Apache .htaccess, Nginx nginx.conf, virtual host configurations), PHP configuration (php.ini), cron jobs, and any custom server settings. Without these, your site may not work correctly even with the files and database restored.

4. SSL/TLS Certificates

If you use a custom SSL certificate (not a free Let's Encrypt certificate that can be re-issued), back up the certificate files and private keys. Losing these means your site cannot serve HTTPS until you obtain new certificates.

5. Email Configuration

If your site sends transactional emails (order confirmations, password resets), back up the email configuration, templates, and any SMTP credentials.

6. DNS Records

Document your DNS configuration. If you need to set up the site on a new server, you will need to recreate the DNS records. Take a screenshot or export of your DNS zone file.

7. Third-Party Integration Credentials

API keys, OAuth credentials, payment gateway configurations, CDN settings, analytics tracking codes. Store these securely (not in the backup itself, but in a password manager or secure document).

Testing Restores: An Untested Backup Is No Backup

This is the most neglected aspect of backup management. Having backup files is not the same as having a working backup. If you have never restored from your backups, you do not know if they work.

What Can Go Wrong

Corrupt backup files: The backup process may have errors that produce unusable files.
Incomplete backups: The backup may be missing the database, or missing certain directories, or missing configuration files.
Version mismatches: The backup may be from a different PHP version, MySQL version, or CMS version than the restore environment.
Permission issues: File permissions may not be preserved correctly in the backup.
Path references: Hard-coded paths in configuration files may not match the restore location.

How to Test

At minimum, test your restores quarterly. Here is the process:

Set up a test environment (a staging server, a local development environment, or a temporary cloud instance)
Take your most recent backup and attempt a full restore
Verify that the restored site works: pages load, forms submit, user login works, e-commerce functionality works
Check the database: are all records present? Are the most recent changes included?
Document the process: how long did the restore take? Were there any issues? What steps were needed?

If the restore fails, you know now (when it is not an emergency) rather than during an actual disaster. Fix the issue and test again.

Offsite and Offline Backups Against Ransomware

Ransomware is one of the biggest threats to business websites. Ransomware encrypts your files and demands payment for the decryption key. If your backups are accessible from the same network or server, the ransomware will encrypt them too.

Why Regular Backups Fail Against Ransomware

Most backup systems use automated processes running on the same server or accessible via the same credentials. Ransomware that gains admin access to your server can:

Delete backup files stored on the server
Encrypt backup files alongside your website files
Access cloud storage using stored credentials and delete or encrypt cloud backups
Modify the backup process to create backups of already-encrypted (useless) files

How to Protect Backups Against Ransomware

Offline backups: Keep at least one backup copy that is not connected to any network. An external hard drive stored in a safe works. Update it weekly or monthly depending on your RPO.
Immutable storage: Use cloud storage with immutability features (AWS S3 Object Lock, Backblaze B2 with Object Lock). Once written, these backups cannot be modified or deleted, even with admin credentials, for a specified retention period.
Separate credentials: The credentials used to access backup storage should be different from your server credentials. If the attacker compromises your server, they should not automatically get access to your backup storage.
Air-gapped backups: For high-value websites, maintain backups on storage that is physically disconnected from the network except during backup transfer.

For more on ransomware defense strategies, see our article on ransomware prevention for websites.

Version Control as Backup

If your website code is managed with Git (or another version control system), you already have one form of backup for your code. Every commit is a snapshot of your codebase that can be restored.

What Git Covers

All source code files (HTML, CSS, JavaScript, PHP, etc.)
Configuration files tracked in the repository
Full history of changes (who changed what, when, and why)
Ability to revert to any previous state

What Git Does Not Cover

Database content: User data, posts, products, orders are not in Git
Uploaded media: Images, documents, and files uploaded through the CMS are typically not tracked in Git (and should not be, due to repository size)
Server configuration: Unless you specifically commit these files
Credentials and secrets: These should never be in Git (and if they are, that is a security vulnerability)

Git is a complement to your backup strategy, not a replacement. It protects your code but not your data.

Disaster Recovery Plan for Your Website

A backup is only useful if you have a plan for using it. A disaster recovery plan documents exactly what to do when things go wrong.

Recovery Time Objective (RTO)

RTO answers: "How quickly must the site be back online?" For a brochure site, maybe 24-48 hours is acceptable. For an e-commerce site doing CHF 10,000/day in sales, every hour offline costs money. Define your RTO based on business impact.

What Your Plan Should Include

Contact list: Who to call when the site goes down. Your hosting provider's emergency number, your web developer's phone number, your domain registrar's support. Keep this on paper, not just digitally.
Access credentials: Where are the hosting login details? The domain registrar login? The database credentials? Store these in a password manager that is accessible even if the website is down.
Backup locations: Where are the backups? How to access them? What credentials are needed?
Restore procedure: Step-by-step instructions for restoring the site. Written for someone who may not be familiar with the system. Include screenshots if helpful.
Priority pages: If a partial restore is faster, which pages are most critical? Homepage, checkout, contact page, key landing pages.
Communication plan: How to inform customers that the site is down. Temporary landing page, social media post, email notification.
Testing schedule: When was the plan last tested? Schedule quarterly tests.

Scenarios to Plan For

Server failure: The hosting server dies. Everything on it is lost.
Hack/defacement: The site is compromised and needs to be restored to a clean state.
Ransomware: The server is encrypted and inaccessible.
Accidental deletion: Someone deletes critical files or drops a database table.
Hosting provider failure: The entire hosting company goes down or goes out of business.
Domain expiry: The domain name expires and is grabbed by someone else.
Agency relationship ends: The agency that manages your site disappears or you part ways.

Common Mistakes

Mistake 1: Assuming Someone Else Handles It

The number one mistake. "My hosting takes care of backups." "My agency handles that." Unless you have verified this with specific questions and tested the backups yourself, you are assuming. Assumptions fail during emergencies.

Mistake 2: Backing Up Only Files or Only Database

A WordPress site without its database is just a collection of PHP files. A database without the files is just data without a way to display it. Both are needed for a complete restore.

Mistake 3: Keeping Backups Only on the Same Server

If the server fails, you lose both the site and the backups. This is surprisingly common.

Mistake 4: Never Testing Restores

You discover your backups are corrupt during the one time you actually need them. Test quarterly, at minimum.

Mistake 5: No Versioning

If you only keep the most recent backup and your site was hacked two weeks ago, your backup contains the hack. Keep multiple versions going back at least 30 days, ideally 90.

Mistake 6: Not Backing Up Before Updates

A plugin update breaks your site. You do not have a pre-update backup. Now you need to troubleshoot the issue instead of simply restoring.

What to Do Now

Ask your agency or hosting provider the questions listed above. Get clear, written answers.
Verify that backups exist. Ask for proof. A screenshot of the backup files with dates. A test restore to a staging environment.
Implement the 3-2-1 rule. If your current backup situation does not meet 3-2-1, fix it.
Test a restore. Do it now, not during an emergency.
Write a disaster recovery plan. Even a one-page document with contacts, credentials location, and basic restore steps is better than nothing.
Set a quarterly reminder to test restores and review the plan.

If you want help setting up a proper backup strategy for your website, including automated backups, offsite storage, restore testing, and a disaster recovery plan, contact our team. We help businesses across Switzerland protect their online presence against data loss.