|
Home > Archive > 70-081 Exchange 5.5 > February 2001 > Are you having problems understanding 70-081 Recovery Read this!!
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Are you having problems understanding 70-081 Recovery Read this!!
|
|
|
| I was looking around on TecNet and I found this from the MS Exchange Documentation http://www.microsoft.com/technet/ex...h17.asp?a=frame :
Steal this white paper
Microsoft has prepared a terrific 84-page white paper titled "Exchange Disaster Recovery." It was originally written for Exchange 4.0 by a group from Microsoft Consulting Services; since then, it's been updated several times and is still the canonical source of disaster recovery knowledge. One reason it's so long is that it consolidates in one place much of the information spread throughout this book.
Stop reading this book right now and go get the white paper; it's available from http://www.microsoft.com/exchange/t...ckupRestore.htm . Once you've got a copy, come back and resume reading; I'll be making reference to the white paper throughout the rest of this chapter, and it's a very handy reference to keep right next to each of your servers.
I suggest you have a look at it since it covers all that can be asked of you in the exam 
Yeti the Exchange Doctor 
-------------------------
MCNE, MCPx5, SCO ACE, LCP, Compaq ASE, CCIE Wannabe (part of the Wannabe Boffin Club).
www.yetigbr1.plus.com or www.mcse2000.plus.com or www.mcse-2000.org & www.mcse-2k.co.uk
MCSE2000 Forum http://pub34.ezboard.com/bmcse200067298
Mailto: yeti@zerg.com
[This message has been edited by Yeti-GBR1 (edited 02-09-2001).] | |
|
| I also found this:
Estimating recovery time
To know how long it'll take to recover your system, you first must know how long it will take to physically move your backed-up data to the recovery system. Once your store gets bigger than about 5GB, recovery time is driven primarily by the speed of your I/O subsystem. Even with a Fibre Channel RAID array, an 18GB file copy between two separate controllers and disk arrays can take more than an hour. Over a 100Mbps switched full-duplex network, a 16GB file copy time still takes around 90 minutes. When you consider the sad fact that restoring data takes at least as long as backing it up, and that running the Exchange utilities can push the total recovery time to twice as long as the original backup requirement, knowing how long things take is critical.
It's prudent to establish a baseline for the speed of your network and servers. I recommend the following tests, using at least a 2GB store file:
If you intend to run eseutil or isinteg on the same disk partition as the databases, do a disk-to-disk copy on that partition.
If your system has multiple controllers, do a disk-to-disk copy between the two controllers on one server.
Do a disk-to-disk copy between two unique servers; this will tell you what sort of network throughput you can reasonably expect during a restore.
Back up your stores from disk to tape using your backup software. For best performance, put your tape drive on a different controller than your database disks. With some systems and backup software, local backups will be faster than doing backups over the network; on others, CPU load and other overhead will actually make a local backup slower.
Back up your stores from their home on one server to a tape drive on another. This offers you superior flexibility when it's time to restore, since you aren't limited to restoring onto a machine with a tape drive.
These tests take time to run, but one late night or Saturday spent doing them provides real-world data on how long restores will take in your environment. These tests will tell you how long it takes to restore the data, but not how long it takes to play back the log files. There's no really good way to estimate that, since many short transactions take longer to play back than an equal-size block of a few large transactions.
Tip Note that these tests may show that your I/O system isn't well optimized for copying large files. That's okay, since most Exchange I/O is made up of small (4KB to 64KB) requests. See Chapter 18, Managing Exchange Performance, for more details.
One interesting note: Exchange 5.5 has been tuned to make the database backup APIs significantly faster. Microsoft claims that Exchange supports speeds up to 30GB/hour, so if you can't back things up that fast the problem is likely that your backup hardware can't keep up.
Yeti
[This message has been edited by Yeti-GBR1 (edited 02-09-2001).] |
|
|
|
|