Treat backup as a routine you rehearse
A backup only counts once somebody has restored from it. The usual surprise arrives during the incident: the copy lives on the same server that failed, the database dump is a month old, or nobody remembers how to bring it back. We suggest a simple discipline instead: automatic copies, at least one of them kept away from the production server, and a restore that you actually try from time to time. On cPanel the daily backup runs by itself and you restore it from the client panel. On VPS and dedicated servers our DevOps engineers can schedule restore drills from your included hours, so that the first real restore is not also the first attempt.
What each plan gives you out of the box
cPanel hosting comes with an automatic daily backup that you restore from the panel. A VPS offers snapshots, which are full copies of the state of the server, with no guaranteed frequency. A dedicated server includes no backup by default: its NVMe drives come in pairs and RAID is configured at installation, but RAID protects against a failed disk, not against deletion, ransomware or a bad release. Off-server backup, point-in-time recovery for databases and restore tests are built by our team from the included DevOps hours, which are 5–10 h a month on dedicated servers depending on the plan.
| Plan | Backup | How you restore | Location |
|---|---|---|---|
| cPanel hosting | One automatic backup every day | You restore it from the client panel | EU: Frankfurt |
| VPS | Snapshots, frequency not guaranteed | You roll back to a chosen snapshot | EU: Frankfurt |
| VPS with off-server backup | On request, built from DevOps hours | As defined in the strategy you agree | Agreed with the team |
| Dedicated server | Not included by default, built on request | As defined in the strategy (3-2-1, PITR) | EU: Frankfurt, plus external storage on request |
RPO and RTO: two numbers to agree before you need them
“Back up as often as possible” is not a plan, and two figures turn it into one. The recovery point objective (RPO) is how much data you can afford to lose, measured in time. The recovery time objective (RTO) is how long the business can wait for the service to come back. We build the strategy backwards from those two figures instead of starting from a tool.
A daily backup can lose up to a day of work. With WAL streaming, a PostgreSQL database can get under a minute, configured on request. A ledger and a brochure site rarely need the same figure.
Restore time depends on the volume of data, the disk and where the copy is kept. We do not guarantee an RTO. The only figure you can rely on is the one measured in a restore test.
A restore drill proves both figures. It can run in a separate environment, so production is not touched, and it leaves you with a measured time and a list of what was missing.
Six ways to lose data, and the safeguard for each
Disasters are rare, but the ordinary failures behind them are not. For each scenario below we name the safeguard we recommend. On VPS and dedicated servers our team builds these safeguards from your included DevOps hours.
A failed disk or memory module
Hardware failure is the classic cause of data loss. Dedicated servers use NVMe drives in pairs with RAID configured at installation, and the EPYC and Xeon tiers carry ECC memory. RAID keeps the server running when one drive dies, but it is not a backup, so a copy outside the machine is still needed.
Safeguard: RAID plus an off-server copyRansomware or a hijacked account
Whoever gets into the server can encrypt every copy the server can reach. Picture a logistics company in Timisoara whose dispatch system is encrypted overnight. At least one copy must live outside the server, where the production account cannot change or delete it, either immutable or offline. We set it up on request from your hours.
Safeguard: an isolated copyAccidental deletion
A DELETE without a WHERE clause on a production table is the classic human error. With point-in-time recovery (PITR) configured, you go back to the moment before the mistake. A daily backup only returns you to the last copy, which may be a day old.
Safeguard: PITR on requestLoss of the whole data centre
Fire, flood or a long outage at the operator. The safeguard is a copy in another location, for example the second data centre. Replication and failover are not included by default, and the team configures them on request from the DevOps hours.
Safeguard: a copy in another locationA release that corrupts data
A new version ships with a bug that rewrites records wrongly. With a separate database backup you roll back the database alone and keep the application files exactly as they are.
Safeguard: a separate database backupOutgrowing the current server
Growth is a planned risk. A VPS can move up to a larger plan with more vCPU, RAM and disk, and a move to a different server is scheduled in advance so that the interruption stays short. Take a fresh copy right before the switch.
Advice: plan the move earlyDatabase backup, engine by engine
A full copy of a VPS is not always enough, because a database that is being written to can be captured halfway through a transaction. Each engine has its own mechanism for point-in-time recovery, which takes you to the exact moment you choose and not only to the last snapshot. We configure them on request from the included hours.
What is included and what is built on request
There is no separately sold premium backup. What comes with each plan is listed below, and anything beyond that is built by our engineers from the DevOps hours of your subscription: 1 h a month on cPanel from Advanced up, 1–8 h on VPS, 5–10 h on dedicated servers depending on the plan, and 10 h on GPU servers. You request the work from the client panel. Hours do not carry over to the next month, and extra hours are accepted and billed separately.
- cPanel: an automatic daily backup, restored from the panel (included)
- VPS: snapshots with no guaranteed frequency (included)
- Dedicated servers: NVMe drives in pairs and RAID configured at installation, with no backup by default
- Off-server backup following the 3-2-1 rule: on request, from the DevOps hours
- PITR for databases (WAL, binlog, oplog): on request, from the DevOps hours
- Restore tests and the retention period: agreed with the team and configured from the DevOps hours
Restoring a backup in four steps
Sign in to the client panel
On cPanel you restore the daily backup from there. On a VPS you pick a snapshot.
Choose the restore point
Select a copy from before the problem began. The newest copy is not always the right one, especially when the damage went unnoticed for several days.
Confirm the restore
A restore overwrites the current state. If you are unsure, ask the team to restore into a separate environment first, so that you can compare the two.
Check the result
Confirm that the application starts, that recent records are present and that integrations still work. How long the restore takes depends on the volume of data.
Backup and recovery questions
Do I need to stop the server to take a snapshot?
Normally not: a VPS snapshot is taken while the server runs. For a database that copy is not always consistent, so we recommend a separate database backup, either a dump or WAL and binlog shipping, which the team sets up on request.
How long does it take to restore a very large snapshot, say 500 GB?
It depends on the volume of data, the disk and where the copy is kept, and restoring from an off-server copy takes longer than from a local one. We do not promise a fixed time. A restore test, which we can run with you, gives the realistic figure.
Are backups encrypted?
Encryption of off-server backups is part of the strategy we configure on request, for example copies that leave the server only in encrypted form, with the keys kept apart from production. Tell the team your requirements when you ask for the setup.
What if I need to keep backups for longer than a month?
The retention of off-server backups is decided when the strategy is configured, according to your needs and any legal archiving duties. Agree the storage for a longer period with the team; plan details are on the pricing page.
Can I download a copy of my data?
On VPS and dedicated servers you have root access and can copy data with the tools you prefer, such as rsync or tar. The team can also configure automatic copies to external object storage from the DevOps hours, for example Amazon S3, Google Cloud Storage or Azure Blob.
Where are my backups kept?
Servers and the backups held by the platform stay in the EU, in Frankfurt. An off-server copy can go to a second location that you agree with the team.
Agree your RPO and RTO before the incident
cPanel includes a daily backup and a VPS includes snapshots. On dedicated servers our team builds the backup strategy from the included DevOps hours, and support is available in English and Romanian. See the pricing page for plan details.
See the plans →