<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>The Geek Diarys &#187; microsoft</title>
	<atom:link href="http://paior.com/tag/microsoft/feed/" rel="self" type="application/rss+xml" />
	<link>http://paior.com</link>
	<description>The random thoughts from another geek</description>
	<lastBuildDate>Wed, 05 Oct 2011 04:04:54 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>Disaster Recovery</title>
		<link>http://paior.com/2009/03/11/disaster-recovery/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=disaster-recovery</link>
		<comments>http://paior.com/2009/03/11/disaster-recovery/#comments</comments>
		<pubDate>Tue, 10 Mar 2009 15:03:59 +0000</pubDate>
		<dc:creator>paior</dc:creator>
				<category><![CDATA[Rant]]></category>
		<category><![CDATA[Technical]]></category>
		<category><![CDATA[adelaide]]></category>
		<category><![CDATA[australia]]></category>
		<category><![CDATA[backup]]></category>
		<category><![CDATA[backups]]></category>
		<category><![CDATA[disaster recovery]]></category>
		<category><![CDATA[microsoft]]></category>
		<category><![CDATA[sbs]]></category>
		<category><![CDATA[sbs2003]]></category>
		<category><![CDATA[small business server]]></category>
		<category><![CDATA[south australia]]></category>
		<category><![CDATA[virtualisation]]></category>

		<guid isPermaLink="false">http://paior.com/?p=42</guid>
		<description><![CDATA[There is no doubt that the fastest way of getting a server backup and running is via virtualisation. ]]></description>
			<content:encoded><![CDATA[<p>I thought I would start my return to the blogosphere with a post about how I think DR plans should be constructed.</p>
<p>I recently posted to the SA SBS User&#8217;s group about an alternative way of thinking about server imaging. I think some people got it, and some didn&#8217;t. I didn&#8217;t want to ruffle any feathers or anything silly like that, It&#8217;s just that obviously sometimes I don&#8217;t make my self clear.</p>
<p>A poster asked what imaging product provides the fastest recovery in the event of a meltdown for SBS2003.</p>
<p>I based my answer on the following assumptions:<span id="more-42"></span><br />
1: the server was nearing the end of it&#8217;s productive life (SBS2003 was superseded about 4 months ago)<br />
2: The user has some form of off-site backup already (I nearly die when people even suggest that an off-site backup is not an ABSOLUTE MUST!!!!!) Don&#8217;t make me rant about this now.<br />
3: The user was only now getting nervous about the possibility of a &#8220;server meltdown&#8221;.</p>
<p>I try to base my DR planning on scenarios. Scenarios, in order of likelihood based on my experience is as follows:<br />
1: User deleted files / corrupted files<br />
2: Power supply failure in server<br />
3: Hard disk failure in server<br />
4: Operating system corruption<br />
5: Theft of server (AND ALL BACKUP TAPES / DEVICES)<br />
6: Fire / destruction of premises. (This has only ever happened once)</p>
<p>There is no doubt that the fastest way of getting a server backup and running is via virtualisation. I doubt anyone who thinks otherwise would have had much experience with virtualisation. My concept of using VMconvert and then restoring the current data set via conventional tape or file based backup means seems to be somewhat lost in the physical old school thinking.</p>
<p>The fact is that once you start getting your head around virtualisation then you cease to think of a server as being anything other than a commodity, much like petrol for your car. You start to realise that the LAST place you want to store data is the same place as the computer that serves it to you. In all but the most budget conscious sites (and this is where I go wrong arguing with the SBS Users crowd) flat files should be stored on some form of NAS or SAN device that has adequate redundancy built in. People who can&#8217;t get their heads around this concept will be left behind as everyone else moves onto the cloud.</p>
<p>I do agree however, that when you have a server onsite, imaged based backups are here to stay, but they can&#8217;t be the only backup.<br />
For SBS Server installations, running a core accounting application, such as MYOB I recommend the following.</p>
<p>1: BACKUP THE MYOB / PRIMARY APP DATA<br />
This is achieved via one of two ways:<br />
a key user uses a high capacity USB &#8220;thumb drive&#8221; and manually backs up the data. This thumb drive leaves the site daily. For SQL servers a flat file based &#8220;Cold backup&#8221; or scripted &#8220;hot backup + transfer&#8221; is used. The scripts are easy to write and run. Generally this will be the business owner or key accounts person.<br />
or<br />
If the key person is unreliable, we recommend an automated Internet based backup for this critical data.<br />
The key thing here is GET THIS DATA OFF SITE.</p>
<p>Most small businesses would be happy to leave it there. and in the event of major data loss, if they had even just that one thing, the business would survive.</p>
<p>2: Daily backups using an imaged based product.<br />
Weekly full + daily incremental is recommended.<br />
Really what you want here is to have a quick backup / restore routine that is used if someone accidentally deletes a file and you haven&#8217;t bothered to switch on shadow copies or in the event of catastrophic hard disk or raid failure. This backup never leaves the site, as typically you would do this to 3.5&#8243; hard disks and they tend to be too fragile. Also the full + incremental routine (needed because USB2 is soooo slow) gets confused when you start swapping drives around. We use Acronis for this.</p>
<p>3: Daily complete backups of DATA &#038; METADATA ONLY<br />
To a large capacity tape medium. People who think tapes are dead (I was one of them) haven&#8217;t seen the recent advances (and price drops) in the new media formats. LTO/Ultrium absolutely kicks arse right now in terms of price and performance and to be able to backup your data at full SAS performance can&#8217;t be beaten. Use a real software product here, something that replaces Microsoft&#8217;s RSM (note other than RSM, there is nothing wrong with NT backup). We use Symantec Backup Exec. Backup Assist seems to be just as good, just the price advantage they once had has now been eroded with Symantec&#8217;s OEM program.<br />
The only time you will use this backup is in the event of theft or fire. (More common than you might think)</p>
<p>4: Run a &#8220;once off&#8221; or &#8220;infrequent&#8221; VM convert. Store this machine on a fast desktop computer with the VMServer installed but completely disabled. In the event of a &#8220;Melt down&#8221;, you can plug your USB 3.5&#8243; drive with your onsite backups straight in, and other than a short amount of time to restore your files / key DB&#8217;s (sharepoint, systemstate, exchange) you are up and running instantly. If you are running OEM versions of SBS2003 you then have 30-60 days to replace the broken bits in your old server or even better convince the customer to move to SBS2008 on a new system.</p>
<p>4 Key rules:<br />
Have a written disaster recovery plan, write into it your acceptable down times based on the likely scenarios.<br />
Always have a backup of your data off-site.<br />
Monitor, check and TEST your backups.<br />
Don&#8217;t buy crappy hardware to begin with.</p>
<p>If your customer doesn&#8217;t agree to your terms, make them sign a waiver explaining that they are acting against your advice.</p>
]]></content:encoded>
			<wfw:commentRss>http://paior.com/2009/03/11/disaster-recovery/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

