Use Asigra Cloud Backup on IBM SmartCloud Enterprise

In this article, the authors recommend a "agentless backup" technology that provides better cloud-oriented data recovery methods than traditional agent-based backups. The author of this article will lead you through various backup options, and then learn about a real agentless cloud recovery system that they developed, which runs in ibm®http://www.aliyun.com/zixun/aggregation/13696.html "> SmartCloud Enterprise.

As the cloud is used faster, and enterprise and production-level applications are hosted in the cloud, administrators need to face more challenges because traditional, agent-based backup solutions are already unable to meet the needs of the cloud environment. Agentless backup and recovery technologies can provide some advantages for traditional methods to help simplify and accelerate data recovery.

This article discusses the agentless backup and recovery approach and how it works in the cloud.

Why do I choose agentless Backup and Recovery

The IT world is changing: cloud computing backup and recovery is no exception. Large applications and data centers typically use traditional backup methods, as well as early drivers of cloud development, and data protection patterns designed primarily for Web and consumer applications have failed to meet the needs of enterprise and production applications running in the cloud.

Agentless backup and recovery technologies are typically designed to be started from scratch in a cloud environment to provide a low touch (Low-touch), resource-intensive, flexible data recovery, manageable solution. For cloud users, this means less effort and lower costs (mostly through automation) and provides faster recovery rates.

Now let's look at the evolution of backup technologies before the advent of cloud technology.

How backup evolves and applies to the cloud

Let's look at two more traditional web-based backup types:

Traditional agent-based Backup

Agents used to scan and collect data from the operating system, file systems, and applications. The agent can back up the full dataset, incremental file changes, or incremental block changes.

Recently, the agent function has been further developed to include features such as replication, compression, and encryption. All of these features require a certain amount of system resources. Figure 1 illustrates a typical agent-based backup system.

Figure 1. Typical agent-based backup software deployment

Application proxies for structured database backups (RDBMS, e-mail, ERP, and so on) are usually a special agent or code attached to the System agent. Each agent is unique and cannot be shared with other systems or applications.

The agent must be installed on all devices. Most traditional backup and data protection software does not revoke the agent, and each device requires the administrator to manually install the agent. The same applies to patches, fix packs, and upgrades.

Many backup agents also require that the application system be restarted. This requires that all implementations, upgrades, patches, and fix packs be scheduled and quickly switched. If you have a large number of agents, the process will be cumbersome and will often cause backup administrators to postpone upgrades or patches to the scheduled maintenance period.

When server virtualization has just become popular, backups are implemented on virtual machines (VMS) in the same way as they do on physical machines. This reduces the centralization and consolidation of VMS because each agent consumes resources; more VMS means more proxy resources.

backups also cause I/O contention because each agent attempts to backup at the same time, and contention is usually caused by the fact that the agents are not aware that contention is the same resource. Contention results in reduced backup performance and delays in the backup cycle.

Virtualization Image Backup

The virtual machine hypervisor vendor discovers that the agent is expensive, so a different approach is developed to perform virtual machine backups. Most virtual machine managers today have some form of API that allows backups to take advantage of snapshots owned by the hypervisor, so they share a portion of the load for the backup process and do not use proxies.

Through the hypervisor API, the backup software media system sends a snapshot of a particular VM or a series of VMS (more specifically, the virtual disks associated with the VM). Virtualized snapshots allow complete VM rollback recovery, which is often mistakenly referred to as bare metal recovery (BMR). Considering the amount of data involved, BMR can be a fairly long process; long-term user surveys show that more than 90% of recoveries and restores are usually done on a file, not the entire machine. However, when a VM rollback is required, BMR is a quick and easy way to implement it.

There are some local backup products on the market that enable file-level recovery in virtualized image backups, but they are often specific to virtualized platforms and management programs. In cases where virtual machine hypervisor snapshots or image captures require a cloud server to be offline (planned downtime), more VM resources are needed to recover data, or to increase storage capacity to capture multiple point-in-time or clone image snapshots. Figure 2 shows a virtualized image backup and snapshot settings.

Figure 2. Virtualization image backups and snapshots

Let's take a look at agentless backup and recovery.