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 when comparing ExaGrid vs. other appliances (e.g. EMC Data Domain). The main difference is that ExaGrid’s system offers a GRID architecture with full server and post-process deduplication (which is faster and more scaleable), while other appliances use a front-end server architecture with disk shelves and inline deduplication (which is not as fast and requires costly forklift upgrades to scale).
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|
Writes to the disk at disk speed to ensure completion of the backups quickly.
Performs compute-intensive process between the backup server and disk.
|Backup windows do not expand as data grows||Strong — add full appliances
As data grows, full servers are added, each with their own processor, memory, bandwidth and disk. This maintains consistently fast backup performance and a fixed length backup window as data increases. For example, 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.
|Weak — can only add disk
Only disk shelves are added as data grows, This means you start with a shorter backup window, but as data grows, the backup window expands because you are not adding more deduplication processing resources. For example, when your backup grows from 10TB to 20TB, with twice as much data but the same processor and memory, the backup window expands. Eventually, the backup window expands to a point where you must replace the front-end server with a more powerful server.
|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.
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.
|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.
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.