That was my major concern too Hunter. Although we have not seen this in the lab, I am wondering in a more complex environment (like production) if the beast will rear it's ugly head then. That would be bad, very bad.
Btw, thanks to all of you for the comments and scenario recommendations. Much appreciated! Dave -----Original Message----- From: Coleman, Hunter [mailto:[EMAIL PROTECTED] Sent: Monday, August 11, 2003 10:40 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Disaster recovery scenario comments requested. My biggest concern in this case is that you end up with an offline backup of the AD database, so you could be happily backing up a database with page-level corruption. Running a couple of virtual DCs on different physical hardare should minimize the risk of -1018 errors, though. Has anyone seen low level corruption of an ntds.dit database? Hunter -----Original Message----- From: Joe [mailto:[EMAIL PROTECTED] Sent: Friday, August 08, 2003 9:47 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Disaster recovery scenario comments requested. Actually VMWare or more likely Virtual Server are what we are *starting* to look at for a DR system. Basically the idea is to have a couple of nice sized Physical Servers running multiple virtual servers that are domain controllers for all Domains in the Forest. Every night one of the P-Servers shuts down all of the Virtuals and copies off the disk images to some other location for backup to tape. The next night the other P-Server does it. The beauty of this solution is that physical hardware becomes a lot less important for your DR site or your test lab (yes you could bring these images back up in a *segragated* test lab for testing of your production AD and data...). You simply load up your server and then install your virtualization software and then fire up your images and you are off to the races... We actually just got the hardware in for this, which we will use to develop the solution against the test environment and then once comfortable with it will go prod with it. Personally I think this is about the most flexible and safe DR solution you can have. I am not one for restoring AD from system state dumps. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chianese, David P. Sent: Friday, August 08, 2003 7:04 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Disaster recovery scenario comments requested. That would obviously kill the ghost image idea. I do however like the laptop and "more graceful" way of transferring roles at the DR site. I think I hear the chimes of VMWare ESX Server calling. Thanks for the feedback Don. I see another idea in my head now too. Alas, it's Friday and I'm late for Happy Hour -Dave -----Original Message----- From: Don Guyer [mailto:[EMAIL PROTECTED] Sent: Friday, August 08, 2003 5:12 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Disaster recovery scenario comments requested. David, We use similar methodology for our DR tests, by keeping a laptop running as a DC on our live network, then transferring FSMO roles at the DR site. This has worked flawlessly for us. We are now looking to be able to restore our AD evironment to a totally different server. Problem is, when we do DR testing we usually get Compaq hardware, whereas we are a Dell shop here. Don Guyer IS Dept Citadel FCU Ph: 610.380.7072 Fax: 610.380.7008 [EMAIL PROTECTED] -----Original Message----- From: Chianese, David P. [mailto:[EMAIL PROTECTED] Sent: Friday, August 08, 2003 1:17 PM To: '[EMAIL PROTECTED]' Subject: [ActiveDir] Disaster recovery scenario comments requested. All, I want to run this DR situation by the group and see if anyone else can identify any "gotcha's" in the process. We are currently testing out a DR scenario that involves off-site Domain controllers at a recovery center. During normal operations the DR DC's are linked to our network via VPN and fractional T1 line in order for replication to occur. When we declare a DR test or go into a live DR situation where one of our sites becomes unavailable for an extended period of time due to an outage, network issue or terrorist incident (remember 9/11?) we bring the DR site up, seize the PDC emulator roll (to add workstations, accounts and perform other urgent replication) and let our clients continue operations in all of our remote locations with little interruption of service. Now, here is the hard part. when DR is over we disconnect the DR DC from the wire and delpart.exe (format/fdisk for ntfs) all of the partitions. The site that was down is then restored and the PDC emulator roll is back to its original state. We then take the DR DC and apply a ghosted image of the server as it was when it was first dcpromo'd and let it catch up on replication. This so far has worked flawlessly in the lab. We avoid doing the metadata cleanup of the server since nothing has really changed on the DR DC as it was re-imaged previous to the PDC emulator roll seizure. Our lab environment is a fraction of the capacity of our Production and not as complex. Can anyone see any problems arising down the road by doing a DR process like this? The other option planned is to already have the workstations and DR environments created in a separate OU so that in a DR situation we just need to let the site that is disconnected stay disconnected and then catch up on replication when it comes back. This is my preferred method of how to handle our DR woes, but unfortunately we are not there yet. I am only looking for feedback or you to play devil's advocate on the above situation we currently have in place. Thank you in advance for your comments. Regards, David Chianese Senior Engineer IT - Server Services Delaware Investments *Powered By Research A Member of the Lincoln Financial Group This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us immediately by returning this message to the sender and delete all copies. Thank you for your cooperation. List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us immediately by returning this message to the sender and delete all copies. Thank you for your cooperation. List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us immediately by returning this message to the sender and delete all copies. Thank you for your cooperation. List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
