Mějme Windows 2008 nebo novější radiče domény (domain controller, DC) Active Directory. Předpokládejme, že jich máme v síti více. Předpokládejme, že máme jen jednu doménu, takže nemusíme řešit více-doménové složitosti.
Jak vlastně zálohujeme
Tyto řadiče domény můžeme zálohovat pomocí Windows Server Backup s tím, že při zálohování vybereme buď Full Server, nebo v případě Custom výběru máme zaškrtnuto Bare metal recovery. To stejné platí i v případě, že používáme System Center Data Protection Manager (DPM) a pro danou Protection Group zálohujeme také Bare metal recovery.
Je jedno, jestli používáte Windows Server Backup, nebo System Center Data Protection Manager. Oni stejně oba spouští pouze stejný program WBADMIN (a potažmo samotný výkonný motor WBENGINE) se stejnými parametry:
WBADMIN start backup -AllCritical
Výsledkem takové zálohy je adresář WindowsImageBackup na nějakém disku, buď lokálním, nebo síťovém.
V případě DPM je to trošinku složitější. DPM Agent (DPMRA) nejprve vytvoří tu zálohu lokálně na nějaký volný disk, přímo do kořene disku (klidně i rovnou do C:) a pak ho teprve odkopíruje na DPM server - kopíruje ho normálně přes SMB do sdíleného adresáře s unikátním číslem, který si pro ten účel sám vytvoří na DPM serveru. Tam se tento adresář objeví nejprve na Replica Volume (přímo na něj vede ten share) a jakmile uděláte Recovery Point, tak bude i na Recovery Point Volume.
Takže v obou případech máme ve výsledku někde uschovaný WindowsImageBackup adresář s jedním až možná několika VHD soubory, což jsou "blokové" obrazy (image) zdrojových oddílů.
Poznámka: v tomhle případě je to opravdu kompletní blokový imidž, protože se z toho NEvynechávají žádné soubory, a to ani například stránkovací soubor, různé logy, nebo adresář System Volume Information. Ty by se vynechaly, kdybyste jenom obyčejně zálohovali systémový oddíl. Pokud byste se v tom chtěli rýpat, tak seznam všech normálních vynechávek je v registrech v klíči HKLM\System\CurrentControlSet\Control\BackupRestore\FilesNotToBackup - ale nebojte se, jak říkám, pokud máte -AllCritical, bute tam samozřejmě všechno a to i NTDS.DIT, to je ok :-)
Ještě tedy jednou, závěrem zálohování je fakt, že někde máte WindowsImageBackup adresář. Buď na nějakém USB harddisku, ve sdíleném adresáři, nebo v DPM.
Co si při zálohování pamatovat?
Obnovit řadič domény není úplně jednoduché. Hlavně musíte vědět, které vaše DC provozuje které FSMO role (flexible single master oparations role owner). Takže si to hlavně někde poznačte. FSMO role jsou schema master, domain naming master, PDC, RID manager a infrastructure master.
Obnova "obyčejného" DC, které nedělá žádnou z FSMO rolí je jednodušší. Nemusíte moc přemýšlet. Naopak obnova nějakého FSMO bude raději chtít myslet a případně počítat. Budete tedy i jednodušší, pokud dáte všechny FSMO role na jedno DC a nebudete to rozhazovat mezi různé kamarády, abyste v tom neměli chaos.
Které vaše DC dělá kterou roli zjistíte pomocí DSQUERY příkazů v příkazové řádce:
DSQUERY server -HasFsmo schema
DSQUERY server -HasFsmo name
DSQUERY server -HasFsmo pdc
DSQUERY server -HasFsmo rid
DSQUERY server -HasFsmo infr
Poznámka: z pohledu obnovy vás vůbec nezajímá, kdo je instrastructure master. Pokud máte navíc na všech řadičích domény GC (global catalog), nebo máte zapnutý Recycle Bin, tak vás to nezajímá taky. Protože v těchto dvou případech stejně infrastructure master nic nedělá.
Poznámka číslo 2: předchozí příkazy DSQUERY fungují i za situace, kdy některý z FSMO vlastníků je už zrovna mrtvý. Tzn. funguje to vždycky, když máte alespoň jedno DC v pořádku.
Ostaní vás ale zajímají. Takže pozor.
Dobrá rada
Dejte si na disk každého serveru soubor, podle kterého poznáte, který to je počítač. A buďte si jisti, že to oceníte, až budete vidět ten stejný disk v různých verzích někde pětkrát namapovaný :-) Ideální je naplánovat PowerShelláček, který při každém startu ten soubor znovu vytvoří. Budete mít automaticky aktualizované jméno, kdyby se počítač přejmenoval a hlavně ten soubor bude mít datum alespoň posledního startu.
Ještě lepší rada
Zkontrolujte si, že na žádném DC, které normálně provozujete, nemáte v registrech hodnotu Repl Perform Initial Synchronizations = 0. Viz. můj článek o pomalém startu.
Které provozní činnosti sledovat a hned po nich zálohovat FSMO DCčka?
Pokud rozšiřujete schema, zvyšujete domain functional level, nebo forest functional level (DFL, FFL), přidáváte novou doménu, nebo aplikační oddíl (tzn. například instalujete AD DNS server), nebo vytváříte trust (vztah důvěry), tak si zazálohujte hned potom odpovídající FSMO:
- rozšíření schema - schema master, PDC (kvůli Group Policy a případným doménovým aktualizacím skupin a zabezpečení)
- zvýšení DFL a/nebo FFL - domain naming master a PDC (kvůli změnám doménových skupin)
- nová doména a DNS server - domain naming master
- trust - PDC které se stará o trustová hesla
Obecně se dá říct, že jestli děláte jakoukoliv důležitější operaci, ideálně zazálohujte hned potom všechny FSMO role. Jediné co se nedá jednoduše sledovat jsou operace RID manageru - což taky skýtá jisté riziko - viz. dále.
Myslím, že důvod by mohl být jasný. Pokud například rozšíříte schema a on vám schema master umře dříve, než se to stihne poreplikovat do zbytku prostředí (nebo alespoň do jednoho kamaráda), po obnově tyto změny budete muset provést znovu. Pokud by se to navíc poreplikovalo jen z části, budete se s tím dlouho zadrbávat.
Jak často zálohovat?
Určitě častěji než je tombstone lifetime. Nelze taky obnovit DCčko, které jste ve zbytku prostředí smazali (metadata cleanup). Tedy lze ho obnovit, ale s kamarády se už nikdy nespojí. Ideálně je také vhodné zálohovat častěji, než jednou za 30 dnů - viz. můj článek na téma Případ dlouho vypnutého DCčka., vyhnete se tak zbytečným starostem s rozbitými hesly a nemusíte dělat NETDOM RESETPWD.
Obnova obyčejného DC, které nemá žádnou FSMO roli
Dá se to rozdělit do následujících několika rychlých kroků, které detailněji vysvětlím. Zde je to už úplně stejné, bez ohledu na to, jestli používáte Windows Server Backup, nebo Data Protection Manager:
- mrtvý, nebo poškozený server odpojíme od sítě, aby nám to ještě více nekazil.
- celé zdravé prostředí poreplikujeme. Můžeme použít například můj článek o replikaci každého s každým - tedy REPADMIN /SyncAll.
- ověříme, že "zdravé" prostředí je opravdu zdravé. Například pomocí REPADMIN /ReplSummary. Bylo by dobře zkontrolovat i stav replikace Sysvol.
- najdeme WindowsImageBackup, který si chceme obnovit a vyndáme si ho ze zálohy.
- WindowsImageBackup adresář nakopírujeme na nějaký USB harddisk, ideálně USB 2.0, aby to nevyžadovalo ovladače. Pokud obnovujeme do virtuálky, můžeme si ten adresář nahrát do VHD souboru a připojit tento VHD soubor do virtuálního počítače jako další disk.
- z mrtvého serveru vytáhneme všechny síťovkové kabely, případně vytrhneme WiFi karty, kdyby je tam snad někdo nedejbože měl.
- mrtvý server nastartujeme z instalačního DVD stejné verze operačního systému, kterou obnovujeme. Pokud obnovujeme na železo, ideálně použijeme rovnou výrobcovo DVD, které nejspíš obsahuje ovladače řadičů, které v bedně máme.
- znovu zkontrolujeme, že máme vytaženy síťovkové kabely
- podle následujících obrázků proklikáme obnovu
- pořád nezapojujeme síťovkové kabely a necháme to pořád odpojené od sítě
- projedeme přes dva normální restarty a zkontrolujeme logy a všechno (viz. detaily dále)
- zdůrazňuji, že pořád ještě máme úplně odpojené síťovky! to znamená, že nepoběží DNS server, ale to nám pořád ještě nevadí! Tedy vadí, protože to bude docela dlouho startovat, ale to je holt cena za obnovu.
Tady až sem jste to obnovovali. Pořád máme odpojeny síťovky. A jdeme zkontrolovat, že se to opravdu korektně obnovilo. Zatím bez sítě.
Nejprve bych se podíval do registrů, kde by měla následující hodnota zvýšena o jedničku oproti dřívějšímu stavu (asi jste to ještě neobnovovali, takže tam bude 1, jinak to prostě bude hodnota s počtem obnov, které jste historicky provedli):
HKLM\System\CurrentControlSet\Services\NTDS\Parameters
DSA Prevoius Restore Count = DWORD
A potom bych prohlédl logy, jestli tam objevíte následující události:
Log: Directory Service
Source: ActiveDirectory_DomainService
Event ID: 1109
Message: Active Directory Domain Services has been restored from backup media. The invocationID attribute for this directory server has been changed.
A podle toho, jestli používáte NTFRS replikaci, nebo DFSR replikaci SYSVOLu, tak v příslušném logu bude jedna z těchto dvou hlášek:
Log: File Replication Service
Source: NTFRS
Event ID: 13554
Message: The file replication service successfully added the connection shown bellow to the replica set: DOMAIN SYSTEM VOLUME (SYSVOL SHARE)
Log: DFS Replication
Source: DFSR
Event ID: 4604
Message: The DFS Replication service successfully initialized the SYSVOL replicated folder at local path.
A zkuste se samozřejmě podívat na obsah Active Directory.
Neděste se, pokud vám nejde spustit konzole Active Directory Users and Computers. To je mrcha, která bez DNS serveru hlásí něco ve smyslu "Naming information cannot be located for the following reason: The server is not operational". Není to pravda. Stačí se do Active Directory dívat pomocí nástroje LDP. Ten žádné DNS ke své práci nepotřebuje.
Co se týče SYSVOL sdíleného adresáře. Pokud máte NTFRS replikaci, tak nasdílený nebude, dokud se neporeplikuje. Pokud máte ale lepší DFSR, měl by být normálně funkční, i když nemáte zatím žádnou síťovku připojenou.
Jestli je to ok, tak super. Dal bych tomu jedne cvičný restart navíc a po opětovné kontrole bych to připojil do sítě a poreplikoval. Uf.
Jak řešit obnovu FSMO řadiče domény
V podstatě je to stejné. Jenom si musíte uvědomit, že žádná FSMO role nebude pracovat dokud se jí nepodaří skutečně poreplikovat s libovolným jedním dalším DCčkem. To je zaprvé.
Poznámka: global catalog není FSMO role, takže ten pojede.
Proto jsem taky říkal, že po operacích, které sahají na FSMO role je dobré si udělat zálohu. Ale rozhodně je dobře mít to všechno poreplikované ještě před tím, než to vaše obnovené DC pustíte znovu do sítě. Uvědomte si, že je trošku zastaralé. A je dobře, aby celý zbytek sítě věděl přesně na čem je.
A to platí dvojnásob v případě RID manageru. V případě ostatních rolí se nejspíš nic nestane, pokud si FSMO po obnově zreplikuje s nějakým zastaralejším kamarádem. Já bych ho k tomu nepustil, a rozhodně bych to zbývající zdravé prostředí nejprve poreplikoval. Ale nejspíš není co by se stalo.
Ale v případě RID manageru se to stát může. Mohli byste skončit s duplicitními SIDy. A to rozhodně nechcete. Takže poreplikovat živé prostředí ještě před tím, než pustíte obnoveného RID managera zpátky do sítě. A pokud chcete splnit všechno, co vám doporučuje Microsoft, udělejte ještě pomocí LDP toto.
Pro fajnšmekry - důvod potenciálně duplicitních SIDů při obnově RID manageru
Tohle nečtěte, pokud se nechcete zamýšlet. Něco o RID manageru si můžete přečíst taky například zde a zde. Toto je jen na vysvětlení. Příklad.
Máme třeba tři DCčka. DC1 je RID FSMO. Máme zálohu DC1. Všechno žije v pořádku. DC2 si od něho lízne nový RID pool a založí si nějaký účet s takovýmto novým RIDem. DC3 je ale vypnuté a vůbec se o této situaci prozatím nedozvědělo.
Najednou chcípne DC1, ale my nemáme ještě zálohu s jeho novým RID poolem. V záloze je pouze jeho starý RID pool.
Obnovíme staré DC1 se starým RID poolem. Pokud by se teďka DC1 doreplikovalo z DC2, dozvědělo by se, že RID pool byl zvýšen. Všechno ok.
Jenže co když se DC1 po obnovení doreplikuje s ještě zastaralejším DC3? Nedozví se o vyšším RID poolu, který před zhroucením vydalo, a vydá ho znovu. A je to.
RID manager na to má jakousi ochranu. Při obnově si sám od sebe zvýší RID pool o jeden RID rozsah (500 RIDů), což by mohlo být obvykle dost RIDů, aby to nejspíš stačilo jako ochrana. Ale jen nejspíš. Lépe je všechno opravdu poreplikovat dříve, než budete RID manager obnovovat a máte jistotu. Pokud poreplikujete, nemusíte ani RID pool zvyšovat ručně, což je stejně nejisté, jako ta automatická ochrana - Raising the value of available RID pools. Samozřejmě tím ale taky nic moc nezkazíte, jenom přijdete o 100 000 RIDů.
Pro zájemce už jen nekomentované obrázky ze stavu RIP poolů mých dvou testovacích DC1 a DC2 před obnovou. A potom LDP obrázek, kde je RID pool DC1, které bylo obnoveno ze zálohy. K přepočtu RID poolů můžete využít nástroj LDP - Utilities - Large Integer Converter podle dalšího obrázku.
