Understand your Backup Technology – Agent vs Agentless Backup
To be Virtual or not to be Virtual?
The evolution of technology from standalone physical servers to shared resource virtualization, creating resource elasticity and so have other technologies evolved to join the virtualization revolution. Many companies have completed a 100% migration to virtual, some are still in this process.
One key technology that has had to keep up is backup and disaster recovery, simply because whether your files server was physical then and virtual now it is the same data and of the same importance to the business, A lot of companies have had to change backup vendors or purchase a different package or even add-on to facilitate the move possibly even keep certain older licensing behind for legacy system that have not yet been virtualized.
Arcserve has been very flexible in this aspect regarding the migration to virtual, physical server licenses where just carried over to physical hypervisor hosts and restore features such as virtual standby, Instant VM restore and full system high availability allowed for the migration & conversion process to be automated with ZERO data loss and in some cases zero downtime. This has added ease to the migration and sped up the virtual revolution globally.
After the Migration (To Be Virtual)
Backup technologies can offer an additional method of backup, a method that would not install into or alter the production environment any way leaving it hands free, this is the agentless method. The agentless method allows for backup software to speak to the hypervisor vendor API and request actions to be performed on the virtual machines. In the case of backup it would look like below steps on a high level.
- Find available servers for backup
- Create a temporary snapshot on target virtual disks
- Extract backup data from target virtual disks
- Transfer backup data to destination
- Delete temporary snapshot
This allows for quicker deployments and more efficient backups, however there are concerns.
First concern taking a temporary snapshot of a virtual disk without knowing what I/O operations are completing within the virtual disk at that point in time could result in capturing a partial operations resulting in inconsistency of application data when it comes time to restore. Further API integration such as the use of VIX library for VMware and host integration tools for Hyper V allows for backup software to access guest operating system files and services within the Virtual Target Disks. This creates application aware backups on the agentless process.
A second concern that creating snapshots and holding snapshots can increase used space on the production shared volumes & add a degrade of I/O performance to target virtual machine disk during online agentless backups. When the snapshot is created it the base virtual disk is in a frozen state and a secondary disk (The Snapshot) holds differential data of the base disk, this then bloats the size of the target VM storage usage on shared storage volumes , vendor KBs suggest 10 – 20 % storage increase on high transactional virtual machines while snapshot is present. If you are processing all virtual machines on a single shared storage concurrently you need to make sure that you have at least 10-20% free for storage to burst during backup.
The reason for the added I/O overhead during snapshot usage is that read access to guest OS files would need to read original base files and all differencing data since snapshot creation, the larger the snapshot the more data we can assume is needed to be read.
A third concern is that software snapshots don’t support certain devices so not all disk devices attached to a virtual machine will be captured for examples are, passing through physical disk devices from hypervisor host to the virtual machine, IscsI Mounts, RDM Raw Device mapping of LUN from a storage array and more… What happens in these cases is that a virtual machine has OS disk provisioned as a virtual disk but secondary storage device is directly to a physical array volume. An easy example here would be an application that has redundancy though multiple nodes however share the same data eg. SQL Cluster with shared storage for database.
In cases like these where Agentless is not a fit you need to revert to the traditional backup through an Agent.
Agent Based Backup
Agent based backup is the process of installing a software package from the vendor in the target system, this will communicate with the backup server and utilise target services and resources to perform and capture backup such as shadow copy service and VSS writers like SQL or Exchange writers for application backup. This using the target system resource to create the backup rather than impacting shared resources as on agentless cross shared virtual infrastructure. This can be a lengthier backup windows compared to agentless approach.
Using agents on virtual infrastructure within virtual machine guest Os would alleviate concerns mentioned above for specific platform or application requirements whilst still providing complete data protection.
Leave Physical (Not to be Virtual)
A lot of systems are left physical and for good reason. Servers that require physical monitoring or licensing via dongle USB key, systems or application servers that licensing is not compatible with virtual hardware, systems that the virtual infrastructure is dependent on, in cases domain controllers or networking systems.
These systems will still utilise agents for data protection rather than agentless in the fear of virtualising and creating in necessary downtime.
The Migration Magic Wand
With Arcserve, both agentless backups and agent based backups can be sent to the same backup server and data is compared and deduplicated cross technologies, further compressed and stored that is true global deduplication!
As mentioned earlier in the article, Arcserve has changed the virtualization landscape by offering a solution that followed its licensing during migration and facilitated the migration to virtualization.
The question whether or not to virtualise a specific system or application is a hard one and requires planning, testing, more testing and hopefully execution at some point. If we introduce Arcserve into this scenario because of Arcserve being hardware agnostic and hypervisor agnostic we can safely backup a physical system or application online, spin up an Instant VM of the physical server backed up onto the hypervisor of choice and test functionality and impact without down time and without hours or days of preparation once confirmed happy, system is functional we can run another backup repeat or avoid data loss through a Arcserve high availability agent . This would create a virtual instance on request with continuous replication to avoid any data loss.
A few days pass and we realise we have overlooked a specific detail and the system is not performing to business standard as virtualised. It can’t be fixed and we need to return to physical. We simply back up VM agentless or with an agent and run a bare metal recovery to the original hardware or newer. Even simpler, we can create a Arcserve HA BMR to allow us to fail back as a high availability process to the physical servers again.
Whether you want to virtualize or have virtualized or won’t virtualise, that is 100% your choice but choose a backup and disaster recovery vendor that can transition through those phases without having to repurchase and avoid multiple vendors to complete a single task or single solution.
I end with a Quote
One reason people resist change is because they focus on what they have to give up, instead of what they have to gain. – Rick Godwin
Download UDP: http://okt.to/eXmslE
Live on-line events for Arcserve UDP: All timezones: http://okt.to/RruMRZ
Arcserve UDP Live Demo: Every Friday, 10:00 GMT: Register: http://okt.to/fALlGx
Arcserve High Availability Live Webcast: Every Tuesday, 10:00 BST: Register: http://okt.to/mR4fEN
Unified Data Protection for Virtual & Physical Servers: Every Thursday, 12:00 CEST: Register: http://okt.to/bhHIT5