Disaster recovery (DR) planning isn't just a matter of storage. It's about identifying the data that your client requires for daily operations, and then duplicating that data across the wide area network (WAN) in a timely and cost-effective manner - striking a balance between WAN speed and connectivity costs. However, deciding just what data needs to be handled, how much WAN bandwidth is needed to accomplish that replication and how to maintain security across remote sites can be difficult for even experienced solution providers. This article details WAN bandwidth factors, redundant connectivity concepts and the use of other technologies, like VPNs and virtualisation, in disaster recovery.

WAN bandwidth requirement issues

In simplest terms, the WAN bandwidth needed for disaster recovery is the amount of data that needs to be moved divided by the time available to move it. For example, if your client must move 1,000 MB of data in 10 seconds, they would theoretically need 100 MBps (about 800 Mbps) of bandwidth. Consequently, more bandwidth is needed to accommodate greater data volumes or smaller timeframes. The trick for solution providers is to establish both numbers accurately.

File sizes are fairly easy to determine through an assessment of the client's business applications, but remember that not all changing data is equally important. Different data types can be protected in different ways to reduce data loads and corresponding bandwidth needs. For example, a client may accumulate 100 MB of new or changed data each day, but if 75 MB of that consists of non-critical data that doesn't really require DR protection, only concern yourself with the remaining 25 MB of "important" data. Non-critical data that is not protected by the DR site can still be backed up for later recovery.

Similarly, it is often possible to split DR protection by data type. Suppose that 25 MB of important business data includes 10 MB of transactional data and another 15 MB of email, documents and other business communication. A solution provider can architect a DR plan that supports the transactional data with real-time synchronous replication, while protecting the remaining data with asynchronous coverage over 30 to 60 minutes or some other appropriate timeframe.

Data volumes can be greatly affected by data reduction technologies like data deduplication - removing redundant files or blocks from data. For example, a client's mission-critical database may change by 20 MB each hour, but data reduction techniques can drop the effective volume to 8-10 MB each hour. WAN optimisation appliances can also be deployed to apply compression for smaller file sizes and TCP/IP traffic assistance (e.g., fewer handshakes and jumbo packets) for lower latency and better bandwidth utilisation. Solution providers may need to monitor or track application activity on the client's network to gauge the actual data types and volumes that require protection.

Next is the issue of time. "If you want 100% data replicated 24/7, then you need high bandwidth," said Rand Morimoto, president of Convergent Computing, a network solution provider. "But if you are okay with a two- to four-hour delay or even one-day delay on DR, then you can get away with really cheap and simple WAN bandwidth."

Real-time synchronous data replication will demand bandwidth that matches the peak file change activity. For example, if data within the client's organisation is changing at 1 MB each second during a normal business day, expect to provide at least 8 Mbps of bandwidth in order to move those changes in real-time. Asynchronous data replication needs can dramatically reduce these demands by spreading out data changes over a longer period.