By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
In the first two parts of this series, we looked at why admins might want to move to a NAS or SAN-based storage platform and away from directly attached disks. We also learned about the process of migrating information from Windows servers to networked storage. In this third and final article, we will look at backup, management and restore procedures for all this migrated information.
Unstructured, file level backups
Ever since Windows XP, the option to recover previous versions of documents, spreadsheets and other documents while maintaining previous versions of files using a solution driven from the operating system has posed some issues. The amount of space taken up by previous versions when the volume shadow is done at the file-block level is far greater than a similar copy taken at the volume-block level -- which is the level at which NAS and SAN storage solutions function.
The better NAS and SAN-based systems carry out backups at the volume-block level, which means that only the physical disk blocks that were changed during a disk write operation are backed up. Rather than backing up an entire 5 MB PowerPoint file held on network storage or the changed bytes within that file, the backup will instead just back up the disk blocks that hold the part of the file that was changed. Most local disk and NAS-based backup solutions work in a "halfway house" manner by backing up the bytes of a file that -- although more efficient than securing a copy of the entire file -- is still nowhere near as efficient as working at the volume-block level.
Structured database backups
There are differences between conducting backups and restores on a networked storage and doing backups and restores on conventional direct-attached storage. Carrying out a backup on large Exchange, SQL or even Oracle databases generally involves doing one per day, purely to reduce the impact that the backup has on the server processor and memory. Whether that daily backup is a full backup or an incremental backup depends largely on the size of the database itself.
The larger a database becomes, the more time it takes to perform a full backup. And the longer it takes, the more likely it is that you'll do an incremental backup. Carrying out daily backups these days means you probably won't meet a stringent RPO (recovery point objective).
Daily backups are fine if you have an RTO (recovery time objective) of several hours and an RPO of up to 24 hours. However, if you are required to bring your database service back within minutes and to a point minutes away from the moment of failure, then your conventional backups are often -- to be frank -- useless.
These problems do not exist with structured databases stored on networked storage. Without any software on the database server itself, the SAN controller is able to put the database into a paused state, take a "snapshot" of the storage on disk and then allow the database to resume write operations for clients. At no point are read operations paused, allowing clients to continue calling data from the database.
Unlike on local storage systems, carrying out hourly backups on networked storage platforms will not generally impact the performance of the server or storage because the act of the backup does not cause any significant disk reads by itself. At the very least, a local disk backup will cause the backup application to track across the disk and read the transaction logs. A networked storage backup will read nothing more than the disk map and secure a copy of the relevant parts of that map. The storage administrators then use a backup protocol that takes that information and -- during quiet hours -- sends that backed up information off to tape or another disk solution.
Unstructured data recoveries from networked storage are as easy to do from networked storage as from local disks on a server. While the background process of physical file storage is greater, the act of recovering information is very similar. Users can either click the properties of the file and select the file they want to recover or they can browse to the "~snapshot" directory on the networked storage -- where such a feature has been implemented and configured -- and recover any version of an old file they require.
Recovering information from structured data sources such as databases is a little different. The backup itself does not actually exist in a clearly identifiable form, but uses the last full backup on disk and the delta changes to present a database that can be used. If an entire database simply needs to be rolled back to a previous state, then the procedure is as simple as changing all the block pointers to a previous state. That way, a backup is restored with absolutely no physical movement of data whatsoever.
When an administrator uses an application provided by the SAN vendor to restore an individual table, record, mailbox or message, he/she does so by following the vendor's instructions. Typically, the instructions will be to connect to a virtualized LUN, which looks like it contains an older copy of the database, and recover the message from there. Of course, the SAN merely presents it as a full-sized recoverable backup. In reality, the backup is a few megabytes in size, representing only the changes made recently to the database.
In today's world, it is important to do data backups and restores as quickly and as unobtrusively as possible. Restores also need to be available within minutes of the point of failure -- or sooner.
This series has offered an overview of what moving to a SAN and NAS-based storage solution will mean to your server count. You can get more functionality from a networked storage platform and improve backup efficiency and performance. And you'll reduce the time it takes to recover information while increasing the granularity to which restores can be done.
ABOUT THE AUTHOR
Mark Arnold, MCSE+M, Microsoft MVP, is principal consultant with LMA Consulting LLC, a private messaging and storage consultancy based in Philadelphia. Mark assists customers in designs of SAN-based Exchange Server implementations. He has been a Microsoft MVP in the Exchange discipline since 2001, contributes to various Microsoft-focused technology Web sites and can be found in the Exchange newsgroups and other Exchange forums.