RE: Please some one help me, no one reply-why ?Good one!!
- From: Rick Boza <rickb@xxxxxxxxxxxxxxx>
- To: Exchange List <exchangelist@xxxxxxxxxxxxx>
- Date: Fri, 01 Jul 2005 09:41:27 -0400
Hah! I always keep a resume ready, whether I think I know what I am doing
or not! That really ought to be listed as a ?best practice¹ somewhere.
So you¹ve made me get up onto my soapbox a bit having spent several years
working on backup software, I have some pretty strong opinions on
backup/restore as well as the different levels of recovery required so I¹m
going to rant a bit and hopefully some will find it useful. If not, just
delete me.
Backup and Recovery planning is actually fairly straightforward these days.
Do a full backup every night if you can afford to it minimizes the number
of tapes used in a restore, which is always a good thing. Avoid incrementals
if you can, but if not, understand their impact on your recovery process.
Build your backup strategy and your database strategy hand in hand and
base them both on the amount of time you want to spend restoring, not
backing up. If you can restore 10 GB per hour, and have a 4-hour SLA in the
event of database failure, I suggest trying really, really hard to limit
yourself to 20GB of store. The reasoning is you¹re going to spend an hour
dickering around trying to avoid the restore, then 2 hours to restore, then
another hour to play with the database if something didn¹t work quite right.
With E2K3, you can probably trim that a bit and grow the databases a bit,
because the restore and recovery is much more robust than in earlier
versions of Exchange meaning ESEUTIL is used less often following a
restore of a good backup.
On that note, TEST your backup tapes. I know for a fact that those backup
programs, which report a successful verify, well, they lie sometimes. Not
intentionally (as far as I know) but they think you have good data when
really what you have is goo. So test your restores and be comfortable with
the process.
As for disaster planning, you hit on some very good points defining what
is a disaster to your organization being a key question.
For DR planning, you definitely need to know exactly what you have in your
environment, and what your expectation is around getting things back on
line. Each system is different, and the bigger the more complex the
planning needs to be. I agree that keeping AD as a separate system (and
also on the minimal of two for redundancy). You also need to understand
what is involved in an AD restore if you have a failure as well as when to
restore! Two servers means you¹re not restoring AD unless you need an
authoritative restore for some reason but now I¹m getting into a slightly
different topic.
I could talk about DR for a very long time, but I¹m starting to even bore
myself. If anyone wants to discuss that, feel free to email me offline and
I will rant some more privately ;)
Rick
On 7/1/05 2:39 AM, "Praveen Ramaswamy" <ramaswamy_praveen@xxxxxxxxx> wrote:
> http://www.MSExchange.org/
> Good one Rick, now i started wondering which category i belong to :)
>
> Any ways i don¹t think users in ADS needs to be removed to restore a Exchange
> server. It is always recommended to have ADS and Exchange separately. If you
> have both Exchange and ADS on the same box then you better first define what
> disaster means to you. If the OS crashes then you have to re-install whole
> thing.
> If you have ADS and Exchange separately then you need to restore only Exchange
> server.
>
> At minimum it is good to have two ADS servers and one separate exchange
> server.
>
> Please correct me if I am wrong. This will help me modify my recovery plan
> incase of any problem. Because I don¹t even have a resume ready.
>
> Regards
> Praveen R
Other related posts:
