It’s Friday afternoon. The owner of an online accessories store launches a plugin update she’s been putting off for three months. The website goes blank for a few seconds, and then an error message appears instead of the store. Customers can’t complete their orders, the phone is ringing, and the IT friend you call for quick fixes is on vacation until Monday.
The latest backup on the hosting server is a month old and, on top of that, has been overwritten by a newer version that already contains the same error. This happened because no one ever explicitly stated who was actually responsible for backing up the website. The owner assumed that the hosting provider handled it. The developer who built the website assumed that backups were included with the hosting service.
The solution, however, isn't complicated or expensive. You just need to know who's actually creating the backup, how often it makes sense to do so, and what it means for it to be usable at all. Let's go through this step by step.
Who is actually responsible for your website's backup?
The answer is: it depends on what you’ve agreed to—and in most companies, nothing has been agreed upon at all. The hosting provider does indeed make backups, but they’re their backups, not yours. If the hosting provider experiences a technical failure, goes out of business, or gets into a dispute with you, you’ll lose access to both your website and the backup at the same time, because both are stored in the same place.
Retention, that is, the period of time during which hosting The length of time that older backups are retained varies by provider; it’s typically one week to fourteen days, and the most recent backup always overwrites the previous one. If you don’t notice the error in time, even the last working version of the website will be overwritten.
The second option is to back up your website yourself, usually using a plugin. This works if someone actually checks it regularly. In practice, however, the plugin is often set up once when the website goes live, and then no one ever verifies whether backups are actually being created or whether the website can actually be restored from them.
The third option is to include backups as an explicit part of your website management contract with an agency or developer, specifying the frequency, storage location, and regular verification that the restoration process works. This is the only option where the responsibility does not rest solely on you, and at the same time, you know exactly what is covered.
| Who makes the down payment? | What does it actually cover? | Risk |
|---|---|---|
| Hosting Only | Automatic short-term backup, typically one to two weeks | The backup will be lost if there is an outage or problem with the hosting service |
| Custom Plugin (DIY) | Full control over the frequency and storage location | It works, as long as someone checks it regularly |
| Part of website management | The frequency, storage, and regular testing of contract-specified recovery procedures | Higher monthly costs, but clearly defined responsibilities |
No matter which option you choose, the first step is the same: clearly document who creates the backup, how often, and where it is stored. Without that, the backup exists only in your imagination—and that’s exactly the situation that hurts the most on a Friday afternoon.
How often is it recommended to back up a website?
The frequency of backups depends on how often the website's content changes, not on how large the website is. An active e-shop that receives daily orders requires a completely different backup schedule than a corporate website that is updated once a quarter.
| Website Type | Recommended Frequency |
|---|---|
| Online Store with Daily Orders | At least once a day, ideally more often, and always before each update |
| A company website or magazine with regular content | Once a week, or after each major content update |
| A static presentation with minimal changes | Once a month, or whenever you make changes |
In addition to a regular schedule, there is one simple rule that is often overlooked: you should always create a backup even outside of your regular schedule, right before any risky changes are made to the website. Before updating the content management system, before installing a new plugin or template, before migration to another hosting provider. This one extra backup could save you hours of trying to figure out exactly what went wrong.
What a Complete Website Backup Should Include
A website built on content management system (CMS) It consists of two parts that work together but are backed up and restored separately. The first is the database—the place where all texts, orders, users, and settings are stored. The second part consists of files—namely, templates, plugins, and uploaded images. A large proportion of failed restores occur precisely because one of these two parts is missing—most often the database—and the website then launches either half-empty or not at all.
A proven standard for organizing backups is the so-called 3-2-1 rule: three copies of the data, on two different types of storage, at least one of which is located outside the server where the website runs. In practice, this means a live website on a hosting server, an automatic backup on that same server, and a third copy stored elsewhere—typically in cloud storage such as Google Drive or Dropbox, or on a separate server.
That last, separate copy is crucial. If an attacker gains access to the server running the website, they can often also gain access to the backups stored in the same location and compromise both at once.
The backup history is just as important as the most recent backup. If malicious code infiltrates the website and remains undetected for several days, the most recent backup is usually compromised just like the live website. That’s why it’s recommended to have multiple points in time available—for example, a combination of daily backups from the past week, weekly backups from the past month, and monthly backups covering a longer period.
Try it out for yourself
The most underrated step in the entire backup process is verifying it. A backup that no one has ever tried to restore is just a hope, not a real safety net. Try this simple test: if the website disappeared right now and you only had the latest backup available, could you get it back up and running in two hours? If so, you’ve got it set up right. If not, it’s time to fix it before someone has to deal with it on a Friday evening.
A backup is not the same as an archive
These two terms are often confused, but they serve different purposes. A backup is a current copy of a website whose sole purpose is to restore operations as quickly as possible after a crash, error, or attack. An archive, on the other hand, stores older versions of a website or data over the long term, typically for historical purposes, to meet legal retention requirements, or for future reference. For day-to-day website operations, you mainly need a functional backup with a short history. An archive addresses a different need and does not replace it.
Who technically handles your backups depends on what your website runs on. For a content management system like WordPress, backups are usually handled by a plugin that you need to set up once and then regularly check to make sure it’s actually running. For a custom web application or headless solution, when content is separated from the user interface, backup is typically handled differently—often directly at the database and infrastructure levels—and it is all the more important to have this covered contractually rather than relying on a single universal tool.
How much does it cost if the deposit is missing?
A dedicated cloud storage solution for backups typically costs between 50 and 500 CZK per month, depending on the amount of data; the exact amount varies by provider and the size of the website. That’s the price of prevention.
The cost of the repair without an advance payment is different. According to the public price lists of Czech companies that specialize in repairing compromised and broken websites, a minor fix—such as removing malware from a simpler website—costs in the thousands of crowns; while for a more extensive or long-neglected website, the cost can climb to tens of thousands of crowns—and that’s not even counting lost orders during the time the e-shop is down. The exact price always depends on the extent of the damage, the age of the last usable backup, and how quickly the problem is detected.
The difference between these two figures—hundreds of crowns a month for prevention and tens of thousands for remediation—is exactly why it pays to take care of backups before you need them.
What Data Loss Means for an Online Store
For an e-shop, a backup protects not only the website’s appearance but also orders, customer history, and the personal data you’ve collected from customers. If this data is lost or leaked to an unauthorized party, it’s not just a technical problem. This data constitutes personal information as defined by the GDPR (General Data Protection Regulation), and its leak or loss may also entail an obligation to notify the Office for Personal Data Protection and, in some cases, the customers themselves.
Similar to the Web Accessibility Act, which we they wrote in an article about web accessibility, it is important to note that ignorance of your obligations does not exempt you, as a website operator, from liability. Regular backups with verified restoration capabilities are therefore not just a technical precaution, but also a way to mitigate the risk of a website outage turning into a legal problem.
Frequently Asked Questions About Website Backups
How often is it recommended to back up a website?
It depends on how often the content on the website changes. An e-shop that receives daily orders needs to be backed up at least once a day; a corporate website with regular content needs to be backed up once a week; and a static website with minimal changes only needs to be backed up once a month. It’s also always a good idea to back up outside of this schedule, right before any update or major changes to the website.
What should a complete website backup include?
Two parts: the database, which stores text, orders, users, and settings, and the website files—that is, the template, plugins, and uploaded images. Both parts must be backed up and restored together; otherwise, the website will launch only partially functional.
What are the safest ways to store website backups?
The safest approach is to follow the 3-2-1 rule: three copies of your data, stored on two different types of storage media, at least one of which is physically located outside the server where the website runs—for example, in cloud storage. A backup stored only on the same server as the website protects against only some of the risks.
How do I restore a website from a backup after a server crash?
First, restore the website’s database and files to a new or repaired environment—ideally to a test version first, not directly to the live site. Only after verifying that the website is functioning properly should you switch it back to production. It’s a good idea to test this exact procedure in advance so that, in the event of an actual failure, your first attempt isn’t also the live one.
Are backups from the hosting provider enough?
Not on their own, usually. While hosting providers typically take backups, those backups belong to them, are kept for only a short time, and the latest version overwrites the previous one. To be truly safe, you need to have at least one copy stored outside the hosting provider, which you can access regardless of what happens to the hosting service.
Three Questions to Ask Yourself Today
Before you close this article, try answering these questions. Who exactly backs up your website, how often, and where are the backups stored? Do you have at least one copy stored outside the hosting provider where your website runs? And when was the last time you actually tried to restore a backup—not just checked to see if the file existed?
If you can't answer any of these questions, you face exactly the risk described in the scenario at the beginning of this article. Fortunately, you can resolve it before Friday afternoon actually arrives.
Backing up a website isn’t a one-time task that you can just check off and forget about. It’s a habit that’s worth clearly assigning to a specific person or contract—not just assuming that someone else is taking care of it. When you know who is performing the backups, how often, and that they actually work, Friday afternoons will no longer be a cause for concern.
Are you unsure whether your website's backup is set up correctly, or whether it's even covered by a contract anywhere? Contact us and we'll go over it together on your specific website.
Backing up a website is one of those technical maintenance tasks that’s easy to overlook. The cookie banner falls into the same category. We explain how to set it up according to the rules in our article on cookies on the website.
Do you want a website where it depends?
We'll also make sure your data is always secure.
How about you? Does your company need a polished digital business card, or is a simple, functional website enough for you?
Let's have a casual chat about what makes sense for your business. Please contact us at [email protected] or fill in short form.
Who performs backups, how often, and how long the backups are retained are all specified in the contract with the provider. Along with access rights and the license, this is one of the points we discuss in the article about, What to Look for in a Website Development Contract.
A security deposit is most useful when you’re leaving a supplier. Request it while you’re still working with them, not after. We explain why the order of these steps matters so much in our article on the subject, What to Ask Before Switching Web Agencies.
Backing up your data is useful not only when switching providers, but also when, when a website is hacked. In this article on what to do if your website is compromised, you'll find a step-by-step guide from the very first hour through to getting back on Google.
