Website backup: the 3-2-1 rule and a restore test

A website backup seems a boring matter until the site disappears. A suspended hosting account, a break-in, a faulty update or a mistake when deleting files is all it takes. Then it turns out whether a backup exists, where it is, and whether anything can be restored from it.

In this guide I show the 3-2-1 rule, a simple scheme that protects a business website and a store. You will also get a list of what to back up and a restore test to do once a quarter. It will take you about an hour and will check whether the backup really works.

Why a backup at the same hosting isn’t enough

Most hosting providers make backups automatically, and that is a good thing. The problem is that the backups sit with the same provider, often on the same account or in the same data center. A single failure can take the site and the backup at once.

Typical situations in which such a backup won’t help:

• loss of access to the account (a hijacked password, unpaid hosting, suspension of the service),
• ransomware or a break-in that encrypts or deletes files, and sometimes also the backups accessible from the account,
• a provider error that deletes data or restores it with a delay,
• your own mistake, noticed weeks later, when the backups from that time are long gone.

A hosting backup is therefore a good safeguard, but only one of several. Check how many days of backups your plan keeps in your provider’s offer description (OVHcloud, home.pl, nazwa.pl and others describe it in different ways), because the period can be short. An example: according to the OVHcloud web hosting documentation as of 25 October 2026, files can be restored only from as far back as the Sunday two weeks earlier, and the provider itself recommends making your own backups regularly.

The 3-2-1 rule in plain words

It is an old, proven scheme from IT. You can remember it in one sentence: 3 copies of the data, on 2 different media, including 1 off the server.

The point is that a single event can’t destroy everything. A data center fire, a break-in or a blocked account affects one place, and the copy off the server stays intact.

What must be in the backup

A website is not just files. A good backup has two parts, and both have to be saved together:

1. Files: the theme, plugins, uploaded photos and documents, configuration files.
2. Database: page content, settings, orders, customer accounts, messages from forms.

In a store, the database matters more than the looks. You can recreate the photos and the template, but not the orders of the last few weeks. That’s why in a store the database should be backed up often, at least once a day, preferably every night.

Remember also the things that are usually forgotten:

• the configuration file with the database connection settings,
• keys and passwords for services (payments, email, API), kept separately in a password manager,
• domain and email settings (DNS records), which are worth saving as a screenshot or a list.

What a good scheme looks like in practice: the robimyweb.pl example

On my own site robimyweb.pl I use exactly this arrangement. The data is backed up every night on the server, and the system keeps the 14 most recent copies. The backup is also downloaded off the server, to a computer that I have at my place.

On top of that, the dashboard warns me when the latest backup is more than 36 hours old. This matters, because the worst backup is one that stopped being made a month ago without anyone noticing. The warning turns “I have a backup” into “I know a fresh backup exists”.

Your version can be simpler. Three things are key: an automatic schedule, a copy in another place and a signal when something stops working.

Step by step: set up your own 3-2-1 scheme

You can put the plan below in place in one afternoon, if you have access to the hosting panel.

1. Check what the hosting does. In the panel find the backups section. Note how often they are made and how many are kept.
2. Turn on automatic backups if there are none. For a rarely changed business site once a week is enough, for a store at least once a day, preferably every night.
3. Add a copy off the server. Download the backup file manually once a week, or set up an automatic transfer to a second place (another provider, a network drive, a cloud with a separate account).
4. Secure access. Protect the account with the backups with a strong password and an additional login confirmation. A backup with customer data is the same data as on the site.
5. Write down who is responsible. One person and one note: where the backups are and how to restore them.

If you would rather not deal with it yourself, I set this up as part of technical maintenance: updates, backups and a quick response to requests.

Restore test: once a quarter

A backup that nobody has ever restored is only an assumption. It happens that the file is corrupted, has no database, or an empty directory was saved. You will find out only when it’s too late.

Once a quarter, do a trial. It is best to put it in the calendar: the first week of January, April, July and October.

1. Download the latest backup from the place off the server, not from the hosting panel.
2. Restore it in a separate place: on a test subdomain, on a second hosting account or locally. Never overwrite the working site.
3. Open the site and click through it. Check the home page, the subpages, photos, the menu and the contact form.
4. In a store, additionally: see whether the products, recent orders and customer accounts are there, and whether the cart gets through to payment in test mode.
5. Write down the result: the date, how long restoring took and what didn’t work. Restore time is information that will be useful in a real failure.

If the test fails, that is good news: you learn about the problem now, not on the day of the failure.

The most common backup mistakes

• A backup of the files only, without the database, or the other way round.
• All backups on the same hosting account.
• No notification when backups stop being made.
• Too short a history: an error noticed after two weeks, while the backups go back only three days.
• A backup on a USB stick lying in a desk drawer and never checked.
• No protection of backups with customer data: free access to the database file is a data leak.

With customers’ personal data, remember that the backup contains it too. GDPR Article 32 lists among its security measures, among others, the ability to restore the availability of data quickly after an incident and the regular testing of safeguards. This is not legal advice: set the rules for storing and securing data with a lawyer or a data protection officer. I can keep customer data on a server in the EU as part of the Customer data in the EU service.

What to do when a failure has already happened

Stay calm and start by establishing what happened. Restoring a backup over an infected site without removing the cause often ends in the break-in happening again.

1. Change the passwords to the hosting panel, the database, email and the site’s admin panel.
2. Find the latest clean backup, from before the problem.
3. Restore it in a test location and check that everything works.
4. Update the software (system, plugins, theme) before publishing.
5. Only then switch the site to the restored version.

If you are not sure the site is clean, you can order a security audit with a report of fixes. If you want backups, monitoring and server protection handled in one place, the Project cybersecurity service helps.

Summary

A website backup makes sense when there are three copies, two media and one copy off the server, and you check restoring once a quarter. A backup only at the hosting is not enough, because it may not protect you from losing the account or from an attack that reaches the backups too.

If you want me to set up backups, the restore test and warnings, write to me. I price technical maintenance from PLN 149 net per month, and a domain and hosting with a server in Poland or the EU from PLN 390 net per year. You can also first check the basics of your site with the free tool Check your website. The state described in this guide is valid as of 27 October 2026.