As I stated earlier, we need to differentiate between
object restores (via lag sites) and true DR (which the MS paper deals with).
Restoring a user differs to the restoration of a DC, which differs again to the
restoration of a domain and/or forest.
Objects can be restored using 3rd party tools (which back
up the database and all attributes regularly) and/or via lag
sites.
True DR needs (IMO) a separate physical location, separate
physical machines along with DR processes and technologies.
Requirements need to be gathered so that the optimal
solution can be found.
What are you trying to achieve?
neil
PS I tried to curb my habit of waffling :)
PS I tried to curb my habit of waffling :)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of PAUL MAYES
Sent: 08 March 2006 13:13
To: [email protected]
Subject: RE: [ActiveDir] AD Lag Sites
</lurker>
Hi All,
Forgive me a second whilst I ramble on 'cos this IS going to be a
ramble, then shoot me down in flames at the end!
The problem with DR is getting the data from somewhere. Typically we go
back to tape, which depending on when the last successful backup took place
gives you a bit of a wide window to play with. Not good if you're going back
some 24 hours/days etc...
To get better coverage of times we kicked about with lag sites. Trouble is,
and this has already been noted, replication and timings can scupper the
intentions of lag sites and where do you stop. Is one enough, is one for every
hour of the day enough?
Microsoft released this white paper on fast recovery with AD using SAN's
and disk imaging.
Now, I'm currently playing with using Microsoft's in-built disk
snapshotting to provide something similar. So on a pure DC server I've set it up
to snapsnot it's disks every hour. And then I get to chose which hour that
I go back to and use as my recovered backup. After all it's the same tech that's
used when you actually do a backup.
No need for a lag site, just pick the hour on the timeline and restore from
that DC. Ok so it means that you might need bigger disk and you can only
snapshot down to 30mins. But if you're a bit creative with a few DC's then you
can get much better coverage than lag sites without the need for more DC's or
creative subnetting.
Now I'm going to stand back and be shot down in flames. But thus far
playing with VSS is kind of casting doubt on plans for one or multiple lag
sites. I'm not going to bore with the how's and where's but it might stimulate
some discussion.
Oh and I realise that this is way far from perfect.
Curious to know if anyone has done this or thought about it if nothing
else.
Paul.
Myrick, Todd \(NIH/CC/DNA\) [E]
Mon, 06 Mar 2006 15:35:36 -0800
Mon, 06 Mar 2006 15:35:36 -0800
I also said, I have to spend my time and money wisely. I am well aware of why people use lag-sites. They always like to throw the money issue around... but I wonder what the TCO is really. Maybe these major AD DR players should commission a study.... heck maybe MSFT should for both AD and Exchange Mailboxes. I think you would do better to encourage new Admins to make sure they do a MFT backup of a domain controllers system state each night, then stand-up more sites and servers. Then based on need select the restore method and evaluate the results. I agree knowing how all the inner workings does help as well, but operations people are usually not engineers, so it is best to give them tools that have some workflow, and makes the operation smooth and less error prone. Thanks again, Todd
PLEASE READ: The information contained in this email is confidential and
intended for the named recipient(s) only. If you are not an intended
recipient of this email please notify the sender immediately and delete your
copy from your system. You must not copy, distribute or take any further
action in reliance on it. Email is not a secure method of communication and
Nomura International plc ('NIplc') will not, to the extent permitted by law,
accept responsibility or liability for (a) the accuracy or completeness of,
or (b) the presence of any virus, worm or similar malicious or disabling
code in, this message or any attachment(s) to it. If verification of this
email is sought then please request a hard copy. Unless otherwise stated
this email: (1) is not, and should not be treated or relied upon as,
investment research; (2) contains views or opinions that are solely those of
the author and do not necessarily represent those of NIplc; (3) is intended
for informational purposes only and is not a recommendation, solicitation or
offer to buy or sell securities or related financial instruments. NIplc
does not provide investment services to private customers. Authorised and
regulated by the Financial Services Authority. Registered in England
no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand,
London, EC1A 4NP. A member of the Nomura group of companies.
