How fast does your application need to be – how quickly do you need to be able to see a response after you enter a command? In some contexts, speed is not a critical factor. For instance, if you’re entering or retrieving accounting data, you don’t want to wait for half an hour, but anything up to a second in response might be acceptable – at least on a temporary basis. On the other hand if you are trading in dynamic financial markets, a few milliseconds in latency could mean the difference between a profitable or unprofitable trade. How far can you go with WAN or cloud based disaster recovery in such cases?
The key metric here is latency, and not for instance the number of nodes in a network path. Network latency can be measured using tools available on the web or simply the tried and trusted Ping tool available on any commercial IT system that communicates via the Internet. It’s easy to see how the geographical location of different servers can have an impact on the latency of a connection. From that, it also becomes obvious why some companies, like stockbrokers, insist on datacentre facilities that are no more than a stone’s throw from where they do business.
The faster a response time an organisation needs, the bigger the potential conflict with the remote back-up data centre. Conventional advice about a failover site over 600 miles distant from the usual operational site may need to be reappraised in this light. This kind of distance can also have an impact on off-site backups if the network link goes down when a disaster recovery situation occurs. In this case, the data that was in transit may be lost, leading to a difference between the data in the original system just before interruption, and the data recorded on the backup system. The only way to really find out if a cloud/WAN backup solution will work for you is to test it before anything fails.