Windows Backup

8/13/2019 Windows Backup

1/27

The Definitive Guide Totm

Don Jones

Windows

Application and

Server Backup 2.0


2/27

Introduction

i

IntroductiontoRealtimePublishersby Don Jones, Series Editor

For several years now, Realtime has produced dozens and dozens of highquality booksthat just happen to be delivered in electronic formatat no cost to you, the reader. Wevemade this unique publishing model work through the generous support and cooperation ofour sponsors, who agree to bear each books production expenses for the benefit of ourreaders.

Although weve always offered our publications to you for free, dont think for a momentthat quality is anything less than our top priority. My job is to make sure that our books areas good asand in most cases better thanany printed book that would cost you $40 ormore. Our electronic publishing model offers several advantages over printed books: You

receive chapters literally as fast as our authors produce them (hence the realtime aspectof our model), and we can update chapters to reflect the latest changes in technology.

I want to point out that our books are by no means paid advertisements or white papers.Were an independent publishing company, and an important aspect of my job is to makesure that our authors are free to voice their expertise and opinions without reservation orrestriction. We maintain complete editorial control of our publications, and Im proud thatweve produced so many quality books over the past years.

I want to extend an invitation to visit us at http://nexus.realtimepublishers.com, especiallyif youve received this publication from a friend or colleague. We have a wide variety ofadditional books on a range of topics, and youre sure to find something thats ofinterest to

youand it wont cost you a thing. We hope youll continue to come to Realtime for yourfar into the future.educational needs

enjoy.Until then,

Don Jones
http://nexus.realtimepublishers.com/http://nexus.realtimepublishers.com/http://nexus.realtimepublishers.com/http://nexus.realtimepublishers.com/http://nexus.realtimepublishers.com/


3/27

Table of Contents

ii

Introduction to Realtime Publishers ................................................................................................................. i

Ch apter 1: Introduction ......................................................................................................................................... 1The Philosophy of Backup ............................................................................................................................... 2

W hy Backup 1.0 Is No Longer Enough ....................................................................................................... 3Backup Windows ............................................................................................................................................ 3NonContinuous .............................................................................................................................................. 5Just the DataNot the Application ................................................. ............................................. ........... 5Disaster Recovery Is Too Inflexible ........................................................................................................ 6Backup 1.0: The Verdict ............................................................................................................................... 7

Ba ckup Basics ........................................................................................................................................................ 7Why Back Up? ............................................ ............................................. ............................................. ............. 7What Do You Back Up? ................................................................................................................................. 8When Do You Back Up? ............................................................................................................................. 10What Type of Backup Will You Use? .................................................................................................... 11Where Do You Store Backups? ............................................................................................................... 13Should You Test Backups? ....................................................................................................................... 13Are You Keeping an Eye on Your Backups? ...................................................................................... 14

Ap proaches to Backing Up ............................................................................................................................ 16FileBased Backups ..................................................................................................................................... 16Image Backups .............................................................................................................................................. 17ApplicationSpecific Ideas ........................................... ............................................. ................................ 18Our Backup 2.0 Wish List .............................................................................................................................. 21

Whats Ahead ...................................................................................................................................................... 22


4/27

Copyright Statement

iii

Copyright Statement

2009 Realtime Publishers. All rights reserved. This site contains materials that havebeen created, developed, or commissioned by, and published with the permission of,Realtime Publishers (the Materials) and this site and any such Materials are protectedby international copyright and trademark laws.

THE MATERIALS ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND,EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,TITLE AND NON-INFRINGEMENT. The Materials are subject to change without noticeand do not represent a commitment on the part of Realtime Publishers or its web sitesponsors. In no event shall Realtime Publishers or its web site sponsors be held liablefor technical or editorial errors or omissions contained in the Materials, including withoutlimitation, for any direct, indirect, incidental, special, exemplary or consequentialdamages whatsoever resulting from the use of any information contained in the Materials.

The Materials (including but not limited to the text, images, audio, and/or video) may notbe copied, reproduced, republished, uploaded, posted, transmitted, or distributed in anyway, in whole or in part, except that one copy may be downloaded for your personal, non-commercial use on a single computer. In connection with such use, you may not modifyor obscure any copyright or other proprietary notice.

The Materials may contain trademarks, services marks and logos that are the property ofthird parties. You are not permitted to use these trademarks, services marks or logoswithout prior written consent of such third parties.

Realtime Publishers and the Realtime Publishers logo are registered in the US Patent &Trademark Office. All other product or service names are the property of their respectiveowners.

If you have any questions about these terms, or if you would like information aboutlicensing materials from Realtime Publishers, please contact us via e-mail [email protected].
mailto:[email protected]:[email protected]


5/27

Chapter 1

1

Chapter1:IntroductionThe first backuptechnicallywas around 1951, when the first generation of digitalcomputing appeared in the form of UNIVAC I. The backups, such as they were, were thepunch cards used to feed instructions to the massive machine. Once computers began touse more flexible forms of storage, reeltoreel magnetic tape began to replace punch cards.In 1965, IBM introduced the first computer hard drives, although through the 1970s, thesedevices remained impractically expensive to use for backups. Floppy disks came into use in1969an 8inch monster storing just 80 kilobytes of data. Recordable compact disksbecame available in the early 1990s, and flash drives became common in the early part ofthe 21stcentury. Shockingly, magnetic tapethe secondoldest form of backup storageisstillin use today. Figure 1.1 shows a timeline of data backup storage (excerpted fromwww.backuphistory.com), and you can see that tape is still alive and welland has beenfor almost 50 years.

Figure1.1:Backupstoragetimeline.

Theres an interesting parallel to be drawn here: Despite numerous technical advances instorage, we continue to rely on one of the oldest mediums to store backups. The sameapplies to our backup techniques and procedures: Despite advances in howwe performbackups, we tend to still use the same decadesold techniques, albeit wrapped up in prettynew tools.
http://www.backuphistory.com/http://www.backuphistory.com/http://www.backuphistory.com/http://www.backuphistory.com/http://www.backuphistory.com/http://www.backuphistory.com/http://www.backuphistory.com/http://www.backuphistory.com/


6/27

Chapter 1

2

Throughout computing history, backups have been practical, simple procedures: Copy abunch of data from one place to another. Complexities arise with alwayson data like thedatabases used by Exchange Server and SQL Server, and various techniques have beendeveloped to access that form of inuse data; however, backups have ultimately alwaysbeen about a fairly simple, straightforward copy. Even magnetic tapemuch more

advanced than in the 1960s, of courseis still a primary form of storage for manyorganizations backups.

I call it Backup 1.0essentially the same way weve all been making backups since thebeginning of time, with the only major changes being the storage medium we use. Althoughmany bright engineers have come up with clever variations on the Backup 1.0 theme, itsstill basically the same. And I say its no longer enough. We need to rethink whywe dobackups, and invent Backup 2.0a new way to back up our data that meets todaysbusiness needs. Surprisingly, many of the techniques and technologies that support Backup2.0 already existwe just need to identify them, bring them together, and start using them.

ThePhilosophy

of

Backup

Lets start with the question, Why do we back up?

I suppose the first answer that comes to mind is simple enough: Sothatwedontloseanydata.But thats not actually an accurate answer. Personally, I dont back things up justsothey will never be lost; I back them up so that Icancontinueusingthem.Thats a subtledifference, but an important one. If youre only concerned about never losing data, Backup1.0 is probably sufficient: Copy your data to a longterm storage mediumprobablymagnetic tapeand stick it in a vault somewhere. You could call it archivingand be moreaccurate, really. But most organizations arent as concerned about archiving as they are

about making sure that data remains available, which means you not only need a backupbut also a means of restoringthe data to usability. So the real answer, for mostorganizations, is more complicated: Sothatourdataremainsavailabletousallthetime.

Thats where Backup 1.0the backup techniques and technologies weve all used foreverand are still native to operating systems (OSs) like Microsoft Windowscan really fail.Making a copy of data is one thing; putting that copy back into production use is often tooslow, too complicated, and too monolithic. And thats where Backup 1.0 fails us. As we startconsidering Backup 2.0, and what we need it to do, we need to bear in mind our realpurpose for backing up. Ultimately, we dont care about the backing up part very much atallwe care about the restorepart a lot more.


7/27

Chapter 1

3

WhyBackup1.0IsNoLongerEnoughOur decadesold backup techniques are notsufficient anymore. They may be great forcreating backupsalthough in many cases, they arent even good for thatbut they do notexcel at bringing the right data back into production as quickly as possible. Despite

advances in specialized agents, compressed network transmissions, and so forth, were stilljust making a copy of the data, and that doesnt always lend itself well to restoringthe data.Why?

BackupWindows

One problem is the need for backupwindows,periods of time in which our data isnt beingused very heavily, so that we can grab a consistent copy of it. Consistencyis critical forbackups: All the data in any given copy needs to be internally consistent. We cant back uphalf a database now and the other half later because the two halves wont match. As ourdata stores grow larger and larger, however, getting a full backup becomes more and moredifficult.

Microsofts TerraServer, which stores and provides access to satellite photographs for theentire United States, has a data store in excess of 1 terabyte, and even with fairly advancedbackup hardware, it still takes almost 8 hours to back it all up. Thats a total datathroughput of 137GB per hourbut if that data were in constant use, it would become lesspractical to make a complete copy on a regular basis.

As a workaround, we commonly use differential or incremental backups. These allow us tograb a lot less data all at once, making it easier to make our backup copy. The problem isthat these ignore the realreasonwe made the backup in the first placeto enable us torestorethat data. Consider a common backup approach that uses SQL Servers native

backup capabilities:

Sunday, full backup

Every weekday evening, a differential backup

Every hour during the day from 8am to 5pm, a log backup

Those weeknight differentials grab everything that has changed since the last full backup(as opposed to an incremental, which grabs everything that has changed since the last fullorthe last incremental). If something goes wrong on Friday at 4:05pm, theres a lot of datato restore:

Last Sundays full backupwhich will be fairly large Thursdays differentialwhich will also have grown quite large

The log backups from Friday at 8am, 9am, 10am, 11am, noon, 1pm, 2pm, 3pm, andill be fairly small4pmthats nine files in all, although each w

Figure 1.2 illustrates these different backup types.


8/27

Chapter 1

4

Figure

1.2:

SQL

Server

backup

types.

Thats a ton of workand a ton of waiting while tapes and hard drives spin, restoring allthat data. Sure, we wont have lost muchjust 5 minutes worth of workbut on a largedatabase (say, a terabyte or so), you could easily be waiting for 16 hours or more.

And thats ifthe backups all work. Tape drives and even hard drives are not immune tocorruption, errors, and failures, and one of the most common stories in the world is theadministrator who realized that the backup tapes were no goodand realized it whiletrying to restore from one of them. We all know that we should test our backups, buthonestly, do you do it? Out of more than 300 consulting clients Ive worked with in the past10 or so years, oneof them had a regularlyscheduled plan to do test restores. One. Lessthan one percent. Why?

Well, the one customer who did regularlyscheduled test restores had a dedicatedadministrator who did almost nothing else. A full test restore of their environment, usingBackup 1.0style techniques and technologies, would require the entire IT team about aweek to perform. That one administrator could testrestore various systems, one at a time,over the course of a monthand then start over. I think that pretty much answers thequestion about why so few people test their backups. Its a simple: Too much data for fullbackups results in workarounds such as differentials and incrementals that contribute tolengthy restore times, which is why we never bother to testand why, when the rubberhits the road and we needthose backups, nobodyis happy about how long it takes to grab

the needed data.


9/27

Chapter 1

5

NonContinuous

Backup 1.0 has another major weak point: Its always a point in time. A snapshot. Non-continuous,in other words. Consider one approach to backing up Active Directory (AD),which I see a lot of my customers using:

Full backup of every domain controllers System State on the weekends. This is aquick, fairly small backupeven an exceptionally large domain can be backed up ina few minutes.

n,On one or two domain controllers, a twicedaily backup of the System State. Agaithis operation is quick.

The problem is that you always stand to lose a halfdays worth of work because youreonly taking snapshots twice a day. What if you just imported a couple of hundred newusers into the domain, added them to groups, and assigned them file permissions onvarious file servers? Losing that work not only means you have to start over, it also meansyouve got orphan Security Identifiers (SIDs) floating around on all those file permission

Access Control Lists (ACLs). Youll not only have to repeat your work, youll also have toclean up all those ACLs.

Businesses tend to design backup strategies around the concept of How much data are wewilling to lose, and how much work are we willing to repeat? Theres often a lot lessconsideration about How quickly do we want to restore the data? and much to myirritation, almost nobody thinks to answer, We dont want to lose anydata or repeat anywork! Backup 1.0 has conditioned us to accept data loss and repeated work as inevitable,and so we design backup schemes that tradeoff between the inevitable loss of data and theamount of backup resources we want to devote. Frankly, the attitude that I haveto acceptdata loss and repeated work is nonsense. I cant believe that, a decade into the 21stcentury,

were all so complacent about that attitude.JusttheDataNottheApplication

Another problem with Backup 1.0 is that we often tend to just back up datadatabases,files, System State, or whateverwe rarely back up the applicationsthat use the data. Itook a brief survey on my blog at ConcentratedTech.com, and about 95% of therespondents said they dont back up applications because they keep the originalinstallation media so that they can always reinstall the application if necessary.

Really? Lets think about that: Microsoft Exchange Server takes about 45 minutes to anhour to install properly. Then you have to apply the latest service packanother halfhouror soand any patches released since the service packcall that another 20 to 30 minutes.

Thenyou can start restoring the data, which may take another few hours. If yourerebuilding an entire server, of course, youll have to start with reinstalling Windows itself,and its service pack and patches, which will add another 2 or 3 hours to the process. Thetotal? Maybe a full work day. And for some reason, people find that acceptablebecauseBackup 1.0 is all about archiving,really, not restoring.


10/27

Chapter 1

6

One valid counterargument is that mostrestorations are for just the data, or even a part ofthe data (like a single database table, or a single email message), and arent a fullondisaster recovery rebuild. Well, okaybut does that mean its still acceptable for a fullondisaster recovery rebuild to take a full day? Typically not, and thats why someorganizations will imagetheir servers, using software that takes a snapshot of the entire

hard drive and often compresses it to a smaller size. Used for years as a deploymenttechnique, it works well for backing up an entire server. For backingupthe server but oftennot restoringit.Snapshot, or pointintime, images take time to produce, and the servermay even have to be shut down to make an imagemeaning youll need a frequentmaintenance window. A traditional snapshot image wont contain the latest data, so evenafter restoring the image, you still have to rely on traditional backups to get your mostrecent data back. It just amazes me that we accept these limitations.

DisasterRecoveryIsTooInflexible

Closely related to the previous discussion is the fact that people do backups for twodifferent reasons. Reason one, which I think is probably more commonly cited as a reason

to back up is to restore small pieces of data. Youve doubtless done this: Restored a singlefile that someone deleted by accident, or an email message, or a database table. Nearlyeveryone has dealt with this, and it isnt difficult to sell this reason to management whenacquiring backup technologies.

The second reason is for what I called fullon disaster recovery in the previous section.This is when an entire serveror, goodness help you, an entire data centeris lost, andhas to be restored onsite or at a different location. Unfortunately, this level of disaster isactually quite rare, and its a tough sell for management if the organization hasntencountered this type of disaster in the past.

The ultimate problem is that Backup 1.0 technologies lend themselves to one or the other

scenariosbut not usually to both. In other words, if you have a product that does greatbaremetal recovery, it may not do singleitem recovery as well. Some productscompromise and do an okay job at bothbacking up the entire server to enable baremetalrecovery (and often providing bootable CDs or other techniques so that you can initiate abaremetal recovery), and then keeping a separate index of every backedup piece of datato make singleitem recovery easier. Frankly, Ive not used many solutions that do a greatjob at both tasksand the fact that theyre all essentially snapshotbased still makes thempretty limited. I neverwant to have to agree that losing a certain amount of work isacceptable.


11/27

Chapter 1

7

Backup1.0:TheVerdict

If youre just archiving data, Backup 1.0 is pretty awesome. It starts to fail, though, whenyou need to restorethat data, and want to do so in an efficient manner that enables bothsingleitem and fullon disaster recovery restoration. The snapshotoriented nature ofBackup 1.0 means youre always at risk of losing some work, and that snapshotoriented

nature also imposes rigid requirements for maintenance and backup windowswindowsthat might not always be in the business best interests.

So lets rethink backup. I want to go back to basics and really define what backups shoulddo. Consider this definition a wish list for Backup 2.0.

BackupBasicsI have no doubt that youre a pretty experienced administrator or IT manager, and youmight not think that backup basics is a particularly enticing section. Bear with me. Ill tryto keep each of the following sections succinct, but I really want to step back from the

existing technologies and techniques to focus on what people and businessesnotsoftware vendorswant their backup programs to do. Weve been doing backups more orless the same way for so long that I think its beneficial to just forget everything wevelearned and done and start over without any assumptions or preconceptions.

WhyBackUp?

Weve covered no confusion:this topic pretty well, but let me state it clearly so that theres

Backups should prevent us from losing any data or losing anywork, and ensure that we always have access to our data withas little downtime as possible.

That statement implies a few basic business capabilities:

ta loss as possibleWhen a problem occurs, we want to experience as little da

We need to be able to recover data as quickly as possible

We place equal importance on recovering a single bit of data as we do in dealingwith a complete disaster


12/27

Chapter 1

8

The statement also means a few things traditionally associated with Backup 1.0 probablyarent acceptable:

Snapshots that grab only a certain pointintime image are less desirable

Any system that is weighted toward disaster recovery or toward singleitem

recovery is less desirablewe need bothcapabilities

Any system that requires lengthy, multistep restore processes is less desirable

Backups that do not lend themselves to some form of physically protected storageare less desirable

Backups that requires hours and hours to complete will require hours and hours tostorre eboth of which are less desirable

So given whywe back up, we can take a fresh look at whatwe back up.

WhatDoYouBackUp?

Even the relatively primitive backup software included with Windows Server 2003 (andprior versions of Windows) understood that you dont always need to back up everythingevery time you run a backup. Figure 1.3 shows how that utility allowed you to select theitems you wanted to back up or restorea user interface (UI) duplicated in some form bymost commonlyused backup software.


13/27

Chapter 1

9

Figure1.3:SelectingwhattobackuporrestoreinWindo

So wha ny choices:

wsBackup.

t do you back up? On any given server, you have ma

Back up the entire serverevery file on every disk

Back up just datashared files, application databases, and so forth

Back up applications and their dataincluding the applications executable files andsettings

Back up the OS and its settings but not any application files or any data


14/27

Chapter 1

10

The permutations are practically limitless. If youre simply after archivingcreatingbackups, that isthen anything that grabs the data is fine. In fact, justgrabbing the data isprobably all you need to do ifall you want to do is create a pointintime snapshot forarchival purposes. Sure, you couldback up the entire serverand if your goal is to be ableto handle a fullon disaster orrecover individual items, then backing up the entire server

would provide both capabilities. But backing up the entire server would probably take a lotlonger. It might not even be entirely possible because there will always be some open files,running executables, and other items that Backup 1.0style backup techniques cant get to.So maybe backing up the entire server isnt really practical. After all, we can always

ions l media, right?reinstall the OS and any applicat from their origina

Wait, a secondlets go back to whywere backing up:


Okay, this statement clearly indicates that we need to grab the data, but that last phrasehave access to our data with as little downtime as possibleadds something important.In order to accessour data, we need the OS and associated applications to be up andrunning! A data backup is useless without an application and OS to restore it to. Ive alreadyexplained why rebuilding a server using the installation media is so slowyou have to

.perform lengthy installs, then install service packs and patches, and thenrestore your data

This tells me, then, that our backup mustbe of the entire server. After all, Im not just hereto archive my dataI also need to be able to restore it quickly, and get access to it quickly,and that means I need to restore the OS and any applications quickly. So regardless ofpracticalityfor nowIm going to say that backing up theentireserveris the only way to

go. I just need to figure out how to do it quickly.

WhenDoYouBackUp?

How often will I be making backups? Under Backup 1.0, this was a real question. Often, youmight take a full backup during an evening or weekend maintenance window, then grabsmaller backups more frequently. When I started out in IT, I was an AS/400 operator.Every evening, we made tape backups of our most important data files from the AS/400; onweekends, we ran a full backup of the entire system. Backing up the data files took a fewhours, and we had to do it in the evening after pretty much all the work for the day wasfinished because the data was unavailable while the backups were running (in fact, wepretty much kicked everyone off the system while backups were being done). The weekend

full backups could take a full day, and everyone had to be offline then.

But maintenance windows are a Backup 1.0 concept, so lets disregard them. In fact, letsreview our whole reason for being here one more time:



15/27

Chapter 1

11

Right there is my answer: from losing anydata or losing anywork. That tells me theBackup 1.0 method of pointintime snapshots is useless because no matter how often Immaking incremental or differential backups, Im still going to be at risk for losing someworkor data, and thats not acceptable.

So if you ask, When will you make backups? I have to answer Always. Literallycontinuous backups. In fact, the industry already has a term for it: continuousdataprotection.Although specific techniques vary, you can think of thisvery roughlyasbeing similar to RAID 1 drive mirroring. In a RAID 1 array, as Figure 1.4 shows, the drivecontroller writes blocks of data to two (or more) hard drives at once. Disk 2 is a complete,blocklevel backup of Disk 1. Restoring is fastsimply swap the two if Disk 1 goes bellyup.

Figure1.4:RAID1diskmirroring.

Of course, RAID 1 is good for a certain type of scenario but it isnt practical for all situations,and it doesnt meet all our backup requirements. For one, server disks are still prettyexpensive. In a server using a large number of disks, mirroring every one of them isntpractical. Some organizations will set up a RAID 5 array and then set up a second array tomirror the firstbut that can be incredibly expensive. A further problem is that the backupdisks coexist with the primary disks, so the backup disks are still at risk for damage due tofire, flood, and other physical threats. Further, a mirror is only a backup for the currentcondition of the primary disk: You cant roll back to a previous point in time. So mirroringalone is a great tool for certain situations, but it isnt a complete backup solution. What it is,though, is a good idea for how to make continuous backups. We just need to leverage thetechnique a bit differently.

WhatTypeofBackupWillYouUse?Full backup? Differential? Incremental? I have to say none of these because those Backup1.0 terms are associated with pointintime snapshots, and were not going to use those.Instead, were going to use a Backup 2.0 technique, borrowing from the RAID 1 concept ofblocklevel mirroring. Part of continuous data protection, well call this block-levelbackups.Figure 1.5 shows how it might work.


16/27

Chapter 1

12

Figure1.5:Agent-basedblockbackups.

Here, a software agent of some kind runs on the server. As blocks are changed on disk, thisagent transmits those blocks to a backup server, which stores them. That server mightstore blocks for many different servers. The agent would likely tap into a very low level ofthe OS to accomplish this. The benefits:

ll changes, as they happenWe can have nearly realtime backups of a

We get the entire server, not just the data

We can store more than just the currentblocks; in fact, we can store changes as farback as we want, meaning we can restore any given filewhich consists of multipledisk blocksto any point in time we want

We can restore the entire server by simply writing all the latest backedup blocks toa servereither the original server or a replacement

In the event of corrupted blocks, we might still be backing those upbut weve alsogot older, noncorrupt versions of those same blocks, so we can potentially repairfiles that have become corrupted to their most recent, noncorrupted point in time

This is powerful magic, but its a reality: Todays market includes solutions that follow thistechnique. It delivers Backup 2.0: continuous backups thataredesignedforrestores,not forarchiving.


17/27

Chapter 1

13

WhereDoYouStoreBackups?

Do you need offsite storage of your backups? Probably yes. In 1996, Parisbased CreditLyonnais had a fire in their headquarters. Administrators ran into the burning building torescuebackuptapesbecause nothing was stored offsite. Let me write that again: Ranintoaburningbuilding.Folks, fire is a constant possibility, as is the possibility of damage from

floods (bad plumbing anyone?) and other disasters. If the data is worth backing up, itsworth keeping copies somewhere else. At the very least, have some sort of onsite storagethats disasterproofa waterproof fire safe, for example. Does that mean you have to usemagnetic tape? No, but you probably will, simply because its relatively inexpensive, fairlydurable, and easy to work with. Youll likely end up using tape in conjunction withsomething else, in fact, with tapes being the sort of lastresort place to restore from. Thepoint is this: Dontassumethatamajordisasterwillnotstrikeyou.Past performance isno guarantee of future results; just because youve never been hit by a disaster beforedoesnt mean you wont be hit by one eventually. Thats why people buy insurance policies,and backups are basically a form of insurance.

In terms of Backup 2.0, we might combine our blockbased backups with some tapebasedstorage. Our backup server, for example, might periodically dump all its backedup blocksto a tape array, allowing us to carry a snapshot offsite for archival purposes and to protectagainst a total disaster to our data center.

ShouldYouTestBackups?

This is a trick question. The answer is, Of course. As Ive already explained, though, fewfolks actually do. Why? Well, there are really a few reasons, many of which are related toour Backup 1.0 mindset.

First, as I mentioned earlier, is the time commitment. Spending hours doing a test restoreisnt in most folks budgets these days. Of course, a blockbased restore can actually bedone more quickly: Youre streaming the restore from disks over a highspeed network, notreading them eversoslowly from a tape drive.

Second, theres the availability of hardware. Now, if youre testing singleitem recovery,most backup solutions will allow you to restore files to any location you want, so you justneed a small spot on an existing file server. But you should also be testing fullon disasterrecovery, where you restore a server that was completely lost (say, to fire) to a differentpiece of hardware. The problem is that many Backup 1.0style solutions require you torestore to identical hardware, meaning you have to have a lot of spare servers around. Notgonna happen. A good solution will let you restore to dissimilar hardware, which is actuallymore practical from a disaster recovery perspective; an ideal solution will let you restore to

a virtualizedserver, which is absolutely perfect. So yes: Test your backups. Regularly.Perform both singleitem restores and the type of baremetal restore youd associate with atotal disaster, ideally utilizing modern virtualization technologies to eliminate or reducethe need for extra test restore hardware.


18/27

Chapter 1

14

Virtualization:MorethanJustConsolidation

As Ill discuss in later chapters, virtualization is an integral part of the Backup2.0 mentality. In Backup 1.0, a fullsite disaster might mean retreating to a

specialpurpose, leased offsite recovery facility and starting a lengthy restoreprocess using your most recent offsite backup tapes.

In Backup 2.0, that facility might live on the Internet and consist of one ormore virtualization hosts, each running a dozen or so virtual servers. Youstream your latest backups over the wire to the virtual servers, performing abare virtual metal recovery rather than recovering to actual, physicalmachines. This approach makes it more practical to recover a set of servers,makes that recovery faster and cheaper (no leased facilities), and makes itmore practical to conduct occasional test runs of a complete disasterscenario.

AreYou

Keeping

an

Eye

on

Your

Backups?

Do you monitor your backups? Other than just checking an error log, I mean? You should.In fact, checking error logsaside from being incredibly boringis the kind of oldschoolBackup 1.0 mentality Im trying to change in this book. A modern, Backup 2.0style solutionshould alertyouto problems, and ideally might even integrate with an existing monitoringsolution, such as Microsofts System Center Essentials or System Center OperationsManager.

What might those alerts actually inform you of? Primarily, problems with the backupsthemselves, such as corruption. Nothings worse than suddenly finding you needyourbackups and then realizing that theyre no good due to corruption; you should be informed

of corruption as soon as it occurs. A good Backup 2.0style solution might inform you viaemail, might drop something in a Windows event log (which System Center OperationsManager could then pick up and raise to your attention), or perform some similar style ofnotification.

Figure 1.6 shows how System Center Operations Manager can be used to configure an alertfor a given type of event log entrysuch as an event log entry created by your backupsolution, alerting you to corruption. Note that System Center Essentials works similarly forthis type of alert.


19/27

Chapter 1

15

Figure1.6:

Creating

an

event

log

entry

alert

in

SCOM.

A really with it backup solution might even come complete with a System CenterManagement Pack. A Management Pack is basically a preconfigured set of rules formonitoring and alerting on a specific application; the pack tells System Center OperationsManager what to look for (such as specific event log IDs) and what to do (such as sendingemail alerts). But if your backup solution doesnt come with a Management Pack, at leastmake sure that it has its own builtin features for providing these types of notifications.


20/27

Chapter 1

16

ApproachestoBackingUpHaving advocated for blocklevel backups, I want to take a step back and briefly review theentire gamut of backup possibilities. Although some of these dont meet my requirementsfor a good backup andrecoverysystem, they nonetheless offer some business value that

you should be aware of.

FileBasedBackups

Filebased backups are the oldest type of backup, and probably still the most common. Itinvolves simply taking a snapshota pointintime copyof one or more files. These typesof backups may have difficulty working with open files, and they dont capture everychangemade to a filethey just grab a copy of it at a specific time.

But theres value here. For example, Windows builtin Volume Shadow Copy feature isessentially an onserver filebased backup, grabbing copies of files as users change themand storing them in a local cache on the server. Users can access these cached fie versions

on their own, using Windows Explorers Previous Versions feature, as Figure 1.7 shows.

Figure1.7:Accessingpreviousversions.


21/27

Chapter 1

17

The key phrase here is ontheirown.Unlike many data centerclass backup solutions,Volume Shadow Copy / Previous Versions is designed for user selfservice. Properly used(meaning your users will need a bit of training), this feature can help prevent calls to theHelp deskand overhead for youwhen users need to roll back a file to a somewhat olderversion. In fact, Ive seen this featureagain, with a bit of enduser trainingreduce

singlefile recovery Help desk calls by 90% in several of my clients. Those organizations tellme that the average cost for completing a file recovery request is about $75, and the onesthat keep really good records average about four calls a week. Thats a savings of more than$15,000all for free, since the feature is builtin to Windows (well, you do have to spend abit extra for the disk space needed to store the cache).

In a Backup 2.0 world, there should be room for complementary solutions. PreviousVersions meets a specific need: user selfservice for individual file rollback. Whatever datacenter backup solution you select shouldnt interfere with complementary solutions, and infact, should embrace them. Where filebased backups tend to fall shortas Ivediscussedis in the wholeserver backup scenario, which youd be performing in the data

center.

ImageBackups

Image backup is another term for what Ive been calling blockbased backups. There arereally two ways to achieve an imagestyle backup: by using solutions such as the triedandtrue Ghost software and via what Ill call streaming images.

Software such as Ghost and its many competitors make pointintime snapshots of a disk,typically compressing the disk blocks so that the resulting image file is much smaller. Thissoftware isnt usually positioned as a backup and recovery solution but rather as adeployment solution: You make a template computer the manual way, image it, and thendeploy that image rather than installing other computers manually. Its most commonly

used for desktop deployment, and it can serve as a kind of lastditch recovery tool fordesktops, essentially redeploying the image to get a machine back to square one. But as apointintime snapshot, its not useful for capturing data, changes to applications, and soforth.

Another weak spot is that snapshot imaging software usually requires the source computerto be unavailable. Typically, the image is captured using a preboot environment (like theone shown in Figure 1.8)a sort of strippeddown OS that runs in lieu of Windows. Thisensures that none of the files on disk are open and changing so that a single, consistentsnapshot can be gained. You can see where this would be a bit burdensome as a continualbackup technique.


22/27

Chapter 1

18

Figure1.8:Ghostspre-bootenvironment.

Streaming images are the kind of blockbased backup I illustrated in Figure 1.5, earlier inthis chapter. This technique is the basis for almost realtime, continuous data protection ofmultiple servers. You could use the technique with desktop computers, too, although I

suspect doing so wouldnt be practicalit would involve a lotof backup data flying aroundyour network, not to mention a lot of storage. No, I think this technique is really gearedbest for the data center, where youre backing up servers and where you can easily set uphighspeed or even dedicated network connections between those servers.

ApplicationSpecificIdeas

Some applicationsprimarily missioncritical, alwayson applications such as MicrosoftSQL Server and Exchange Serverpresent their own challenges for backup and recovery.These applications executables are always running, and they always have several data filesopen, making it difficult for filelevel backup software to get a consistent snapshot.


23/27

Chapter 1

19

To help address this, the applications designers take varying approaches. SQL Server, forexample, has its own internal backup and recovery capability, which is tied to the productsown unique architecture. Traditionally, the best way to get a SQL Server backup is to askSQL Server to do it. You might, for example, use SQL Servers own tools to produce a backupfile, then grab that file with a traditional filebased backup solution. Or, you might create an

agent that taps into SQL Server and gets the data that waythe approach used by mostenterpriselevel, Backup 1.0style backup solutions. Figure 1.9 shows a common dialog boxfor a backup solutions configuration, showing that a SQL Serverspecific agent is loadedand able to stream data from SQL Server to the backup software. Exchange Serverfunctionality might work similarlyin fact, you can see that tab in the figure as well.

Figure1.9:Application-specificbackupagents.

Exchange Servers developers took a slightly different approach, choosing to integrate withWindows Volume Shadow Copy service. Essentially, they provide a copy of the Exchangedata files through Volume Shadow Copy; a backup solution simply needs to access theVolume Shadow Copy Application Programming Interfaces (APIs) and request the latestcopy of the database. Again, its Exchange Server thats doing most of the work, but adedicated agent of some kind is usually needed to get to the right APIs. As Figure 1.10shows, even Windows Server 2008s builtin backup can be extended to see the ExchangeServer databases.


24/27

Chapter 1

20

Figure1.10:BackingupExchangeServerinWindowsServerBackup.

The downside is that these applicationspecific approaches are still Backup 1.0 in nature,meaning theyre grabbing a snapshot. Youre still at risk for losing data and work thatoccurs between snapshots; particularly with these missioncritical applications, I thinkthats just unacceptable.

Blocklevel backups can certainly solve the problem because theyre grabbing changes atthe disk level and dont particularly need to understand what those disk blocks are for. Adisk block thats part of a file looks the same as one thats part of a SQL Server database, sothe backup solution just grabs em all. But from a recoveryviewpoint, your backup solutiondoes need some additional smarts. Heres why: A simple filesay, a Word documentconsists of several blocks of disk space. Its easy to keep track of which blocks make up anygiven file, and no disk block will ever share data from two files. If you need to restoreSalaries.xls, you figure out which blocks that file lives on, and restore just those. Easy.


25/27

Chapter 1

21

With complex data storessuch as SQL Server and Exchange Serverthings arent so easy.A single mail message might occupy multiple blocks of disk space, but those same blocksmight also contain data related to other messages. The database also has internal pointersand indexes that need to be restored in order for a given message to be accessible. So ablockbased backup doesnt need much in the way of extra smarts to makea backup, but it

will need some cleverness in order to restoresingle items from that backup. Solutionvendors tend to approach this by using plugins: Its easy to think of these as being similarto the Backup 1.0style agents, but theyre not. These plugins dont necessarily assist withthe backup process (although they may record special information to assist withrecoveries), but they do contain the smarts necessary to peer inside complex data storesto recover single items.

OurBackup2.0WishListThe following list highlights desirable capabilities in a Backup 2.0style backup solution:

Continuous data protection thats always on, always working, and as close to realtime as is practical

The ability to move snapshots of my backups to tape (or other portable media) foroffsite storage

The ability to restore anything from a single file to an entire serverquickly, and todifferent hardware (or virtual hardware) if needed

Blocklevel imaging that provides the ability to roll back to any point in time andkeeps backups physically separate from the source

Automatic notifications of problemssuch as corruptionwith the backups

Doesnt interfere with complementary solutions such as Windows own VolumeShadow Copy feature

The ability to easily test restores, from a single file to a complete disaster, ideallyusing dissimilar hardware or virtualization

The ability to restore single items from complex stores like SQL Server or ExchangeServer

Ill add a few things to this list as we progress through the upcoming chapter, but this is agood start. It represents everything that the Backup 2.0 philosophy is all about, and itmeets all the implied requirements in our businesslevel statement:



26/27

Chapter 1

22

WhatsAheadIve got a full plate coming up for you, starting with the next chapter in this book, where Iget to share some of the horror stories Ive run across with my consulting clients, in thenews, and so forth. Its kind of interesting to see the problems others have had, but it can beinstructional, too: Ill examine each case and draw conclusions about what went wrong and

what you would need to do to avoid that situation.

Chapter 3 is where Ill dive into the actual technology of wholeserver backups. This is anarea where I think Backup 2.0 really has some immediate benefit, but Ill start byexamining more traditional wholeserver backup techniques and identifying things thatdont always work so well. If youre responsible for backing up domain controllers,infrastructure servers, Web servers, a public key infrastructure, or similar servers, thenthis is the chapter for you.

In Chapter 4, Ill tackle the tough topic of Exchange Server backupstough enough that thebackup software that shipped with Windows Server 2008 couldnt even do it. Again, Ill lay

out some of the more traditional ways that Exchange backups have been made, and thenrethink the process and come up with a wish list of backup capabilities that include severalExchangespecific concerns. Chapter 5 will follow the same approach for SQL Server, andChapter 6 will examine SharePoint in the same way.

Chapter 7 will be a bit of a departure, as Ill focus on virtualization server backups. This isstill a relatively new field, and Ill look at ways in which traditional backup techniques arebeing used and examine how well theyre actually getting the job done. Ill cover some ofthe unique aspects of virtualization backups and examine innovative techniques thatBackup 2.0 can bring to the table.

In Chapter 8, Ill pull back a bit for a broad look at other backup concerns and capabilities:

Baremetal recovery, data retention concerns, compliance and security issues, mobileinfrastructure problems, and so on. Ill also look at instances where oldschool backupsmight still provide some value, and Ill offer advice for integrating Backup 2.0 with moretraditional techniques.

All of the backups were making are going to require some serious storage, so Ill useChapter 9 to focus on storage architecture. Ill look at how backup data is structured, andcompare the advantages and disadvantages of things like storage area networks (SANs),tape drives, local storage, and so forth, and examine pressing issues of storage:compression, encryption, security, deduplication, and so on. Ill also look at unique waysthat Backup 2.0 allows you to interact with your backedup data more easily and efficiently.


27/27

Chapter 1

Chapter 10 will focus on disaster recoveryand I mean realdisasters. Ill look at things likebaremetal recovery, and Ill cover some of the more interesting capabilities that todaystechnologies offer, such as using virtualizationrather than dedicated offsite facilitiesaspart of a disaster recovery plan.

Chapter 11 is for all the businessminded readers out there; this chapter is where Illdiscuss the costs involved in rearchitecting backup and recovery to use Backup 2.0techniques. Naturally, Ill also help you determine whether doing so is actually worth it toyour organization, and even tackle some of the nontechnicalwhat I like to callpoliticalissues that you may have to solve in order to make your backup situation moremodern and efficient.

Finally, Chapter 12 will be the chance for me to share stories from my own experienceswith Backup 2.0a sort of tales from the trenches chapter, with case studies thatdescribe successes (and challenges) Ive seen with Backup 2.0.

We have a long journey ahead of us, but youve made a good start. I look forward to seeing

you again in the next chapter.

Date post:	04-Jun-2018
Category:	Documents
Upload:	dcenzi
View:	220 times
Download:	0 times

Windows Backup

Documents