Is it safe to have backup and production servers in the same cluster?

Question

I have two virtual servers maintained by the same provider. I asked them to place them on different physical machines. They told me that they placed them in different nodes of one cluster.

I do not know much about clustering and what node actually is (is a an independent machine?) What I wish to know is if it is safe to have a backup server in the save cluster with production server.

I think it is a good idea to have a backup server on an independent machine so that if one of the servers accidentally crushes the other one is still safe.

Answer 1

No solution can be examined without knowing more about the threat model, ie, what are you trying to protect against?

If you want to survive software failure on the part of your hosted image, then simply having two VMs should be fine; if one crashes, the other should still be there.

If you want to survive software or hardware failure on the part of the host, then joeqwerty is right in his comment above: it will depend on the details of the hosting and clustering technologies, and only your hosting company can advise on that.

If you want to survive infrastructure failure on the part of your hosting company, then having VMs on different hosts will not be enough; you will need VMs at different sites, or possibly even with different providers.

Until you are more precise about exactly what sort of redundancy you're looking for, noone can say whether a given solution will be enough.

And a couple of cautionary notes: the more separation you introduce between the VMs, the harder it will be to fail over to the backup server in any reasonable timescale. And ADM is right to note that backups should be as far away as possible from the source of the information, though that is not quite the question you asked.

Answer 2

No, this scheme is not considered safe, because if your (provider/host server/providers backup) goes down, you won't be able to restore your business.

Safest backup is when your files are going to an absolutely different location - Dropbox, S3, Github, your own home PC, etc.

If any disaster happens, with this setup, you can easily buy a new server anywhere else and roll out your backup.

Answer 3

Sooner or later you are going to have to make a compromise between latency and protection of your data.

The best protection you can get for your data is through algorithms that guarantee protection against byzantine failures. Such algorithms require at least four replicas, and communication delays between those replicas can cause poor latency for data updates. This is especially bad, because those replicas need to be in four different data centers for best possible security.

Almost everybody chose to sacrifice a bit of the the integrity guarantees you get from such a setup in order to reduce cost and/or improve performance.

Two servers in the same data center can improve availability of your service and protect against some cases of data loss. The two server setup does however introduce a minor risk of data corruption in case both servers are writing in a situation where they think the other is down. Keeping the servers in the same data center reduce latency between them, and makes it more likely they'll stay connected and not simultaneously perform conflicting writes.

But two servers in the same data center is not a replacement for a backup or replication.

It is possible to replicate data to another physical location right after it is written. If you allow writes to be committed and communicated back to the client before data is replicated to another physical location, there will be negligible latency cost. The window of data loss possibility can be kept to a few minutes or a few seconds depending on the write volume.