In this guide (9)
- 1Who this is useful for (and who it isn't)
- 2What a website backup is, in practice
- 3Why a copy on the same server isn't enough
- 4The seven questions to ask your provider
- 5Three scenarios, with explicit assumptions
- 6Local copy, hosting, dedicated service
- 7When a managed CMS is not the right choice
- 8What KeideaCMS states today
- 9Checklist before signing
A website backup is not a file copied into the same folder as the site. It's a copy you can restore from if pages, databases or media become corrupted, encrypted or deleted. Without a tested copy, "we have a backup" is just a sentence, not a plan. This guide is for an SME owner or IT manager who needs to decide what to buy and what to put in writing in the contract.
This does not cover the first hours of an attack: that is covered in the guide on what to do if your site has been hacked. Here we talk about copies, restores and responsibilities. The signs that a site is compromised without any noise are covered in a compromised site without knowing it.
Who this is useful for (and who it isn't)
It's useful if you have a business site or an ecommerce store, you pay a subscription or hosting fee, and you don't know whether a copy exists to restart from. The typical reader is renewing a contract, switching provider, or has heard "backup included" without details.
This isn't the right guide if you're looking for a script to run tonight on a server you administer yourself: there's no command tutorial here. Nor is it right if the problem is an incident in progress: go back to the guide on the first hours. It doesn't replace a continuity policy for a group with its own data centers: that requires procedures and roles that an article can't write.
What a website backup is, in practice
A website backup is a usable copy of what makes the site work: files (theme, media, configurations), database (content, users, orders), and whatever is needed to bring it back up. A folder of images without the database is not a site. A database dump without the media leaves the pages empty.
Two measures to ask for, not to invent:
RPO (recovery point objective): how much history you can lose. If the last copy is from yesterday evening and this morning you took ten orders, those ten are gone.
RTO (recovery time objective): how long the site can stay down while someone restores it. It's not the same number as the RPO.
These aren't universal legal standards. They're agreements. If the provider doesn't put them in writing, they don't exist.
Why a copy on the same server isn't enough
NCSC, in its guide on mitigating malware and ransomware (accessed on 14 September 2026), lists regular backups as the first action: up-to-date copies of important files, restore tests, offline copies or copies otherwise separate from the production network. Stated reason: ransomware also targets connected copies, to make payment more likely. The same guide asks that backup disks not be left permanently connected to the network, that previous versions in the cloud be protected, that copies be scanned before restoring, and that the products used for backup be kept updated.
CISA, on the StopRansomware portal, states the same point in one line: offline, encrypted copies, and regular testing. This isn't a ranking of providers. It's the minimum scope to check.
A copy that lives on the same machine as the site can disappear along with the site. A copy that syncs in real time to the cloud can also copy files that have already been encrypted. That's why "we have a cloud backup" without previous versions and without a test doesn't settle the question.
The seven questions to ask your provider
Get these in writing. If the answer is "we'll take care of it", ask how.
What gets copied? Files, database, media, mail, certificates, configurations. A list, not a slogan.
How often, and how many copies are kept? Frequency and retention. One dump a month on a daily ecommerce store is a gap, not a plan.
Where is the copy stored? Same server, another disk, another data center, cloud, offline. How many separate locations.
Who can delete or encrypt it? Same admin accounts as the site, or separate access, with multi-factor authentication.
When was the last test restore done? Date, scope, outcome, duration. Without this, the copy hasn't been proven.
What happens if the copy is infected? Is it scanned before the restore? On which environment? NCSC states this explicitly: compromise can predate discovery.
Who pays for the restore time, and within how many hours? Included in the fee, extra, time slot. This isn't a detail: it's the real cost of the incident.
Three scenarios, with explicit assumptions
These aren't market averages. They're meant to stop you buying the same product for three different problems.
A showcase site updated rarely, few forms. A full copy on a set schedule, plus an offline copy or one on another account, plus a test restore at least whenever you change provider or platform, may be enough. The risk is a defacement or a badly uploaded file, not a hundred lost orders.
A site with a blog, leads, appointments. You need a frequency aligned with how often the data changes, previous versions, and a tested restore of both database and files. If appointments only live on the site, the copy is also your calendar.
An ecommerce store or catalog that moves every day. Here RPO and RTO must be written down. A nightly copy loses the day. A channel manager or external management software, if present, has its own copies: the site shouldn't be the only source of truth for orders. If it is, the site's backup is the company's backup.
Local copy, hosting, dedicated service
This isn't a ranking. It's a scope, symmetrical.
| Mode | What it's for | Typical limit | When it makes sense |
| Copy on the same hosting | Recovering from your own mistake, a plugin, a deleted file | Disappears with the server if the attack hits there | As an extra layer, not as the only copy |
| Provider copy / snapshot | Recovering if it's managed by whoever keeps the site running | Scope and timing are often implicit; the test needs to be requested | Managed plan, if frequency and restore are documented |
| Dedicated backup service | Separate copies, versioning, sometimes immutability | Cost and integration; it too needs to be kept up to date | Data you cannot afford to lose, or industry obligations |
When a managed CMS is not the right choice
KeideaCMS is a managed proprietary CMS. The security page states native WAF, AES-256 encryption of forms, 2FA and file scanning. As of September 14, 2026, it does not state backup frequency, retention, encryption of copies, restore testing, RPO or RTO. So, based on that documentation, it is not an enterprise backup product.
If you need an RPO of minutes, immutable copies compliant with a regulated industry, or a disaster recovery plan with periodic drills, you first need a continuity design (and often a dedicated backup provider), not just a CMS. If you manage the servers yourself, a managed CMS adds a perimeter you don't control: that's fine only if you accept that model.
In those cases, buying "the website" hoping it will solve the restore issue is the wrong product. Better to say so before signing.
What KeideaCMS states today
On KeideaCMS, the security stated today is what's on the security page: WAF in the core, encrypted forms, TOTP 2FA, upload scanning. Hosting, maintenance and support are included in the plans' fee. The comparison with other approaches is on the comparison page.
Backup, in the absence of a public sheet with frequency and testing, should be asked about in the quote just like with any other provider: the seven questions above. We don't promise that "with us you don't need it". We don't use the absence of a public CVE as proof that a copy isn't needed. The platform sits on our servers: your domain, content and exportable data remain yours, not the software code.
If the site is already under attack, don't start here: start from the guide on hacked website, what to do. The overview of "who keeps security running over time" is in managed website security.
KeideaCMS
Do you want a written list of what is covered (backup included or excluded) on your current website?
Security, scope and limits audit → Contact
Checklist before signing
List of what is backed up: files, database, media, configurations.
Frequency, retention, and where the copies are stored (how many distinct locations).
At least one copy does not live on the same server as the site.
Date of the last test restore, with outcome and duration.
Access to the copies separate from site access, with multi-factor authentication if stated.
What happens if the copy is infected, before bringing the site back up.
Who pays for the restore, during what hours, within how many hours.
No "backup included" without the figures above.
Written link to the incident procedure, not just a single "we'll take care of it".
A website backup is a copy from which you have already restored at least once, as a test. Everything else is a statement. The next step, if you want a clear scope on your current site, is an audit with explicit limits: it is not a certification and it is not a "secure website".
