What we do · Storage and compute
Disaster recovery and cross-site replicas
For critical systems we keep a continuously updated copy at a second site, so recovery is a failover rather than a restore, and we design the replication path, the firewall posture around it and the monitoring that tells us the moment the copy falls behind.
What it is
A recovery design matched to the service you order. A small, simple service gets solid backups and a tested way back. A platform that cannot be down gets live replicas in another datacenter, storage replicated between arrays, and a front end that keeps serving while the back end recovers. Recovery point and recovery time follow the service, and we write yours down.
How we build it
Live database replicas at a second site. A production database replicates continuously, by global transaction ID, to a read-only replica in another datacenter over our encrypted private backbone.
Pull-only, enforced at the firewall. The protected side never pushes. The replica and backup systems reach into production to take what they need, and backups are taken over our air-gapped out-of-band network, never across a production segment; production has no network path to them and no credentials for them. Only our management network may reach the recovery systems, and everything else is explicitly denied on the firewall appliances, not just on the hosts.
Storage replicated between countries. Underneath, volumes can replicate array to array between HPE 3PAR arrays in Athens and Amsterdam, on dedicated ports, so a block-level copy of your platform already exists in the other datacenter. Inside each site, clustered systems keep each member on a different physical array.
EU data stays in the EU. Replicas and backups of EU-hosted data stay inside our EU infrastructure.
Encrypted at rest, wiped with a certificate. Encryption at rest is available by default. Drives that leave service are sanitised with Blancco, and we keep the PDF erasure certificate for every disk we wipe.
Watching for drift. Replication health is checked every few minutes, and any change of state, broken, lagging or recovered, raises an alert to the engineers on duty.
Serving through a back-end outage. For public web properties, the cache layer is configured to keep serving content when the application tier is down, so a back-end failure does not become a public outage while we recover.
Backups underneath it all
We back up virtual machines, bare metal Linux and Windows servers, SQL servers and cPanel and Plesk nodes with Veeam, and Linux file and database data with a deduplicating backup hub that pulls over SSH using restricted, append-only keys. Repositories run on XFS with fast cloning and a hardened repository tier that receives copy jobs. Schedules are set from measured run times so large jobs never collide, coverage is checked against the live inventory, not trusted from job status, and restores are tested regularly, as often as weekly.
What it protects you from
- Losing your primary database host or your primary site.
- Ransomware or an intruder deleting your backups from the compromised server.
- Replica drift: every replica's state is checked every few minutes.
- An application outage turning into a public outage.
- Gaps in backup coverage: every machine that should be backed up is, and we check it against what is running.
In practice
A news site kept serving with its back end switched off. For a news publisher, we configured the cache tier to serve stale content on error for a full day, then proved it: the back end was deliberately marked failed and cached pages kept returning normally to readers.
A database cluster designed to lose an array. For an analytics customer, every cluster member's data volume sits on a different physical array, so the loss of an entire array costs one replica and the database keeps serving with no failover at all.
Why EuroVPS
- Pull-only backup and replication, enforced on the firewall, with no exceptions.
- Recovery designed and documented per service.
- Replicas and backups monitored for freshness, not assumed.
- Array-to-array replication between Athens and Amsterdam, with EU data kept inside the EU.
- Design aligned with ISO 27001, NIS2 and NIST guidance on boundary protection.
FAQ
What RPO and RTO do I get? It depends on the service you order. Basic services get backups and a defined restore path; services with cross-site coverage get live replicas and failover. We will write yours down.
Why pull-only? If production could push to backup, an attacker on production could reach backup. With pull-only, no such path exists.
Can my replica live in a different country? Yes. Athens and Amsterdam replicate to each other, array to array and database to database, over our own private network. EU-hosted data stays inside our EU infrastructure.
Do you test restores? Yes, regularly, as often as weekly, and we check coverage against what is actually running, not against what the backup job says.
Is my data encrypted at rest? Yes, by default. And when a drive leaves service it is sanitised with Blancco, with an erasure certificate kept for that disk.
Recovery is designed before the bad day, not during it. Talk to an engineer about what your services need.
Your next infrastructure partner
Let’s look at
your setup.
Tell us what you run today and what needs to improve. An engineer will review your brief and help you plan the next step.
+357 222 32280
who will look after your infrastructure.
Let’s start with your setup.
A little context helps us start the right conversation.