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.

News

2/11/2010
08:53 AM
George Crump
George Crump
Commentary
50%
50%

Changing Backup's Image

In a recent briefing with Vizioncore they introduced their Backup 2.0 concept that is based on the value of image based backups. The concept of image based backups are not new and there are several companies that offer image based backup technology like NetApp, Symantec, Syncsort and others. Thanks to the wide acceptance of disk as a backup repos

In a recent briefing with Vizioncore they introduced their Backup 2.0 concept that is based on the value of image based backups. The concept of image based backups are not new and there are several companies that offer image based backup technology like NetApp, Symantec, Syncsort and others. Thanks to the wide acceptance of disk as a backup repository and server virtualization, the time has come to consider the value of only backing up server images.Server images are of course what VMware and other virtualization technologies create when you virtualize a server. A file that encapsulates the potentially millions of files that an individual server may contain. Dealing with a single image is far easier than dealing with the millions. However this single image file can be quite large and thereby cause its own problems when trying to protect it.

Dealing with image size is being addressed by data protection software products by only sending the blocks of information that changed between the last few backups. The software has to either be able to scan for or get this information from the operating system. VMware for example via their vStorage API can provide the backup application a list of changed blocks within the image. Software can differentiate itself by determining if those blocks are valid or if they contain deleted data. Further the backup applications could compare these blocks to other blocks to eliminate redundant blocks of information.

Physical machine backups are handled differently depending on the application. Applications will either back them up into virtual image repositories via a physical to virtual conversion (P2V) or other applications will back them up as a stand alone entity. Both physical and virtual image copies are typically done to disk by these applications. Either the application software itself or the disk needs to be snapshotted somehow to be able to provide a point in time rollback capability in case you need to get to a prior version of the image.

Server recovery is another key advantage to an image based model. If the backup of the image is stored in a native form, server recovery can be almost instant. Simply point to the image and resume operations. In either a virtual environment or physical this requires some planning. For example make sure that the virtual infrastructure can connect directly to the backup repository. That said even if the image has to be copied across a network it is almost always far faster to copy a single 200GB file than 100,000 files that total up to 200GB.

Individual file recovery could be image's weak spot and something to make sure you understand. Do you have to recover the whole image before being able to get to an individual file? Not always. Several applications have cracked the code on opening up server images and providing a single file recovery. Some are even offering or planning to offer the ability to provide further granularity like message level recovery from within Exchange, This could be expanded table level recovery support for databases.

Image based backup technology is a viable alternative to traditional file by file backup. It can reduce backup windows and the amount of data transported. It also can greatly reduce the recovery times and return to operation times when an application fails.

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

Subscribe to our RSS feed.

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

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/3/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
New 'Nanodegree' Program Provides Hands-On Cybersecurity Training
Nicole Ferraro, Contributing Writer,  8/3/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15820
PUBLISHED: 2020-08-08
In JetBrains YouTrack before 2020.2.6881, the markdown parser could disclose hidden file existence.
CVE-2020-15821
PUBLISHED: 2020-08-08
In JetBrains YouTrack before 2020.2.6881, a user without permission is able to create an article draft.
CVE-2020-15823
PUBLISHED: 2020-08-08
JetBrains YouTrack before 2020.2.8873 is vulnerable to SSRF in the Workflow component.
CVE-2020-15824
PUBLISHED: 2020-08-08
In JetBrains Kotlin before 1.4.0, there is a script-cache privilege escalation vulnerability due to kotlin-main-kts cached scripts in the system temp directory, which is shared by all users by default.
CVE-2020-15825
PUBLISHED: 2020-08-08
In JetBrains TeamCity before 2020.1, users with the Modify Group permission can elevate other users' privileges.