Backup, replication, high availability
These three terms are often used interchangeably. They describe three different mechanisms, protecting against three different things. Confusing the first two is one of the most common ways of losing data.
Three mechanisms, three protections
Backup
Our clients’ virtual machines are backed up daily, on D&D’s Swiss infrastructure.
A backup is a dated and separate copy of your data. Its value lies precisely in being frozen: it lets you return to yesterday’s state, or the day before’s, when something went wrong today.
It is the only mechanism that protects against accidental deletion, database corruption, an application update that goes badly, or encryption by ransomware.
Restoration is part of the service: you ask us to restore, we restore. How long it takes depends on the volume and on what has to be brought back.
The retention policy — how many copies, how far back — is defined with you, according to your legal and business obligations. We prefer to set it with you rather than advertise a generic figure that would match neither your constraints nor your volumes.
Replication
Where requirements justify it, replication to another Swiss infrastructure can be put in place.
Replication keeps a copy of your machine on a second site, in another data centre located in Switzerland and meeting the same requirements. It answers one specific risk: the prolonged unavailability of a site.
It does not answer the risk of data loss. Whatever is written on site A is copied to site B — including a deletion, including a corruption, including malicious encryption. Replication comes in addition to backup, never in its place.
We do not put it in place as a matter of course: it has a cost, and it is only relevant if your tolerance for the loss of a site genuinely justifies it.
High availability
The infrastructure includes hardware redundancy. Depending on the environment, a virtual machine can restart on another host when a failure occurs.
That is already real protection against the failure of a physical server: the machine comes back, on another host, without anyone touching the hardware.
It is not a promise of zero interruption. A restart is still a restart: the service is unavailable while the machine comes back up, and an application may need to be checked afterwards.
When your availability requirement is higher, a more elaborate architecture can be designed: distribution across several machines, application failover, database replication, load balancing. That is designed for your specific application — there is no universal high-availability architecture, and it would not be honest to sell one as an extra line on a quote.
Choosing what you actually need
The right question is not “how many nines?”, but “what happens if…”.
Questions to ask yourself
- How long can my business run without this service?
- How much data loss can I absorb: an hour, a day?
- Do I have a legal retention obligation?
- What happens if someone deletes the wrong data?
- Who decides to trigger a restoration, and under what procedure?
Possible answers
- Daily backup: the baseline, for every machine
- Extended retention: where retention is an obligation
- Replication to a second Swiss site: where losing a site is the main risk
- Distributed architecture: where the interruption itself is the main risk
- A combination of all three: for genuinely critical environments
Frequently asked questions
Can replication replace a backup?
No. Replication copies whatever happens on the first site to the second, errors included. If a database is corrupted or files are encrypted by ransomware, the replicated copy is affected in the same way.
Only a dated, separate backup lets you return to an earlier state.
Where are the backups kept?
On D&D’s Swiss infrastructure — that is, on hardware we own and operate, in Switzerland.
What is the retention period?
It is defined with you, according to your obligations and your volumes.
We prefer not to advertise a generic figure: the answer is not the same whether you host a brochure site or accounting records subject to a statutory retention requirement.
Is the second replication site in Switzerland?
Yes. Where replication is put in place, it targets another infrastructure or data centre located in Switzerland and meeting the same requirements.
Can I test a restoration?
Yes, and it is good practice. A backup whose restoration has never been verified is an assumption, not a guarantee. We arrange these tests on request.
See also
How much interruption can you really absorb?
Answer that question and the architecture almost designs itself. We can help you answer it.