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
DevOps’ Impact on Application Security
DevOps’ Impact on Application Security
Managing the interdependency between software and infrastructure is a thorny challenge. Often, it’s a “developers are from Mars, systems engineers are from Venus” situation.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0914
Published: 2014-07-30
Cross-site scripting (XSS) vulnerability in IBM Maximo Asset Management 6.2 through 6.2.8 and 6.x and 7.x through 7.5.0.6, Maximo Asset Management 7.5 through 7.5.0.3 and 7.5.1 through 7.5.1.2 for SmartCloud Control Desk, and Maximo Asset Management 6.2 through 6.2.8 for Tivoli IT Asset Management f...

CVE-2014-0915
Published: 2014-07-30
Multiple cross-site scripting (XSS) vulnerabilities in IBM Maximo Asset Management 6.2 through 6.2.8, 6.x and 7.1 through 7.1.1.2, and 7.5 through 7.5.0.6; Maximo Asset Management 7.5 through 7.5.0.3 and 7.5.1 through 7.5.1.2 for SmartCloud Control Desk; and Maximo Asset Management 6.2 through 6.2.8...

CVE-2014-0947
Published: 2014-07-30
Unspecified vulnerability in the server in IBM Rational Software Architect Design Manager 4.0.6 allows remote authenticated users to execute arbitrary code via a crafted update site.

CVE-2014-0948
Published: 2014-07-30
Unspecified vulnerability in IBM Rational Software Architect Design Manager and Rational Rhapsody Design Manager 3.x and 4.x before 4.0.7 allows remote authenticated users to execute arbitrary code via a crafted ZIP archive.

CVE-2014-2356
Published: 2014-07-30
Innominate mGuard before 7.6.4 and 8.x before 8.0.3 does not require authentication for snapshot downloads, which allows remote attackers to obtain sensitive information via a crafted HTTPS request.

Best of the Web
Dark Reading Radio