A backup that lives on the same disk as your data protects you from nothing: it disappears with the machine, with the account, or with the incident itself. On a VPS, the only copy that matters is the one stored somewhere else. Here is how to build it, and how to prove it works with a restore you have actually run.
What Your VPS Plan Already Covers, and What It Doesn't
Every NVMe VPS plan, from VPS-1G at $9.99/month (94.48 DH excl. tax) up to VPS-5G at $49.99/month (472.80 DH), ships with the same baseline: automatic backups, firewall and DDoS protection, 24/7 monitoring, one dedicated IPv4, unlimited bandwidth, root access, a management panel, support six days a week, delivery in under 15 minutes, and a 99.9% SLA on infrastructure.
That list answers "am I covered?". It does not answer the Sunday-night question: "can I come back after losing the server, the account, or the datacenter?". An automatic backup stays tied to your subscription. Account suspended, payment disputed, incident larger than the machine — the copy leaves with everything else. That is not a product flaw; it is what a local backup is.
So write down two things: the frequency and the retention actually applied to your plan. Read them in the panel or ask support, and keep them next to the date of your last restore test.
The 3-2-1 Rule on a Production VPS
Three copies, two different media, one copy offsite. The rule is over thirty years old and still the fastest way to judge a backup design, even for a single server.
- Three copies: production, one fast-restore copy, one offsite copy. Only one of the three is optional, and it is never the third.
- Two media: the VPS NVMe on one side, object storage, a NAS, or a second server on the other. Two folders on the same disk do not count.
- One offsite copy: another provider, another region, another account. The goal is to leave the failure domain, not to change directories.
- One copy that is hard to delete: versioning or object lock on the target, so a malicious encryption run cannot rewrite your history.
Offsite Does Not Mean "in the Cloud"
Offsite means outside the failure domain of production. A billing mistake, a project deleted in the wrong place, a leaked API key — any of these wipes data that was perfectly replicated. Geography protects you from physical failures; account separation protects you from human ones. The second is usually the missing one.
One scheduling detail matters here: production sits in New York today, and a Rabat datacenter is announced but not open yet. Until it opens, "offsite" means outside this provider or outside this region. A copy in the same building as the VPS shares the incident.
Snapshot, Backup, Replication: Three Objects, Three Jobs
A snapshot captures a volume at a point in time. Perfect for rolling back a bad update in ten minutes, useless as a backup: it lives next to the data and disappears with the storage system that holds it.
A backup produces an independent, dated, encrypted object that can be copied elsewhere and read without the original server. That object is what you test, and the only one you really own. Replication copies continuously; it protects against hardware failure, not logical corruption, because a bad schema change replicates as fast as a good write. Plenty of teams believe they have backups when all they have is replication.
| Offsite target | What you keep control of | Starting cost | When to pick it |
|---|---|---|---|
| S3-compatible object storage at another provider | Versioning, object lock, lifecycle rules, client-side encryption | Billed per GB stored by that provider | Large volume, rare restores |
| A second Open Vista VPS, copy pushed over SSH | Root access, full control, same panel | From $9.99/month (94.48 DH) on VPS-1G, 30 GB NVMe | You want to restore yourself, with no third-party API |
| Managed CodeGuard backup | The scope the service covers, no script to maintain | List price, see the store | You would rather delegate execution and monitoring |
The three are not exclusive. A common mix: the plan's automatic backup, an encrypted export to object storage, and a second copy on a small VPS used as the restore target. The managed backup service is the shortest path when nobody on the team wants to maintain a script.
Encrypt Before It Leaves, Keep Only What You Need
Encryption Happens on the Client Side
An unencrypted copy sitting at a third party is a breach waiting to happen: databases, customer files, sometimes API keys in plain text. Encrypt before upload (restic, age, rclone, GPG) and keep the key off the machine you are backing up. A key stored in the same script as the backup protects nothing.
The one-time test: pull an object from the target, decrypt it on a machine that has never seen the server, and read the contents. If you cannot repeat that alone, the backup is not ready.
Retention Is Decided Before the First Incident
A grandfather-father-son rotation covers most needs: a few daily copies for the current week, a few weekly ones across the month, a few monthly ones across the half-year. The point is not to hoard data but to reach a state older than the slow corruption you discover three weeks late.
Retention costs money, and that cost is measured in useful gigabytes, not production gigabytes: compression and deduplication cut the bill. For scale, the pricing grid uses 1 USD ≈ 9.46 MAD. A backup target does not need to be fast; it needs to be there, readable, and cheap per gigabyte.
Test the Restore, Not the Backup
An untested backup is a hypothesis. Two numbers describe it: the RPO, the maximum data loss you accept, which is really the copy frequency, and the RTO, the time needed to bring the service back. Unmeasured, both stay theoretical.
- Pick a representative data set: production database, user uploads, web server configuration.
- Restore onto a clean machine, never onto production, not even for a quick check.
- Time it from the first download to the first request served.
- Check application integrity: the database connects, files respond, certificates are in place.
- Record the date, the duration, the errors, and every manual fix.
- Repeat every quarter, and after any schema or provider change.
The value of the drill is not the result on the day; it is the fix to the script that follows. A restore needing three undocumented manual steps is not a procedure, it is a memory.
FAQ
Is the automatic backup in my plan enough?
For a deleted file or a bad update, often yes. For a lost account or an outage that hits the datacenter, no: the copy disappears with the thing it protects. It is the first layer, not a complete answer to the 3-2-1 rule.
Object storage or a second server?
Object storage is cheap per gigabyte and suits long archives, but restores are slower and depend on an API. A second VPS, from $9.99/month (94.48 DH), gives immediate root access and a restore path you control end to end.
How long should I keep copies?
It depends on your business, the accounting rules that apply to it, and how long it takes to notice corruption. A weekly and monthly rotation over six months is a reasonable starting point for an SMB site; beyond that, every extra month costs money and needs a reason.
What if the New York datacenter goes down?
The 99.9% SLA covers infrastructure: it is an availability commitment, not a promise that nothing will ever fail. The offsite copy is exactly what lets you rebuild elsewhere. It is also why the Rabat datacenter is announced but not presented as available yet.
Your Next Step: One Offsite Copy This Week
You do not need a three-month project. You need a target, encryption, a rotation, and a dated test. A small VPS with 30 GB of NVMe holds several generations of compressed copies for an SMB site, with the same panel and the same automatic backups as the rest of the VPS lineup.
Pick the plan that covers your archive volume: VPS-1G (1 vCPU, 1 GB RAM, 30 GB) at $9.99/month, VPS-2G (40 GB) at $19.99, VPS-3G (50 GB) at $34.99, VPS-4G (80 GB) at $39.99, or VPS-5G (100 GB) at $49.99. Delivery in under 15 minutes, and you can move to a larger plan later without a painful migration.
Then put the first restore test on the calendar, before the first incident.