It takes 2 months (60 DAYS) to move 1 terabyte of data over a T1.
Don't have that much data ? It takes about a month (30 DAYS) to move 500 gigabytes. Only have 100 gigabytes - you should be able to pull it back in about a week (6 DAYS). Now this is for an uncompressed data stream but as we all know the ratio of multi media files (which are already at maximum compression) is growing rapidly so your mileage will vary. Point being if you are hoping that compression or de-duplication can fix it, well, that is a discussion for a later entry.
Don't have that much data ? It takes about a month (30 DAYS) to move 500 gigabytes. Only have 100 gigabytes - you should be able to pull it back in about a week (6 DAYS). Now this is for an uncompressed data stream but as we all know the ratio of multi media files (which are already at maximum compression) is growing rapidly so your mileage will vary. Point being if you are hoping that compression or de-duplication can fix it, well, that is a discussion for a later entry.
In any case, pretty much every Small to Medium Business (SMB) has eclipsed the 100 gigabyte mark in aggregate and should be mindful of this simple math. Unlike all of the dedicated resources that we can swap out to go faster or store more, bandwidth remains a shared resource and critically, is only as fast as it's slowest link. Someday we will all have unlimited fibre to the touchscreens on our refrigerators... someday.
In the meantime, SMBs have two specific needs; the first is online backup to an authoritative READ ONLY HISTORICAL repository to serve as a backstop for Disaster Recovery (and e-discovery) and the second is an ACTIVE replica of the most RECENT version for Business Continuity. The phrase "kill two birds with one stone" is a good one for the opportunity presented with cloud computing.
Most of us can agree on the need for an authoritative offsite repository to make sure that our data is safe no matter what happens on the ground. The reasons are easy to tick off, starting with physical threats and ending with deliberate malicious intent. More often than not however, this "Disaster Recovery" (DR) solution is passive and idles in background collecting data over time until you pull it back - usually when a problem occurs.
But what if that repository were dynamic ? What if it satisfied not only the natural role of DR but could also "push" the critical data you might need for "Business Continuity" (BC) to one (or more) alternate platforms in waiting. That is what the "pay forward" in the title refers to; maintaining an offsite or online parallel working environment that is time shifted, or lagging the primary production environment, by a reasonable delta. There are a lot of solutions that achieve this goal using proprietary ecosystems and dedicated bandwidth but those can be expensive - and that is one of the biggest reasons why you might want to factor cloud computing into your solution.
Dramatically simplifying this concept of time shifting (which will be revisited in greater detail in later posts), we simply talk about real time production and a "latest snapshot" from delta changes. Let's assume that your production data is constantly in motion during it's "day shift" from, say 9 to 5, and you maintain a local near Continuous Data Protection (CDP) disk to disk capability with snapshots every 15 minutes to an hour. At 5:00 PM, most everybody powers off their systems (to conserve energy) and goes home.
This however is your data's "night shift" and the opportune time to post through the latest delta changes for the entire day to your DR repository in the clouds which, in this hyper simplified explanation will continue until around 1:00 AM.
After which your data's "graveyard shift" begins and the previous day's delta changes are relayed again to your terrestrial offsite or cloud computing online BC failover facilities. Critically, this data transmission is sequenced so that the most important data sets go first.
Of course the order is open to interpretation; ie. you go offsite first and then online depending on your specific needs. In addition, the solution you choose should be able to transmit on multiple threads simultaneously and give you the option to pick and choose subsets of your data for retransmission much as we do with WarLock DR+.
In summary, the cloud is correctly isolated from your organization's terrestrial exposure and well suited to functioning in the dual role of authoritative repository and dynamic hub for paying forward delta changes in anticipation of failover.
Posts
