Exchange Server 2010 Backup and Restore

Question

Hai,
I have Exchange server 2010 stand alone server combined with mailbox, hub and cas role. i dont have backup application program. I want to take my exchange database backup to my SAN storage automatically everyday...
Using windows server backup i can take full backup only and i can schedule it to happen daily.. Is it possible can i take incremental backup??????????for exchange 2010 database.
Thanks Chandru CT. MCITP

Answer 1

You have two basic options to backup Exchange 2010, VSS snapshots and "native backup" (meaning a Lag copy).  As far as VSS backups go, there are three components; the VSS Writer, the VSS Provider, and the VSS Requestor.  The Writer is built into
Exchange.  In fact in Exchange 2010 there are two - the Exchange VSS Writer and the Exchange VSS Replica Writer.  The provider can be a software VSS provider such as the Microsoft Shadow Copy provider or a hardware provider (usually supplied by your
SAN vendor.  The requestor is what you would tend to think of as the backup application; it coordinates activities between the Writer and the Provider.
As far as the Exchange 2010 plugin for Windows backup goes, it a very minimal requestor.  It only supports the Exchange 2010 VSS Writer, not the Replica Writer.  This means you can only take backups of the Active copy of a database.  The requirement
to backup the entire "volume" in the windows sense, or partition to the rest of us is a function of the way VSS works and is no real surprise.  In fact, another limitation of VSS is that the logs and database need to be on seperate volumes: see
http://technet.microsoft.com/en-us/library/ee832794.aspx. 
That it only takes full backups makes sense as well.  Shadow copies, like many software providers and many hardware providers out there are copy on write.  Initially, after the first one that is, they take up minimal space for some metadata. 
As data is writen to the volume while the the snapshot is in place, the original blocks are evacuated to a "difference area" and the write is then written to the newly evacul\ated spot.  You can generally put the difference area on the same volume or
somewhere else.  The downside is to write a block while a copy on write snapshot is in place means a read and two writes for every write.  This gets ugly on RAID 5 which already has a write penalty of 4; that turns into 9 IOs for every write while
the copy on write snapshot is in place.  Since you can't do the snapshots on the replica because the replica writer isn't supported, that IO hit is on the active copy.  When using copy on write snapshots, you generally want as few around as possible
for as short a time as possible; usually just long enough to export or copy the snapshot to another set of spindles.  I really wouldn't want to use WSB plugin for Exchange 2010 in anything but the smallest deployments.
What about native backup?  Well then you take a 100% space hit for every lag copy.  In addition, restoring a LAG is a one shot deal.  As you strive with the LAG to match what you could achieve with even daily or weekly copy on write snapshots,
the number of database copies, and Exchange mailbox servers,  poliferates.  You may want to consider a "Happy medium" that combines a LAG for fault tolerance/protection against logical corruption with copy on write snapshots (replicated or copied
to seperate storage) for HA.  Perhaps DPM would be worth a look in your situation.
You did mention that you have a SAN.  Most SAN vendors offer hardware VSS Providers.  Many are copy on write, and you shift that set of problems to the, albeit likey a bit more performant SAN, Some vendors use other stratagies.  The vendor
I work for uses allocate on write, so it avoids the 3 IOs per write copy on write penalty while a snapshot is in place.  This means you can snapshot frequently and keep many of them around without penalty shortening your RPO and RTO.  They optionally
archive truncated logs allowing for "up to the minute" restore of older snapshots, not just the last one.  They also provide a proprietery version of RAID 6, called RAID DP that outperforms RAID 1.  Combine that with all the storage efficiency features
like dedupe of primary storage, thin provisioning, compression, etc., that can all be combined and it starts to get compelling as the size of your deployment increases.  Although I might be a bit biased when it comes to SAN vendors, if your SAN is someone
other than NetApp I still encourage you to talk with your SAN vendor and see what features/functionality they offer that can help you address your backup needs for Exchange 2010.  I think you'll find much to like; it really comes down to scale and a cost/benefit
analysis.
If you decide that hardware VSS providers are not you thing and want to stay with a software vss provider, I encorage you to talk to the usual backup software vendors as well.  Many can integrate with DAS and/or SAN, and have their own software
VSS providers often including support for the Exchange 2010 replica writer.  This at a minimum allows you to snapshot passive copies.  Features like replication (to get the changed blocks to other storage or off site), tape support (to roll backups
off to tape potentially to store off site) and catalogs come to mind as very useful things to have.
I'd take a look around at what's available and see if any of the things offered meet your business needs at a price you can afford to pay.  The WSB Plug-in is a bare bones sort of thing, and it only gets better from there.
J