Breaking the traditional solution to the new strategy of cloud computing disaster recovery

For disaster recovery, the concept of most people remains in the traditional offline disaster recovery. Now, with the development of cloud computing disaster recovery, many people are still confused about the concepts of traditional off-line disaster recovery and disaster recovery in cloud computing. Figuring out the difference and recovery requirements is the first step in sustaining a fixed disaster recovery strategy. Let's talk about cloud computing disaster recovery as a new technology and traditional disaster recovery differences.

Whether or not a disaster recovery is implemented in cloud computing, a successful disaster recovery plan contains the same elements:

1. Plan for Disaster

2. Record your plans

3. Test your backup files

4. Fixing any existing problems

5. Test again to make sure you have solved all the problems

6. Repeat the above steps regularly

The final step of "repetition" is the key to keeping the disaster from happening.

Disaster recovery technology has restored critical services from tape-based recovery technology and leased data center space to instant switching from a failed site to a virtual fail-back site. There are differences in how cloud disaster recovery vendors manage offline components, or how they implement cloud computing for an IT environment. Some may say that they believe disaster recovery is possible through cloud computing, while others do not.

Most vendors plug the device into the customer's IT infrastructure to get information and store it locally, and then copy it to the cloud. In most cases, the fact that the data does not exist in the cloud is actually transferred to the vendor's datacenter. This approach is similar to a traditional backup solution. The localization and high speed of this approach allows you to recover data from a device that has a non catastrophic data loss event. Offline data is back online via the Internet in the event of an actual disaster that will be protected from the site offline.

Once you understand the location of the data in a disaster event, it is the primary task of the IT team and the business manager to identify the recovery point object (RPO) and Recovery time object (RTO) that meet the company's needs. While many companies may require "always online, never drop" operations, but the actual budget and disaster probability are always reminding them that their demand is completely unnecessary. The most important thing is to work out a realistic disaster recovery goal.

For companies that rely on technology to create value, a 0 rpo/0 RTO guideline is equally valid; Paying for this disaster recovery plan is part of the cost of this business. And for other companies, computer network insurance and high RTO is enough. The greater the size of the business, the greater the complexity of the combination, the higher the complexity of RPO and RTO requirements (from 0/0-8 hours/24 hours, and even more complex 24/24). ）

Disaster recovery in cloud computing options

Virtualization is based on the cloud computing disaster recovery technology. After this process, it becomes a real cloud computing service. Major vendors such as IBM, Iron Kings, CommVault, stencils continuous and appassure provide cloud-based business-level disaster recovery products designed to integrate business standards and processes, Reporting activities and enabling IT teams and business units to understand product status.

The virtual machine (VM) that you have created to restore your IT environment is no different from the virtual machines you use to use physical machines in your dedicated facilities. The only difference is that these VMs are hosted in a third-party facility and basically run from the cloud. When the lights on the protected facility are off and the disaster protocol is invoked, those virtual machines replace the physical machines and virtual machines--taking over the production machine.

The method is SLA friendly. The ability to use virtual machines that store disaster recovery data and applications in a manageable way. This will ensure that you manage system capabilities and costs. If a business unit is based on a web order Processing system with RTO of four hours and a common but unimportant customer order history archiving system RTO is 48 hours, then the service level agreement will require the disaster recovery product to immediately resume the web-based order Processing system and thereafter restore the history archive system. This mechanism preserves the two purposes of recovery services: it lowers the costs associated with any time and gives busy IT staff time to ensure that more critical SLAs are met first.

This phased recovery plan also allows for time to eliminate disasters. Of course, the recovery plan must also be taken into account in case of complete destruction, but in most cases the disaster refers to a simple failure. Once the expiration command is issued and the associated facility is selected, you may not need to run a disaster recovery protocol for an unimportant SLA.