WordPress backup — the question is not whether you have one

Most site owners sleep soundly because they pay for hosting, and somewhere in the provider's offer there was a line about regular backups. The problem is that at the moment it matters — after an attack, after an employee's mistake, after a hardware failure — the question is not "do you have backups".

The real question is: who last tried to restore one, and how long did it take?

A backup nobody has ever restored gives you a feeling of safety and nothing else. That feeling ends at the moment you find out that the automation has been overwriting damaged files for months, or that restoring the site is a matter of days rather than hours.

What actually gets copied — and why files are not enough

Restoring a website is not a copy-paste of one directory. A working site is a system of connected parts: restoring the files without a current database brings back the appearance at best — with no content, no order history, no customer accounts.

For the site to work again, you need a consistent copy of four layers.

Two things are worth clarifying here, because they get confused. An SSL certificate is usually not part of a website backup — the hosting issues and renews it, so after a restore onto the same server it comes back by itself; what does get lost is the setting that forces the encrypted connection, and that belongs to the configuration layer. And administrator passwords sit in the database, not in a layer of their own — what is held separately are the keys to outside services, and those are the ones that most often fail to come back with the copy.

The practical conclusion: the question to your provider or your contractor is "what exactly does the backup include", not "is there one". The answer "files and the database" is a good answer. The answer "the whole site" is not an answer at all.

There is a fifth thing that fits into no layer, and without which the restore never starts: knowing where the backup is and how to get to it. That sounds trivial until the person who configured it no longer works at the company and the copies sit in an account opened on their work address. We have seen this more often than damaged archives — and it is the only item on the list that costs nothing, just one sentence written down next to the hosting and domain access details.

Where the backup lies — and what that protects against

"The hosting has backups" describes a location, not a safeguard. And the location decides what the copy protects against in the first place.

A copy on the same server is not a backup — it is a second file next to the first. It goes with the disk, with the account, and with the encryption of everything the server can reach.

A copy in the hosting provider's backup system is already something real, because it usually sits on a different volume. It will survive a hardware failure. It will not survive the account being deleted — not in a dispute with the provider, not over an unpaid invoice, and not when somebody takes over the control panel.

A copy outside the account, with a different provider, survives all three scenarios. Not because it is more expensive or technically better — because it does not share the fate of the thing it is meant to rescue. That is the entire content of the much-repeated rule about keeping one copy off-site, and the only part of it worth remembering.

Ransomware deserves its own sentence here, because it is what invalidates the most plans: the malware encrypts not only the data but the mounted network shares the server has access to. A copy attached to the same system as a network drive is encrypted along with everything else.

From this follows a distinction that makes all the difference in practice and sounds technical: the backup should be out of the server's reach for writing. Put differently, the backup reaches for the data; the server does not reach for the backup. If the setup is the other way round, and the site itself pushes archives onto an attached drive, then whatever takes over the site takes over the archives too. On a typical hosting plan this is a one-sentence question to support: are the copies kept outside the account, and can they be overwritten from the server?

One more question belongs here, and in the European Union it is not only a matter of preference: where the copy physically lands. A backup is a complete copy of everything the site holds about people — form submissions, accounts, order history. If the backup service stores it outside the EU and the European Economic Area, that is a transfer of personal data to a third country, and the GDPR allows such transfers only under the conditions of its Chapter V (Article 44 sets out the general principle). The site itself may sit on a server in Warsaw while its archives quietly go to a storage region on another continent, because that was the default when somebody switched the plugin on. Providers state which region their storage sits in; ask before you switch the copying on, and write the answer down next to the rest.

What WordPress gives you, and what it does not

Most of the sites this article is about run on WordPress, so it is worth being exact about what the platform itself does for you here: WordPress has no backup function. What it has is an export, and the two are not the same thing.

Under Tools → Export the dashboard produces an XML file. WordPress's own documentation lists what goes into it: posts, pages, custom post types, comments, custom fields, categories, tags, custom taxonomies and users. There is no theme on that list, no plugins, no settings and no uploaded files. It is a content export, built for moving text between installations — as a WordPress backup it restores the words and nothing that displays them.

A WordPress site on the server is at least two halves. The database holds the content, the settings and the accounts. The `wp-content` directory holds the theme, the plugins and everything anyone has ever uploaded. Next to them sits the configuration file with the database connection details and the site's security keys. A WordPress backup that does not take both halves restores half a site — which, seen from outside, looks exactly like a broken one.

Hence the usual arrangement, a backup plugin, and the one question that decides whether it is worth anything: where does it put the archive? More than one of them defaults to a folder inside wp-content — that is, on the same server, in the same account, inside the very directory the copy is meant to protect. It is a second file next to the first, and a growing one: on a site with a large media library, months of archives fill the hosting quota and take the site down with no attacker involved at all.

The second question about a plugin runs in the other direction: how does restoring work, and has anyone here ever done it? Creating an archive is the easy half, and it is the half that gets automated. Unpacking one into a working site is the half that is tested on the day it is needed — which is what the test further down is for.

WordPress specifics do not end with backups. The order in which updates are applied so that the site survives them is a subject of its own, and who still holds an administrator account in the dashboard belongs to security.

Losing access is an incident, not only an outage

This part is left out of guides about backups, and it changes the category of the problem.

A personal data breach is not only a leak. It is also accidental loss of data and loss of access to it — which is exactly what happens after a failure with no working copy.

That is not our reading; it is the definition. The GDPR describes a personal data breach in Article 4(12) as a breach of security leading to "the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to" personal data. Loss is on that list in its own right, next to disclosure. The European Data Protection Board's guidelines 9/2022 on breach notification develop it with worked examples, and they are the document to read if you want to see how supervisory authorities think about a case like yours.

Three parts of the mechanism are worth knowing before a failure:

The clock starts when you become aware — not when you fix the problem and not when you establish its cause. Article 33 gives the controller 72 hours from becoming aware to notify the supervisory authority — in Poland, the President of the Personal Data Protection Office (Prezes UODO) — unless the breach is unlikely to result in a risk to the people concerned. Notifying late is possible, but the delay has to be explained.

Ransomware is the canonical example in the guidelines, including the case where the backups are encrypted too. If the copy works and the data comes back quickly, the risk assessment looks entirely different from the case where it does not come back at all.

Nobody has to steal anything for a breach to happen. This is the least intuitive part and the one that surprises people most: data encrypted in place, with nothing copied out, is still a loss of access.

It is worth being clear about what this section does not claim. It does not claim that every website outage is an incident to report — if the site processes no personal data and has no forms, its unavailability is a business problem, not a legal one. The threshold is the question of whether what became unavailable held data about people: form submissions, customer accounts, orders, correspondence history. On a typical company website the answer is yes, and that is why the section is here at all.

The practical consequence for backups is simple and not obvious: a working copy does not only shorten the downtime — it changes what has to be reported, and with what risk. The notification duty itself, and how to carry it out, is covered alongside the GDPR information duty on your website.

Responsibility does not transfer along with the service

Two sentences we hear more often than any others: "the hosting takes care of that" and "our IT person takes care of that". Both are usually true, and neither moves the responsibility anywhere.

The division the GDPR makes runs between the controller — the company that decides why and how personal data is processed — and the processor, the supplier that processes it on that company's behalf. Both halves are written into the regulation. Article 28 says the controller may use only processors that provide sufficient guarantees of appropriate technical and organisational measures, which makes choosing and checking the supplier your job, not theirs. Article 33 says the processor has to notify the controller without undue delay once it becomes aware of a breach — the report travels to you, because the duty to notify the authority stays with you. The supplier has obligations of its own and can be held to account for its own failures. What it cannot do is take over yours. You can outsource the work; you cannot outsource the answer.

Three practical consequences for backups follow from that.

The backup is a question you ask in writing. What it includes, how often it runs, how long it is kept, where it lies, who can reach it. The answer belongs in your records, not only in the provider's — because on the day you need it, the provider's records may be part of what is unavailable.

The exit clause is a clause about backups. A contract that ends with the provider "returning or deleting all copies of the data" is talking about archives, because archives are what the copies are. Ask how that is done and by when, given a rotation that keeps monthly copies — otherwise it is a sentence that reads as complete and describes nothing. The same applies in the other direction when you change provider: what you should receive is a copy you can restore, not a link to a panel you will lose access to next week.

Out-of-date software is a failure of care, not bad luck. Most restores that are ever needed are needed because of a version nobody updated. That is why the question after an incident is rarely only "who attacked you" and is usually also "what was not done beforehand" — and why updates and backups belong in one conversation rather than two.

The test that settles everything

Five questions. The answer "we have backups" answers none of them.

The most important are the first two taken together: who has restored one, and how long it took. Until somebody has tried, nobody knows whether the copy is complete, whether it unpacks, or whether it contains the database. And the restore time is your real downtime — not the figure from the provider's offer, but the one you will give a customer who asks when you will be back.

The test is run on a copy of the environment, not on the live site, and ideally at a moment when nothing is on fire. It is one afternoon a year, and it turns "we think we have one" into a number of hours.

The three things that come out of such a test most often: the copy did not contain the database, only the contractor had access to it, or the restore needed a password nobody could remember any more.

What to write down afterwards, so that you are not starting from scratch next year: the date, the restore time, where the copy came from, and what was missing. Four lines in the same document that holds your hosting and domain access details. At the next failure that is the first thing anyone reaches for — including the contractor you call in the middle of the night.

There is a version of this test for companies with nowhere to restore to: ask the hosting provider to restore the copy into a test environment. Most have such a service, and the first run is sometimes free. A refusal, or the absence of any such option, is information too — and fairly serious information.

Who does it, and what it costs

Honestly: on a company website the backup is one of the cheapest lines in the whole maintenance bill, and one of the few where cheap genuinely does mean enough.

Three levels, as we see them in practice:

Backups inside the hosting plan, switched on and checked. Usually part of the package, sometimes a small monthly addition. They are enough for a brochure site on one condition: that somebody once checked what they cover and how long they are kept.

A plugin or a service that pushes the copy outside the account. This is the level at which a copy appears that survives the loss of the account — and for most companies it is the right choice. For a site of this size a free tier is often enough, which is why this step is skipped far more often out of habit than out of budget.

A backup managed by the contractor, with a restore test written into the contract. That makes sense for a shop and for a site that earns money. What you pay for then is not the copying but the fact that somebody is answerable for how long it takes to come back.

What is not worth buying: packages in which "backup" is the only line and costs more than any of the above. There is one control question and it settles the matter in a sentence — does anybody in this service ever restore a copy, or only create one?

We do not quote figures here, and that is deliberate. What a backup costs depends on the size of the site, the plan and the provider, and the only honest number is the one on the offer in front of you; a figure carried over from another market, or converted from one, would be a guess dressed up as a benchmark. How the rest of the bill is put together we break down under website maintenance costs.

How many copies, and how often

The rule "three copies, two media, one off-site" gets repeated like a liturgy, so it is worth describing by what it protects against rather than by its numbers.

Three copies — because the second one may be damaged, and you find that out only while restoring.

Two different places — because one place is one failure.

One outside the infrastructure — because it is the only one that survives the loss of the account and the encryption of everything the server can reach.

Frequency is settled by a single question: how much work are you prepared to lose? A company site where nothing changes for weeks is perfectly fine with a daily copy. A shop taking orders needs something more frequent, because every hour is orders that cannot be reconstructed from anything else.

How long to keep them: long enough to go back past the moment when things went wrong. That is a practical argument, not a legal one — infections and damage are often noticed weeks later, and yesterday's copy is by then a copy of an already broken state.

In practice this usually means a rotation: several daily copies, several weekly ones and one monthly. Not because a standard demands it, but because it covers three different scenarios. The daily copy rescues you from a mistake made hours ago, the weekly one from a failed update noticed on Monday, the monthly one from an infection that sat quietly and surfaced only in a customer complaint or a search engine warning. The default settings of most hosting services cover the first scenario and sometimes the second — the third almost never, and that is the one thing in this section worth adding on purpose.

A shop is a different category

Everything above concerns a company website. With a shop three things change, and they are worth listing separately, because they change the choices as well.

Orders cannot be reconstructed from anything else. The content of a site exists in people's heads and in files; yesterday's order exists only in the database. That moves the frequency from daily towards hourly, and it is the only place in this article where we recommend more than the minimum.

The restore has to cover the state of payments. A shop put back to yesterday's state has orders paid after that hour marked as unpaid — and that is worse than an hour without a shop. With a shop, the restore is planned together with a decision about the time gap, not instead of one.

Customer data raises the legal stakes. A shop's database holds addresses, purchase history and sometimes payment details, so the risk assessment after a loss of access looks different from the one for a site with a contact form.

The four sentences we hear most often

"The hosting does backups, so that is off my plate." It does, and that is good. It does not, however, know what is in your database, it will not restore it for you, and it will not survive the account being deleted. The sentence is true and insufficient at the same time, and the difference between the two shows up only on the day of the failure.

"We have a backup plugin." The plugin creates archives. The question is where it puts them — if in a folder on the same server, it is a second file next to the first, and a growing one, which can fill the hosting account and take the site down without any attack at all.

"We will check it when we have to." That is the worst possible moment: under pressure, without knowing how long it will take, and with nowhere to try it safely. The test done calmly costs an afternoon; the same test done during an outage costs a day and several bad decisions.

"It is a company site, not a shop — there is nothing to lose." There is: form submissions, text written over years, positions earned on specific addresses. Restoring the appearance takes days, restoring the text takes weeks, and part of it cannot be restored at all, because nobody has it anywhere else.

What this article deliberately leaves out

• RTO, RPO and enterprise-class tooling. That is the language of an IT department and a different scale of problem; on a company website it is replaced by the question "how long did the restore take".
• Comparisons of specific tools and providers. They change faster than an article can be kept current.
• Retention periods by industry. That is a legal decision rather than a technical one, and it depends on what data you hold.
• Access control and dashboard accounts — how to secure a website.
• Keeping software up to date — separately, and it is the absence of this that most often makes a restore necessary in the first place.
• Noticing that the site is down at all — that is monitoring, and it is what tells you the copy is needed today rather than next week.

What to do, in this order

If you are starting from zero: five steps and one afternoon.

1. Establish what the current backup covers. One question to the hosting provider or the contractor: files, database, how often, how long they are kept, where they lie.
2. Check whether any copy lies outside the hosting account. If none does, that is the first thing to add and usually the cheapest.
3. Restore it into a test environment and measure the time.
4. Write down four lines: date, time, source, what was missing.
5. Add the access details — who can get into the copy, next to the note on who can get into the hosting and the domain.

Steps one to three are done once. Four and five are what stop you starting over a year from now — and they are the only part nobody ever remembers, because nothing breaks on their account until the day everything breaks at once.

The shortest summary: a backup begins to exist at the moment somebody restores it. Before that it is a line in a hosting offer — and a line in an offer does not shorten downtime and does not change the risk assessment when an incident has to be reported.