News

2/13/2009
12:04 PM
George Crump
George Crump
Commentary
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
Comments
Oldest First  |  Newest First  |  Threaded View
'Hidden Tunnels' Help Hackers Launch Financial Services Attacks
Kelly Sheridan, Staff Editor, Dark Reading,  6/20/2018
Inside a SamSam Ransomware Attack
Ajit Sancheti, CEO and Co-Founder, Preempt,  6/20/2018
Tesla Employee Steals, Sabotages Company Data
Jai Vijayan, Freelance writer,  6/19/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-12716
PUBLISHED: 2018-06-25
The API service on Google Home and Chromecast devices before mid-July 2018 does not prevent DNS rebinding attacks from reading the scan_results JSON data, which allows remote attackers to determine the physical location of most web browsers by leveraging the presence of one of these devices on its l...
CVE-2018-12705
PUBLISHED: 2018-06-24
DIGISOL DG-BR4000NG devices have XSS via the SSID (it is validated only on the client side).
CVE-2018-12706
PUBLISHED: 2018-06-24
DIGISOL DG-BR4000NG devices have a Buffer Overflow via a long Authorization HTTP header.
CVE-2018-12714
PUBLISHED: 2018-06-24
An issue was discovered in the Linux kernel through 4.17.2. The filter parsing in kernel/trace/trace_events_filter.c could be called with no filter, which is an N=0 case when it expected at least one line to have been read, thus making the N-1 index invalid. This allows attackers to cause a denial o...
CVE-2018-12713
PUBLISHED: 2018-06-24
GIMP through 2.10.2 makes g_get_tmp_dir calls to establish temporary filenames, which may result in a filename that already exists, as demonstrated by the gimp_write_and_read_file function in app/tests/test-xcf.c. This might be leveraged by attackers to overwrite files or read file content that was ...