Today, the theme of "Towards disaster recovery beyond backup" is the disaster recovery method that can protect the server environment that is changing into various environments at present and the quest "Rapid Recovery" which is thought to be optimized for it. I will explain about it.
First, let's look at the background of a disaster recovery solution.
The current server environment has undergone many changes, and the traditional on-premises physical server environment has the problem that the more complex the mission-critical server is, the more complex the system is.
It also requires management of mixed virtual environments with physical server environments, and also requires protection methods for servers in the cloud for some external services.
In addition, there are increasing disruption points such as interruption of system operation due to infection with Ransomware through security holes in various server environments, natural disasters caused by sudden changes in natural environment, human resources accidents, and increasingly obsolete hardware faults.
In order to cope with these various system environments and the increasing number of disaster points, a methodology for increasing availability is essential.
There are three main methodologies for increasing system availability.
First, the first methodology is backup and recovery. Backup and Restore is a way of copying the original data to another location and recovering the original with a copy in the event of a failure. It is the most common and common methodology.
The second is HA. HA is a solution or solution that maintains service continuity, also known as a high availability solution. It configures two operational servers in Active and Stand By formats and performs real-time replication of data in order to resume service within a few minutes after a failure. And the Active server will resume service to stand-by when it fails.
The third is disaster recovery (DR). Disaster recovery is a method of resuming service by recovering a system that is down when a failure occurs.
All three are technologies that increase availability, but the most comprehensive approach is disaster recovery. This is because it aims at restoring the system, that is, the OS application data, and restarting the service under any circumstances, so the entire IDC center as well as some servers can be targeted.
Let's look more closely at the disaster recovery (DR) methodology.
Among the high availability methodologies discussed earlier, the concepts of backup and DR, except HA, are nearly identical. Backup is a process of recovering data backed up in the event of a disaster, and disaster recovery (DR) is the act of resuming service by recovering the system to a state before loss.
Both methods have the same meaning as disaster recovery, but DR has a more comprehensive concept as I mentioned earlier. Backup is targeted at some data or system in the local area, but DR is aimed at resuming services under any circumstances targeting the entire computing environment.
However, these DR related technologies have various problems. The complexity of the implementation for long-distance replication, the need to configure the same system when configuring the DR site, the added cost of S / W licenses and the excessive cost for this configuration is also a problem.
In such a case, the DR center must be operated efficiently. In reality, the suspicion that it is possible to resume service through normal disaster recovery function in the event of a failure, such as a fire in the IDC center of Samsung SDS, is one of the tasks to be solved. Samsung is also suspicious of restarting services.
So, is there any effective DR solution? I think the simplest way to solve this problem is to make a cost effective, easy, fast and accurate system (OS) image backup.
I wonder why you think an appropriate solution for disaster recovery is an image backup solution. To understand that part, let's first look at the comparison and misunderstanding of the two backup methods.
First, the image backup solution has the advantage of being simple to operate and easy to operate. Data can be backed up and recovered in full, so it has the advantage of resuming fast service in the worst case. On the other hand, data backup is difficult to operate due to various operating methods, and it is difficult to recover the entire system, which can lead to a long downtime in case of a total system failure.
However, the data backup solution supports a wide range of operating systems including Windows, Linux and Unix, and a wide variety of DB applications, enabling extensive data protection and restoration. In addition, it is possible to restore data object unit, that is, DB table unit, at restoration, so that quick restoration is possible in case of some data loss.
Image backup, on the other hand, is not able to support Unix OS. However, the ability to back up and restore your image backup solution can be a great benefit for disaster recovery.
In addition, we will talk about recognition errors for image backup solutions.
What I hear most is that image backup solutions can not recover data units. But this is not true. For years, image backup solutions include not only system restoration, but also the ability to restore files and VM-based mail units.
The second misconception is that image backup solutions do not guarantee consistency with DB backups and can not be restored. In the case of image backup in Windows environment, we basically backup the system using backup API provided by Microsoft called Volume Shadow Copy Service (VSS) which is included in Windows. VSS is a technology that ensures that Microsoft will recover when backing up their OS and applications. In addition, the image backup solution includes features to ensure recovery through MS-SQL and Oracle backup consistency checks.
Based on these two functions, recovery point can be restored to yesterday's date, system and DB can be restored 100% and service can be restarted.
The third misconception is that the image backup solution is weak enough to support backup of virtualized environments. However, before the flood, the image backup solution supports backups for Hyper-V and VMware environments, and supports VM-based backup and file-based recovery.
The last misconception is that image backup is not suitable for disaster recovery environments because of the lack of data redundancy and remote replication in data backup solutions.
This image backup solution already includes deduplication technology and deduplication storage function, and backup data replication to a remote site with WAN optimization replication function like AIR function included in Net backup, which is a representative data backup solution, It is easily possible.
There are a number of image backup solutions available today. Some products include only some of the features described above, and some have full features.
Our company tests various related solutions, distributes and operates them in real environment, and based on their experiences, we think that Quest's "Rapid Recovery" is the most optimized solution for such disaster recovery scenarios . This product is already proven to be effective in a variety of disaster recovery environments, has a reputation for its award winning solutions, and has proven its reliability in the disaster recovery area.
This product is Windows and Linux system backup and DR build solution. It provides basic system backup and recovery as well as remote data replication for disaster recovery, archive function for backup dissemination and integrated web management console to manage anytime and anywhere I will.
By default, backups use image snapshot backup techniques to minimize storage space and backup I / O, especially after the initial one full backup, back up to Forever Incremental to maximize backup efficiency , Very fast backups are possible.
The original data is deduplicated and compressed and stored on backup storage. You can also maximize the efficiency of backup storage by using global deduplication, which is also deduplicated with data from other servers stored in the backup store.
And backup image backup data can be restored under any circumstances.
In addition to restoring the system to the original server, it can be recovered to a completely different hardware server, recovered to a virtual environment and further to a cloud environment. These recovery scenarios enable recovery scenarios where the source server can resume service whenever and wherever it fails.
In addition, the backup data is checked every night by automatic consistency check to see if the data actually backed up is normal and can be recovered. This automated repair consistency check enables customers to demonstrate a more stable recovery environment.
The backup function can be used to prevent backup data from being lost due to backup server failure. Archiving is the recommended feature because it allows you to copy and store backup data on a remote NAS or cloud, allowing you to restore the original server system through the backup data in the archive store in the event of a primary backup failure.
Please note the following "Virtual Standby" drill function. This is one of the most valuable features of Rapid Recovery, and it is very effective in building a DR site.
The Virtual Standby function is a function to create a VM by automatically P2Ving the backed up data into the hypervisor virtual environment, and the VM is continuously updated through incremental P2V automatically at the time of backup. In this situation, when the source server fails, the VM that is being Stand By is powered up and the service is resumed immediately, which can dramatically shorten the Recovery Time Objective (RTO).
This environment supports the MS Azure cloud environment as well as VMware and Hyper-V, enabling flexible DR site deployment.
As mentioned above, the Virtual Standby function enables immediate service restart of the failed server. However, when a disaster-related disaster occurs at the headquarters or the entire IDC, recovery is virtually impossible. To prepare for any of these disasters, it is common for financial institutions and large companies to establish DR sites in remote locations.
The biggest problem when creating a remote DR site is replicating large original backup data to a remote site. This problem can be solved by the remote replication function in Rapid Recovery. First, the data is deduplicated and stored in the backup store on the backup server. Full replication is required at the initial one-time replication, so configure the replication server on the same LAN as the backup server and perform full replication. Subsequent replicas of the incremental backups are deduplicated and compressed so that replication on the WAN can be done very quickly.
The combination of the Virtual Standby feature and the WAN replication feature mentioned above makes cost effective and very fast remote DR configuration possible.
In other words, deduplication from the production site to the backup server. After backup, the replication to the remote DR site through compression and deduplication on the WAN, and then the automatic P2V implementation into the hypervisor virtual environment on the DR site after replication. This complex process is very simple to configure as a series of operations in Rapid Recovery, and it is possible to build a virtualization DR center that can instantly restart service through VM when a failure occurs.
We have experience building DR sites overseas with Virtual Standby and WAN optimized replication.
In short, Rapid Recovery is a disaster recovery solution that offers a quick and easy backup methodology and a variety of recovery methodologies to create a very easy DR environment.
I would like to ask you again about the necessity of the disaster recovery solution mentioned in the introduction section, and I would like you to have an effective disaster recovery plan even if it is not necessarily the product. He suffered from reading a long article.
0 Comments
댓글 쓰기