A backup you actually use
Most companies find out their backup doesn't work only when disaster strikes. That is why we advise treating backup as a process, not a checkbox: automatic copies, kept away from the production server, and restores tested regularly. On cPanel the daily backup runs automatically and you restore it from the panel; on VPS and dedicated servers the DevOps team can set up scheduled restore tests from your included hours.
What backup each plan includes
cPanel hosting has an automatic daily backup you restore from the panel. A VPS has snapshots — full copies of the server state — with no guaranteed frequency. Dedicated servers include no backup by default: the NVMe disks come in pairs and RAID is set up at install time, but RAID is not a backup. External backup, PITR for databases and restore tests are set up by our team from the included DevOps hours (5–10 h/month on dedicated).
| Plan | Backup | Restore | Location |
|---|---|---|---|
| cPanel Hosting | Automatic daily backup | From the customer panel | EU (Frankfurt) |
| VPS | Snapshots, no guaranteed frequency | From a snapshot | EU (Frankfurt) |
| VPS — external backup | On request, from DevOps hours | Per the configured strategy | Agreed with the team |
| Dedicated server | Not included by default — set up on request | Per the strategy (3-2-1, PITR) | EU (Frankfurt) + external storage on request |
RPO and RTO — the numbers you should set yourself
Instead of "backup ASAP", it pays to fix two concrete values. RPO (Recovery Point Objective) tells you how much data you can afford to lose. RTO (Recovery Time Objective) tells you how long a restore may take. The team builds the strategy around these values.
The maximum data loss you can accept. A daily backup means up to a day lost; with WAL streaming a database gets below one minute — set up on request.
Restore time depends on data volume and the chosen strategy. We do not guarantee an RTO — the only reliable figure is the one measured in a restore test.
Disaster scenarios — and how to protect yourself
Disasters are rare but high-impact. Here are the most common scenarios and the protection we recommend for each. On VPS and dedicated servers the team sets up these measures from the included DevOps hours.
Hardware failure (disk, RAM)
The most common cause of data loss. Dedicated servers have paired NVMe disks with RAID set up at install time, plus ECC RAM on the EPYC and Xeon tiers. RAID keeps the server running when a disk fails, but it does not replace backup — an external copy is still needed.
Protection: RAID + external backupRansomware or account compromise
The attacker encrypts server files — and any copy the server can reach. So at least one copy should live outside the server, where the production account cannot change it (immutable or offline). We set it up on request, from the DevOps hours.
Protection: isolated copyAccidental data deletion
"DROP TABLE users" run against production. The most common human error. If the database has point-in-time recovery (PITR) set up, you go back to just before the mistake; a daily backup only takes you back to the last copy.
Protection: PITR on requestFull DC outage
Fire, flood, extended operator outage. The protection is a copy in another location, such as a second DC. Replication and failover are not included by default; the team sets them up on request, from the DevOps hours.
Protection: copy in another locationApp bug corrupts data
A deploy introduces a bug that corrupts DB records. With a separate database backup you restore only the DB (not the whole server) — app files stay, data rolls back.
Protection: separate DB backupMigration to another server
You outgrow the current plan. A VPS moves up to a higher tier with more vCPU, RAM and disk; for a move to another server we plan the migration in advance to keep downtime short.
Tip: plan the migration earlyDatabase backup — per-engine strategies
A full VPS backup is not always enough. Databases have their own point-in-time recovery (PITR) mechanisms — they let you go back to exactly the chosen moment, not just the last snapshot. We set these up on request, from the included DevOps hours.
What is included — and what is set up on request
There is no separately sold "premium backup": what is included is stated on each plan, and anything beyond that the team builds from the DevOps hours in your subscription. Hours over the quota are billed separately, by the hour.
- cPanel: automatic daily backup, restore from the panel — included
- VPS: snapshots, no guaranteed frequency — included
- Dedicated servers: paired NVMe disks, RAID set up at install — backup not included by default
- External backup following the 3-2-1 rule — on request, from DevOps hours (5–10 h/month on dedicated)
- PITR for databases (WAL, binlog, oplog) — on request, from DevOps hours
- Restore tests and retention period — agreed with the team and set up from DevOps hours
Restoring a backup — in 4 steps
Open the panel
Sign in to the customer panel. On cPanel you restore the daily backup there; on VPS you pick a snapshot.
Pick a point in time
Pick the copy from just before the problem. The latest one is not always right if the error has been there for a while.
Click "Restore"
A restore overwrites the current state. If you are unsure, ask the team to restore to a separate environment first so you can compare.
Check the result
Check that the application runs and the data is where it should be. How long the restore takes depends on data volume.
Frequently asked questions
Does a snapshot require stopping the server?
Usually not: a VPS snapshot is taken with the server running. For a database, though, a snapshot of a running server is not always consistent, so we recommend a separate database backup (dump or WAL/binlog), which the team sets up on request.
How long does restoring a very large snapshot (e.g. 500 GB) take?
It depends on data volume, disk and where the copy is stored — restoring from an external copy takes longer than from a local one. We do not promise a fixed time: the realistic figure comes from a restore test, which we can run with you.
Are backups encrypted?
Encrypting external backups is part of the strategy we set up on request — for example copies that leave the server only in encrypted form, with keys kept apart from production. Tell the team your requirements when you request the setup.
What if I want retention longer than 30 days?
Retention for external backups is set when the team configures the strategy, based on your needs and your legal archiving obligations. Storage for longer retention is agreed with the team; you will find the plans on the pricing page.
Can I download a snapshot locally?
On VPS and dedicated servers you have root access and copy your data with the tools you prefer (rsync, tar). The team can also set up automated copies to external storage from the DevOps hours, such as AWS S3, Google Cloud Storage or Azure Blob.
Your data is too valuable to leave to luck
cPanel includes daily backup and VPS includes snapshots. On dedicated servers the team builds the backup strategy from the included DevOps hours. See the pricing for details.
See plans →