Off-site backups in another country: why ours leave Romania

This week missile strikes hit Kyiv again, and data centres were among the reported targets. The city's best-known facility, De Novo, is a Tier III building that has been running since 2008 with one unplanned outage in eighteen years. That outage, in April 2025, cut power to the whole building for fourteen minutes after an automatic transfer switch misfired during maintenance. Government services and the country's largest parcel carrier were offline for most of a morning, and the company published the root cause the next day. An outage like that is what a Tier certificate is designed to make rare. A strike on the building is a different kind of event, and no certificate covers it.

Customers ask us fairly often why every disaster-recovery backup we take is shipped out of Romania to object storage operated by another company in another country, when a second copy on a shelf in the same facility would be cheaper and faster. This post is the long version of the answer.

A data centre is a building with an address

A Tier certificate describes what happens inside the walls: the power feeds, the cooling redundancy, the number of components that can fail before a rack notices. It has nothing to say about the walls. In March 2021 a fire destroyed OVH's SBG2 hall in Strasbourg, and customers whose backups sat in the same hall lost the backups along with the servers. A flood, a grid failure that outlasts the diesel, a court order, an operator that stops answering the phone, a missile: each of these arrives at a street address, and everything at that address shares one outcome.

That is why we treat the address as the unit of failure. The copy that counts as disaster recovery has to sit at a different address and be held by a different company, and the country should differ as well. A copy that meets only one or two of those conditions protects against a narrower set of events than most people assume when they read the word "backup" in a control panel.

Why object storage, and why not ours

We chose the S3 protocol for the destination because it is the least remarkable option available. An archive becomes a single object, and any backup tool or cloud SDK already knows how to fetch it and check its size. There is no catalogue to export from a proprietary system and no appliance that has to stay alive for the restore to work. On a bad day that matters more than any feature.

Whose S3 is the second half of the decision. We operate object storage of our own in Bucharest and it is on the menu as a fast local copy in the same region as your compute. For disaster recovery the copy goes to a vendor we have no other business with: Wasabi in Germany or ImpossibleCloud in France. Both sit in buildings and countries other than ours, and our own storage is never the only place a DR backup lives.

The country matters as much as the building. An object in Germany sits under German law and German courts, and a dispute, a sanction, a frozen account or an insolvency in Romania has no reach into it. The same reasoning covers us as the operator. Archives are encrypted on the hypervisor with a key that belongs to your organisation before they leave the host, so the vendor storing the bytes cannot read them, and anyone holding our credentials to that vendor gets ciphertext and nothing else.

What actually crosses the border

A backup is a full, sequential copy of the disk taken from a consistent snapshot, streamed off the hypervisor without ever returning to the storage cluster it protects. As the bytes flow they are fingerprinted, compressed and encrypted, then uploaded to the chosen backend as a multipart object. Two SHA-256 hashes are recorded along the way: one of the raw disk as it was read, one of the encrypted archive as it was stored. Both live in our metadata rather than inside the archive, so a corrupted object has nothing to vouch for itself with. An upload that ends short or incomplete fails the backup outright rather than registering a copy that would fail on restore.

Restore is the same path run backwards. The archive is fetched, decrypted with your organisation's key and decompressed onto a fresh disk while the raw hash is recomputed, and the disk is attached only when that hash matches what was recorded on the day of the backup. The archive format is standard age encryption over standard zstd compression, so a restore does not depend on our control panel or on our company still existing. The backup documentation covers the format and the off-platform restore in detail.

One backup run, up to three countries

A single run can write to several backends at once. The disk is read once and the same point-in-time archive is uploaded to Romania, Germany and France in parallel, each copy with its own checksum and its own restore. Losing an entire vendor leaves the other copies untouched. Scheduled backups can also be pointed at a rotating off-site target that picks one of the foreign vendors per run and never selects the local Bucharest copy, so a schedule set up for disaster recovery cannot quietly turn into a same-region backup over time.

Questions worth asking about your own backups this week

The questions do not depend on the provider. Where does the backup physically sit, and is that a different building from the servers it protects? Which company holds it, under which account and which legal entity? Who holds the encryption key, and is a copy of the bytes useless without it? When did you last restore from it, as opposed to confirming that a file with the right name exists?

If the first two answers come back as "same place", the fix does not have to be elaborate. An S3 bucket in another country, written to by rclone or restic from your own server on a schedule, already moves the copy past the address as a failure domain. Our buckets in Bucharest accept exactly that kind of upload from any machine, whether or not it runs with us, and the two vendors named above receive our own DR copies the same way.

Earlier this year we wrote about what has to fail before you lose your data. That post walks up a ladder that ends with the provider itself failing. This week added a rung to it. The answer we built for the other rungs holds for this one as well: the copy has to be somewhere else, and somewhere else means a building your servers are not in, owned by a company that is not your provider, in a country with its own courts.