http://ctistrategy.com/2009/04/10/deduplication-capacity/?utm_source=rss&utm_medium=rss&utm_campaign=deduplication-capacity CTI Strategy Blog Fri, 26 Mar 2010 22:05:17 +0000 hourly 1 http://wordpress.org/?v=3.2.1 http://ctistrategy.com/2009/04/10/deduplication-capacity/comment-page-1/#comment-855 Chris Curley Fri, 10 Apr 2009 17:29:53 +0000 http://ctistrategy.com/?p=288#comment-855 Interesting thoughts. My response is specific to using dedupe for backup only. This is why ExaGrid really thought through "backup" and architected a product from the ground up that really "makes backup better". It makes a whole lot of sense to land your backups on disk...at the speed of disk...thus using a post-processing approach. This shrinks the backup window and keeps peformance high. Inline dedupe slows things down. Then the most recent backup is kept in full, simply compressed so that it is ready for a rapid restore without "re-hydrating". When the next backup lands, it is compared to the previous backup and only the bytes that have changed are kept. Combine this with a GRID architecture that brings not only additional capacity into a virtualized single pool of storage, but all the necessary processor, memory and bandwidth...so that as you data grows your performance stays the same. If you just add capacity as another "shelf", as you point out, you are sending more data throught the same processor head and slowing things down further. This is a very "purpose-built" approach to disk backup with deduplication. I encourage you to learn more about ExaGrid. www.exagrid.com Interesting thoughts. My response is specific to using dedupe for backup only. This is why ExaGrid really thought through “backup” and architected a product from the ground up that really “makes backup better”. It makes a whole lot of sense to land your backups on disk…at the speed of disk…thus using a post-processing approach. This shrinks the backup window and keeps peformance high. Inline dedupe slows things down. Then the most recent backup is kept in full, simply compressed so that it is ready for a rapid restore without “re-hydrating”. When the next backup lands, it is compared to the previous backup and only the bytes that have changed are kept. Combine this with a GRID architecture that brings not only additional capacity into a virtualized single pool of storage, but all the necessary processor, memory and bandwidth…so that as you data grows your performance stays the same. If you just add capacity as another “shelf”, as you point out, you are sending more data throught the same processor head and slowing things down further. This is a very “purpose-built” approach to disk backup with deduplication. I encourage you to learn more about ExaGrid. http://www.exagrid.com

]]>