News
2/13/2009
12:04 PM
George Crump
George Crump
Commentary
Connect Directly
RSS
E-Mail
50%
50%

The Problem With Snapshots

Storage solutions have come a long way, but there are areas that need improvement. The next two entries I am going to focus on two of those areas; snapshots and high availability. This entry we will pick on snapshots.

Storage solutions have come a long way, but there are areas that need improvement. The next two entries I am going to focus on two of those areas; snapshots and high availability. This entry we will pick on snapshots.Snapshots sound like the 'be all and end all' for covering yourself from some sort of data disaster but it is an overused term and sometimes can mean different things to different suppliers. For our purposes the file or volume being 'snapped' is comprised of blocks of data. These blocks are organized by an index of pointers or links to the actual blocks on disk. When an application requests data it does not try to find the blocks itself, it is routed to the index for the location. When a snapshot is "taken" you are actually only copying this primary index. This is very small and takes less than a few seconds, if that, to complete. The blocks that are referenced by the snapshot are then put into a read-only mode and can't be changed or deleted.

Typically upon the initial snapshot almost no additional storage is consumed. As the volume is written after the snapshot, new blocks representing those changes are written to the original file or volume and the older blocks that are still under the lock of the snapshot are written to a new area of disk. This is also where data growth begins. The snapshot is not updated and still references the static read-only blocks, allowing you to view that data at a point in time.

OK here is where it get's interesting. Snapshots typically have to reside on the same storage as the original data. That means that if you are using expensive 15k RPM drives for the actual data you are also using expensive 15k RPM drives to store what amounts to a backup of that data. This creates a cost imbalance.

Also in a real world data center there is not just one storage system or SAN, there are multiple. Each one of these require a different snapshot interface with a different set of snapshot scripts, all of which decreases IT efficiency.

Probably most important these snapshots are totally dependent on the primary storage not failing. If you have a corruption on your primary volume, it is destroyed and all your snapshots are destroyed with it.

Finally with many storage systems each successive snapshot you take may take a performance hit on the system. This limits the number of snapshots you can have and lowers your granularity of recovery.

There are solutions. You can leverage a independent virtualization appliance like DataCore's SANsymphony that will bring all your storage under one storage software umbrella or you can use products from companies like InMage and SyncSort that move the snapshot data off of the primary storage platform and onto a secondary storage device as we discussed in our recent article on Driving a Backup ROI.

For more information register for our upcoming presentation on "The State of Backup", getting more from your backup process.

Track us on Twitter: http://twitter.com/storageswiss.

Subscribe to our RSS feed.

George Crump is founder of Storage Switzerland, an analyst firm focused on the virtualization and storage marketplaces. It provides strategic consulting and analysis to storage users, suppliers, and integrators. An industry veteran of more than 25 years, Crump has held engineering and sales positions at various IT industry manufacturers and integrators. Prior to Storage Switzerland, he was CTO at one of the nation's largest integrators.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Threat Intel Today
Threat Intel Today
The 397 respondents to our new survey buy into using intel to stay ahead of attackers: 85% say threat intelligence plays some role in their IT security strategies, and many of them subscribe to two or more third-party feeds; 10% leverage five or more.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0640
Published: 2014-08-20
EMC RSA Archer GRC Platform 5.x before 5.5 SP1 allows remote authenticated users to bypass intended restrictions on resource access via unspecified vectors.

CVE-2014-0641
Published: 2014-08-20
Cross-site request forgery (CSRF) vulnerability in EMC RSA Archer GRC Platform 5.x before 5.5 SP1 allows remote attackers to hijack the authentication of arbitrary users.

CVE-2014-2505
Published: 2014-08-20
EMC RSA Archer GRC Platform 5.x before 5.5 SP1 allows remote attackers to trigger the download of arbitrary code, and consequently change the product's functionality, via unspecified vectors.

CVE-2014-2511
Published: 2014-08-20
Multiple cross-site scripting (XSS) vulnerabilities in EMC Documentum WebTop before 6.7 SP1 P28 and 6.7 SP2 before P14 allow remote attackers to inject arbitrary web script or HTML via the (1) startat or (2) entryId parameter.

CVE-2014-2515
Published: 2014-08-20
EMC Documentum D2 3.1 before P24, 3.1SP1 before P02, 4.0 before P11, 4.1 before P16, and 4.2 before P05 does not properly restrict tickets provided by D2GetAdminTicketMethod and D2RefreshCacheMethod, which allows remote authenticated users to gain privileges via a request for a superuser ticket.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Three interviews on critical embedded systems and security, recorded at Black Hat 2014 in Las Vegas.