Eight Considerations for Evaluating Disk-Based Backup Solutions

This article has been written by Bill Andrews, president and CEO of ExaGrid Systems.

As more IT organizations move from tape to disk-based backup with deduplication, since different architectural approaches are available in the market, it’s important for IT professionals to understand that not all disk-based backup systems are the same. The following eight considerations may help you frame your evaluation process and make the best decision for your organization.

1. Backup Performance
When considering backup performance, you will want to understand whether the implementation slows the writing to disk by performing compute-intensive processes on the way to disk (inline) or writes directly to disk for fastest performance and then deduplicates after the backup is complete (post-process).

Post-process deduplication allows backups to write directly to disk at disk speeds, producing faster backups and shorter backup windows. The rationale is to defer the compute-intensive process until after the backup has landed, so as to not affect the time needed to perform the backup.

Another approach is inline deduplication, which deduplicates data on the fly before it lands on disk. Because inline deduplication can cause a bottleneck at the point where data is streaming into the backup appliance, it can result in slower performance and longer backup windows. Proponents of inline deduplication argue the approach requires less disk and is therefore less expensive. Because inline deduplication relies on faster, more expensive processors and more memory to avoid being prohibitively slow, however, cost differences in the amount of disk used are overcome by the need for expensive processors and memory.

2. Restore Performance
Restore speeds are another important consideration, as some approaches keep a full backup ready to be restored while others keep deduplicated data that must be re-assembled to restore data.

Full system restores are the most important restores, as hundreds to thousands of employees at a time can be down when a full system is down. Nearly all disk-based backup appliances and backup software-based deduplication implementations use inline deduplication; that method, however, requires a given backup to be rehydrated, or reassembled, from its deduplicated state to be restored. This approach takes time-and time is typically not a luxury when a full system is down!

A post-process approach, because it allows backups to land to disk before deduplication, is able to keep the backup on disk in its complete form. As you proceed with nightly and weekly backups over time, the appliance maintains a complete copy of your most recent backup on disk in its complete form so that it can be rapidly restored if needed. This approach saves time and productivity in the event of a full system restore, and it is quite useful with virtual server backups using server virtualization. Finally, because a post-process approach keeps your most recent backup in its complete form, this same backup can be used to quickly generate a tape copy. With an inline deduplication approach, a tape copy requires the backup to be reassambled (rehydrated) before being sent to tape, resulting in more time until data is fully copied to tape and protected offsite.

3. Deduplication Approach
When evaluating a vendor’s deduplication approach, the first, most basic aspect of deduplication to consider is how well it reduces data. But beyond that, there are factors such as support for a variety of backup applications and ease of scaling as a customer’s data grows.

One common method of deduplication is block-level deduplication. This method takes a block of bytes and then looks for other blocks that match, storing only the unique blocks. The key to block-level deduplication is the size of the block. Smaller block sizes (e.g., around 8 KB) can be easily matched and will result in higher deduplication rates than larger block sizes (e.g., 64 KB). Block-level deduplication, when used with smaller block sizes, achieves excellent data reduction. This method, because it is generic in nature, also lends itself to supporting a variety of different applications. The problem with block-level deduplication, however, is its lack of scalability. Because block-level deduplication stores and matches unique blocks, a hash table is required to manage all backup data stored. The smaller the block size, the larger the needed hash table, such that for 8 KB size blocks, one billion entries are needed to deal with just 10 TB of data! This situation forces an appliance architecture consisting of a controller unit with multiple disk shelves, whose adverse consequences for scalability are discussed below.

With the alternative approach, called zone-level deduplication, backup jobs are broken into large 50 MB to 100 MB segments (instead of blocks). These segments are then broken down into zones, or areas, and the deduplication algorithm looks for the changed bytes from one backup to the next. Like block-level deduplication, zone-level deduplication achieves excellent data reduction and lends itself to supporting a variety of applications. Unlike block-level deduplication, the tracking tables required for zone-level deduplication are smaller and can be easily copied across appliances. This allows for a scalable grid-based architecture.

4. Scalability
When examining how well a given disk backup with deduplication solution scales as the amount of backup data grows, consider both the ability to scale while maintaining the backup window and also the ease with which the system can be upgraded when additional horsepower is needed so that IT doesn’t have to deal with costly ‘forklift upgrades.’

There are two basic architectural alternatives: a controller/disk shelf configuration and a grid-based system. With the controller-shelf model, the processing power, memory and bandwidth are contained in the controller. Some disk may be contained in the controller as well, but when data grows and the system must expand, additional disk shelves are added to the controller. This implies a static amount of processing power, memory and bandwidth for a given system even as the amount of data grows, resulting in one or both of the following negative effects: (i) with a constant level of processing power, memory and bandwidth as data grows, the backup starts to take longer and longer; (ii) the amount of processing power, memory and bandwidth must be over-provisioned, when the system is first acquired, to allow for future data growth, resulting in a more expensive system at the time of purchase. In addition, each controller can only handle a certain amount of disk. When the customer’s data increases beyond that level, the entire system must be swapped out for a new one in a costly ‘fork lift’ upgrade.

Instead, use a grid-based configuration, where each appliance contains processing power, memory, bandwidth and disk. When the system needs to expand, additional appliance nodes are attached to the grid, bringing with them additional processing power, memory and bandwidth, as well as disk. This configuration allows the system to maintain all aspects of performance as the amount of data grows, and you are only paying for the amount of capacity you need as you grow, rather than paying for everything up-front. A grid-based approach avoids costly forklift upgrades of controller / disk shelf configurations.

In addition to maintaining backup performance as data grows and allowing you to seamlessly upgrade to larger systems, grid-based configurations automatically load-balance available capacity in the grid, maintaining a virtual pool of storage shared across the grid. All systems can be managed using a single user interface that can access all systems on the grid. This provides a simple, single-dashboard view to give you a quick view of job, deduplication and replication statuses for any system in the grid.

5. Support for Heterogeneous Environments
Since customer environments are comprised of many backup approaches, applications and utilities, consideration should be given to how different disk-based backup approaches support heterogeneous environments. Customers may have any number of backups occurring in their environment, including traditional backup applications, specialized VMware backup utilities (e.g., Veeam and Quest/VRanger), direct-to-disk SQL dumps or Oracle RMAN backups, and specific UNIX utilities (e.g., UNIX TAR). Can the disk backup approach take in data from multiple backup applications, utilities and specialty VMware utilities, or can it only take in data from its own agents?

By definition, backup application software solutions with integrated deduplication only support their own application with their own backup server software and backup client agents. These solutions are unable to support backup data from other backup applications or utilities. Disk-based backup appliances with data deduplication, however, are able to support backup data from multiple sources. Performing dedupe in the backup software limits the ability to have data from all sources stored and deduplicated in a single target device. Unless 100% of your backup data passes through that particular backup application, a purpose-built disk-based backup appliance is the best choice to meet the requirements of your entire environment.

6. Support for Backup Application Features Such as GRT and OST
Another area to consider when looking at disk-based backup solutions is how well a particular solution supports advanced backup application features such as GRT (Granular Level Restore) and OST (Symantec Open Storage).

Some solutions do not integrate well with these features. Poorly-implemented GRT solutions may take hours to restore an individual e-mail or may not work at all. Symantec’s Open Storage is another popular feature that allows for more integrated offsite data protection (e.g., updating the backup catalog for offsite data tracking and restore), and it is important to check whether these features are supported if you are using this with Symantec NetBackup or Backup Exec.

7. Offsite Data Protection
If you are considering a disk-based offsite data protection system that replicates data from the primary site disk backup system to the second site system, you need to consider deduplication rate, bandwidth required, and speed and ease of restoring from offsite if something happens to the primary site.

First, what is the deduplication rate? Deduplication rate is the determining factor in the amount of data reduced and disk required. But deduplication rate also affects the amount of bandwidth needed to maintain a second site for a given backup window, since only the changed data is sent over a WAN to an offsite system. The poorer the deduplication rate, the more data must be sent to maintain the offsite backup and the more bandwidth is required for a given backup window. Deduplication rates can vary greatly, particularly when looking at backup application software deduplication.

Second, does the offsite system keep only deduplicated data or some form of already rehydrated data to offer quick disaster recovery restores? Any system that does inline deduplication only stores the deduplicated data and results in slower disaster recovery (DR) times. Find an appliance that performs replication to an offsite appliance and maintains the most recent backup in its complete form on the offsite system as well. The result is data that’s ready to quickly restore from either the local or the remote system.

Third, can data from the offsite system be used to restore any lost or corrupted data on the primary site? ExaGrid owns the patent for this technology such that if anything happened to any of the backup data at the primary site, the offsite system can be used to restore / replace the lost or corrupted data. This creates an added level of safety.

8. Total Cost of Ownership
Cost needs to be examined both upfront and over time. You want a lower price upfront, but you don’t want to have to repurchase any part of the system later.

On the surface, it often appears that backup application software deduplication would be fairly low cost. After all, you just need to turn on deduplication from within the backup server and you’re good to go, right? Not exactly. It’s important to keep in mind that using backup application software deduplication typically requires greater resources on the backup server-more processing power, memory and disk.

How do you determine how much of each component is needed to optimally work in your backup environment? What do you do as the amount of data you’re backing up grows? Answering these questions likely means additional costs in professional services. When you get to the bottom line, additional costs of these items typically exceeds what you pay for an appliance. So whether you’re comparing appliance or non-appliance solutions, look for the most cost-effective disk-based backup solution upfront and over time.

With the movement from tape-based to disk-based backup well underway and with several different approaches available today, it’s important to understand that disk backup with deduplication does not begin and end with deduplication. Take into account all eight of these factors when evaluating these systems to make the best decision for your organization.