ExaGrid vs. Other Appliances 
Comparing GRID with Full Server Architecture vs Front-End Server/Disk Shelf Architecture for Deduplication
When organizations are choosing a disk-based backup appliance with deduplication, they invariably evaluate the differences in product architecture between ExaGrid and other appliances (e.g. Data Domain or Quantum). The main difference is that ExaGrid's system offers a GRID architecture with full servers and post-process deduplication (which is faster and more scalable) while other appliances use a front-end server architecture with disk shelves and inline deduplication (which is not as fast and does not scale as seamlessly).
Check out our chart below as we compare and contrast the differences between ExaGrid's GRID architecture with full servers using post-process deduplication vs other vendors' front-end server with disk shelves architecture using inline deduplication.
| GRID Architecture with Full Servers and Post-Process Deduplication | Front-End Servers with Disk Shelf Architecture and Inline Deduplication | |
| Fastest Backups |
Fastest Writes to the disk at disk speed to ensure completion of the backups quickly. |
Slower Performs compute-intensive process between the backup server and disk. |
| Backup windows do not expand as data grows |
Strong — add full appliances Backup jobs are broken into 50MB to 100MB segments and then compared to find the bytes that change. Due to the large size of the segments—thousands of them at 10TB—the tracking data can be copied across full servers each with their own processor, memory, bandwidth and disk. As a result, full appliances are added versus just disk. When you grow from 10TB to 20TB (twice the data) the processor, memory, bandwidth and disk all double which means you have twice the resources. This results in a backup window that stays the same length. |
Weak — can only add disk Uses roughly 8KB blocks, which produces a hash tracking table of a billion entries at just 10TB. Due to the size of the hash table and prohibitive cost of memory to store the entire hash table multiple times, the hash table needs to be kept in a front-end server—and therefore, only disk shelves are added as data grows. If your backup grows from 10TB to 20TB, only disk is added while the processor, memory and bandwidth stay the same. With twice as much data but the same processor and memory, as the data grows, the backup window expands. |
| No Forklift Upgrades; Cost Effective Scalability |
No Forklift Upgrades; Cost Effective to Scale Uses full servers. As data grows you add another server into a GRID architecture. Each server comes with processor, memory, bandwidth and disk. When your data goes from 10TB to 40TB, you simply keep adding more appliances and the system keeps growing. There are no forklift upgrade points and no future costs to consider. Just add as you grow. |
Forklift Upgrades; Costly to Scale Only disk is added as data grows, but at some point the front-end server can no longer keep up because the amount of disk you can add behind fixed processor, memory and bandwidth is limited. At some point the front-end server must be replaced with a server with faster processor and memory, which is a “forklift” upgrade. Some product lines have as many as five forklift upgrade points. Since the cost of the front-end can be as much as the price of the initial system, when you buy in and then hit a forklift upgrade point, you may have to spend about as much for the upgrade as what you originally spent. |
| Fastest Full System Restores |
Fastest Restores Keeps full copy of most recent backups and historical versions as byte-level deltas behind the most recent backup. Latest full copy is always ready to restore in complete form for fastest full system restores. |
Slower Restores Deduplicates data on the fly so all data on disk is deduplicated. When doing a full system restore— often time-sensitive—you have to wait for all of the data to be put back together (rehydrated). |
| Fastest Tape Copies |
Fastest Tape Copies Keeps a full copy, so when your Friday night backup is complete, the full backup is sitting on the disk waiting to be copied to tape. The tape copy job simply copies the full backup from disk to tape without any data rehydration time, resulting in fastest tape copies. |
Slow Tape Copies Deduplicates data on the fly so during the Friday night full backup, data is deduplicated on the way to disk. As soon as the Friday night full is complete and the offsite tape copy starts, the entire full backup needs to be put back together (rehydrated) which makes for slow tape copies. |
| Ease of Installation |
Plug-and-Play Appliance Simple to initially install. |
Plug-and-Play Appliance Simple to initially install. |
| Cost-Effective Up-Front Purchase |
Best Price for Best Scalability Performs the processing after the backups are complete. Therefore, the systems can utilize mass market Intel processors that are shipped in high quantity and therefore are inexpensive. This greatly reduces the cost of the system. These systems can be up to as much as 30% less than an inline/block system. |
Higher Price Due to the inline approach, this requires the most recent, high-performance CPU in order to keep up with backups. The premium processor and memory drives the cost of the system up. These systems are more expensive than post process/ byte. |
The Bottom Line on GRID Architecture with Full Servers
A GRID architecture with full servers using post-process deduplication offers the following advantages compared to a front-end server architecture with disk shelves using inline deduplication:
- Faster for backups and full system restores
- More scalable, with no backup window expansion as data grows
- No forklift upgrades as data grows with cost-effective scalability
- Faster for offsite tape copy
- Costs less up front and costs less over time .
|
Want to learn more about a GRID architecture vs front-end server for disk-based backup with deduplication? Schedule a presentation today to see the benefits of post-process, byte-level deduplication. |



