Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

4/21/2011
02:35 PM
George Crump
George Crump
Commentary
50%
50%

Forget Tape Vs. Disk, Use Them Together

Tape is ideal for third tier backup data and the cost per GB, performance, and reliability make it an ideal compliment to disk backup.

"Tape is Dead" may be a common statement, but it just does not hold true to the reality. Most tape and tape library companies are reporting strong sales growth over the past couple years. User studies indicate that well under 20% of data centers have become disk backup only. In most environments this should no longer be a tape vs. disk conversation, both technologies should continue to be leveraged together.

Most data centers now consider backup disk as the first source of recovery when something has failed. In reality backup disk should be your second point of recovery not your first. As Storage Switzerland discussed in a recent article "Protecting Applications From Storage System Failures" most data centers should not be counting on the backup process at all for mission critical recoveries.

There should be some other form of recovery technology in place that provides direct access to data and a smaller window of time between data protection captures. Disk backup should be the second step in a recovery process when something goes wrong with a high availability (HA) solution or an older point in time of the data set is needed. The disk backup can also be used for primary recovery of less critical systems but we think the number of applications and services that can sustain multi-hour recovery times is decreasing.

Tape should be looked at as the third tier of recovery, when a much older point in time of data is needed or when something goes wrong with the previous two recovery steps. Despite this, there is also a situation where tape should be considered as the primary backup and recovery point. Consider tape first when a very large data set needs to, and can be, transferred across a very high-speed connection.

Tape, if it can be sustained at full streaming performance is incredibly fast, faster than many disk based backup systems. An example of this might be a database environment with a large 200GB+ data set where tape can either be attached directly or via a fibre channel connection. A transfer directly from the database server to tape is often faster than to a backup class disk system. A case can be made that tape is all you need here since many database applications have some other form of availability in place for quick recovery. The purpose of the backup then is to create an archive of the database and to get that data off-site. Something that tape is well suited for.

Tape is ideal for this third tier of backup data thanks to the continued progress of the technology. The cost per GB, performance and now the reliability and shelf life of tape make it an ideal compliment to disk backup. It provides an alternate, offline storage method in case something goes wrong with disk media. In most environments, HA solutions should be the point of first restore, disk backup should be the point of second restore and tape backup should be the safety net. The challenge is that the integration between these three layers is lacking and is something we will discuss in our next entry.

Follow Storage Switzerland on Twitter

George Crump is lead analyst of Storage Switzerland, an IT analyst firm focused on the storage and virtualization segments. Storage Switzerland's disclosure statement.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Why Cyber-Risk Is a C-Suite Issue
Marc Wilczek, Digital Strategist & CIO Advisor,  11/12/2019
Black Hat Q&A: Hacking a '90s Sports Car
Black Hat Staff, ,  11/7/2019
The Cold Truth about Cyber Insurance
Chris Kennedy, CISO & VP Customer Success, AttackIQ,  11/7/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-16863
PUBLISHED: 2019-11-14
STMicroelectronics ST33TPHF2ESPI TPM devices before 2019-09-12 allow attackers to extract the ECDSA private key via a side-channel timing attack because ECDSA scalar multiplication is mishandled, aka TPM-FAIL.
CVE-2019-18949
PUBLISHED: 2019-11-14
SnowHaze before 2.6.6 is sometimes too late to honor a per-site JavaScript blocking setting, which leads to unintended JavaScript execution via a chain of webpage redirections targeted to the user's browser configuration.
CVE-2011-1930
PUBLISHED: 2019-11-14
In klibc 1.5.20 and 1.5.21, the DHCP options written by ipconfig to /tmp/net-$DEVICE.conf are not properly escaped. This may allow a remote attacker to send a specially crafted DHCP reply which could execute arbitrary code with the privileges of any process which sources DHCP options.
CVE-2011-1145
PUBLISHED: 2019-11-14
The SQLDriverConnect() function in unixODBC before 2.2.14p2 have a possible buffer overflow condition when specifying a large value for SAVEFILE parameter in the connection string.
CVE-2011-1488
PUBLISHED: 2019-11-14
A memory leak in rsyslog before 5.7.6 was found in the way deamon processed log messages are logged when $RepeatedMsgReduction was enabled. A local attacker could use this flaw to cause a denial of the rsyslogd daemon service by crashing the service via a sequence of repeated log messages sent withi...