Baza de date poate fi cu status “SUSPECT” din mai multe cauze: defecțiuni tehnice, LOG-file sau MDF-file defecte, lipsa spațiului pe disc etc. Pentru a afla cauza exactă pentru care baza de date a intrat în modul “SUSPECT”, putem să utilizăm următoarea interogare

DBCC CHECKDB (‘DatabaseName’) WITH NO_INFOMSGS, ALL_ERRORMSGS

Începem restabilirea bazei de date. Pentru simplitate vom lua cazul când este afectată baza de date utilizator.

1. Oprim MS SQL SERVER;

2. Copiem într-un loc sigur fișierele mdf și log ale bazei de date avariate;

3. Pornim serverul și ștergem baza de date avariată. La acest moment în unele cazuri, când nu este posibilă ștergerea, va trebui corectarea tabelului de sistem sysdatabases;

4. Creem o bază de date nouă, cu același nume și aceeași locație, ca și baza de date suspectă;

5. Oprim serverul și înlocuim fișierul mdf nou creat, cu cel salvat precedent;

6. Pornim serverul. În acest moment starea suspectă a bazei de date pentru noi nu mai este o problemă.

7. Executăm scriptul, care ne va permite redactarea tabelelor de sistem

Use master 
go
sp_configure ‘allow updates’, 1
reconfigure with override 
go

8. Tot acolo executăm scriptul care ne va afișa numărul status al bazei de date avariate, de exemplu, 536870912 – funcțiile full-text sunt incluse și etc

select status from sysdatabases where name = ‘<DatabaseName>’

   memorizăm această valoare în cazul eșecului restabilirii log-ului

9. Tot acolo executăm scriptul care ne va duce baza de date în emergency mode

update sysdatabases set status= 32768 where name = ‘<DatabaseName>’

10. Resetăm MS SQL SERVER;

11. Baza de date trebuie să se afle în emergency mode, și deja nu în suspect mode;

12. Executăm scriptul, care va crea un nou fișier de log la baza avariată

DBCC REBUILD_LOG(‘<DatabaseName>’, ‘<numele fișierului nou de log cu locație>’)

13. Executăm următorul script – utilizarea bazei în regim single user

Use master 
go
sp_dboption ‘<DatabaseName>’, ‘single user’, ‘true’
GO 
DBCC CHECKDB(‘<DatabaseName>’, REPAIR_ALLOW_DATA_LOSS)

  a) Dacă nu s-a reușit utilizarea bazei în regim single user mode, atunci pentru verificarea integrității datelor se poate de încercat  dbo only mode

sp_dboption ‘<databaseName>’, ‘dbo use only’, ‘true’ 

 b) Dacă totul a mers bine, atunci executăm

sp_dboption ‘<databaseName>’, ‘single user’, ‘false’ 
go 
Use master 
go 
sp_configure ‘allow updates’, 0
go

NOTA.

1. Dacă în stare SUSPECT vom găsi, de exemplu, baza de date TEMPBD, atunci va trebui să folosim recomandările  http://support.microsoft.com/kb/q288809/

2. Găsim informație interesantă și pe http://support.microsoft.com/default.aspx/kb/328354

Cu respect.

Prin bunavointa celor de la Align Technology am obtinut o licenta de test pentru UMove si m-am hotarat sa fac un scurt demo al produsului. Fiind de fiecare data precaut am fost ferit de incidente care m-ar fi pus in situatia sa folosesc acest produs. Insa cunosc multi sysadmini care au ajuns in situatia sa aiba nevoie de asa ceva. Unii chiar lucrand in companii foarte mari din Romania. Pe forumurile externe se pot intalni nenumarate cazuri. Si chiar si echipele de suport de la Microsoft ar putea sa confirme.

Produsul poate avea multe scenarii de utilizare, de la mutarea unui domain controller pe un hardware nou, clonarea Active Directory intr-un mediu de test, restaurarea unui server “picat”, pana la optimizarea procesului de backup pentru Active directory.

Cum am testat: 2 masini virtuale; scenariul cel mai dureros, restaurarea unui DC picat. Asta e cazul cel mai des intalnit in practica, in special de cei care au un singur DC si nici un backup (multi admini de SBS intra in categoria asta). Din informatiile producatorului stiu ca ruleaza si pe Windows 2008 insa am ales sa folosesc 2003.

Primul server instalat a fost un Windows Server 2003 R2 pe care l-am promovat la domain controller (numele domeniului a fost itboard). Discul de boot folosit a fost SCSI. Mentionez asta pentru ca la cel de-al doilea server am folosit un disk de boot IDE. Asta tocmai pentru a arata ca poti sa migrezi pe o masina cu hardware diferit, ceea ce in cazul restaurarii unui systemstate normal nu prea e posibil. Am presupus ca primul server este in imposibilitatea de a boota (fisiere de boot corupte, virus, etc) si am atasat discul la cel de-al doilea server. Acesta avea Windows 2003 R2 instalat, standalone server, alt IP, etc – nici o treaba cu primul. Singurul lucru existent acolo era kitul de instalare pentru Umove.

Am pornit instalarea pentru UMove (care e plina de informatii utile pentru multi sysadmini; urmand instalarea si citind helpul poti spune ca faci un mic curs de AD).

Aici am ales optiunea cu Restore (nu cu back-up ca in screenshot).

La locatie am specificat discul pe care tocmai il atasasem la noul server.

Am facut maparea intre informatiile de pe discul atasat si volumele locale. Exista cazuri cand informatiile AD-ului sunt “aruncate” pe mai multe volume.

Am primit un warning ca nu am serviciul DNS instalat. E nevoie ca noul server sa aiba aceleasi componente instalate ca si primul. Oricum wizard-ul o sa va anunte pentru ca altfel nu trece mai departe.

Autorii au luat in calcul si varianta clonarii unui server si incercarea de a-l pune in aceeasi retea (duh). Ca sa-i protejeze pe cei ce ar face asa ceva, softul face o verificare mai intai.

Finish. Isi face treaba – a durat foarte putin la mine si pentru ca baza mea de date AD era foarte mica. Reboot.

Wow. Chiar a mers. Dintr-un server standalone am obtinut un domain controller identic cu cel picat. Pana si IP-ul serverului a fost setat de UMove.

Am mers putin mai departe si am verificat Event Log. Ce am observat, m-a surprins din nou. Foloseste exact procedurile de restore pentru AD si reseteaza invocationID-ul. Pentru cei ce nu stiu ce inseamna, va spun eu ca e de bine. Inseamna ca poti sa folosesti procedura si in domenii cu mai multe DC-uri fara sa ai probleme.

Si SYSVOL-ul a fost restaurat …

Mission accomplished!

Am spus la inceput ca exista multe scenarii de utilizare pentru acest produs. Este facut special pentru AD, insa daca pe masina cu AD-ul mai exista si alte aplicatii (aici ma gandesc de fiecare data la SBS) poate fi folosit sa mute si celelalte aplicatii. Si aici amintim de: Sharepoint, Exchange, IIS, DHCP, WINS, Certificate Services, TS Licensing Services si chiar si EFS.

Deci, pentru cazuri disperate, nu uitati ca exista si asa ceva. Utools poate fi achizitionat online de pe utools.com in versiunile 32 sau 64 de biti la pretul de 129.95$. Nu e free, dar nici nu trebuie achizitionat inainte. Doar ca e bine sa stii de el.

In articolul precedent am vazut cum putem recupera anumite date care au fost sterse accidental din Active Directory, folosind informatiile dintr-un snapshot. Insa ce facem daca trebuie sa recuperam un obiect intreg (user account). Il putem recreea bineinteles, insa dupa cum stim nu o sa fie acelasi obiect deoarece va avea alt SID (Security Identifier).

Manualul spune ca in acest caz ar trebui sa apelam la un backup – insa un restore din backup inseamna ca trebuie sa restartam un domain controller (de 2 ori) plus ca dureaza ceva toata operatiunea.

Hai sa vedem acum la ce se refera termenul din titlu – Tombstoned objects. Pai tine de un anumit mecanism pe baza caruia functioneaza procesul de replicare si stergere a obiectelor in AD. In clipa in care stergem un obiect, sa spunem un user, obiectul nu este sters, ci atributul isDeleted este setat pe True iar obiectul este mutat intr-un container special numit Deleted Objects. In afara de asta, anumite atribute ale obiectului sunt sterse (fara posibilitatea de a fi recuperate). In aceasta clipa obiectul este invizibil pentru administrator, insa nu si pentru mecanismul de replicare, care il va replica si pe restul domain controller-elor pentru a se asigura ca este sters si pe celelalte servere.

Timpul in care obiectul ramane in aceasta stare poate varia – 60 de zile in forest-urile promovate de la Windows 2000 sau 180 de zile pentru cele care au inceput cu Windows 2003 SP1 (bineinteles ca poate fi modificat). Fiecare DC din domeniu scaneaza aceste inregistrari la un interval de 12 ore si le sterge pe cele care sunt mai vechi decat intervalul specificat.

Nota: Informatiile din articol se refera la modul de functionare al forest-urilor Active Directory care ruleaza in modul Windows 2000 pana la Windows 2008. Incepand cu R2 lucrurile se schimba (exista Recycle Bin).

Acum ca am inteles la ce se refera termenul de tombstoned objects, hai sa vedem si cum putem reanima aceste obiecte. In multe cazuri e mai simplu sa le reanimam decat sa le readucem din backup.

O varianta ar fi cu LDP (il gasiti in support tools) – sincer mi se pare cam peste mana; gasiti pe net cum se face.
Alta varianta ar fi sa o faceti programatic din C++, C#, VB – setand atributul isDeleted pe false si mutand obiectul in containerul de unde a fost sters (ne folosim de atributul lastKnownParent). Pe vremea cand nu existau tool-uri GUI pentru asa ceva tin minte ca imi facusem propriul utilitar care imi cauta aceste obiecte si imi dadea posibilitatea sa le recuperez.

Dar acum exista tool-uri suficiente pentru a uita cele doua variante descrise mai sus. Un exemplu foarte bun este ADRestore.Net care mi-a functionat si pe W2K3 si pe W2K8 (inclusiv versiunea x64).

Un alt tool cunoscut dar numai command line ar fi cel de la Sysinternals pe care il gasiti aici.

Si mai sunt multe, inclusiv PowerPack-urile de la PowerGUI insa atentie ca au ceva dependinte in spate (cmdlet-uri third party) si am avut si supriza sa nu imi ruleze pe W2K8 x64; pe 2003 nu am avut nici o problema.

Sa revenim putin si sa ne aducem aminte ce am spus la inceputul articolului: anumite atribute ale obiectului sunt sterse (fara posibilitatea de a fi recuperate). Dupa “recuperare” o sa avem acelasi obiect (acelsi SID) insa multe din informatiile asociate cu acest obiect s-au evaporat. Le puteam adauga manual folosind informatii dintr-un snapshot (vezi AD Explorer).

In majoritatea cazurilor folosim aceasta metoda pentru a recupera obiecte de tip user account. In cazul unui user sters si recuperat prin aceasta metoda, problema apare atunci cand observam ca userul nu mai face parte din nici un grup. Asta pentru ca dupa cum am spus mai sus – unele atribute sunt sterse fara posibilitatea de a fi recuperate. La fel, ne folosim de AD Explorer pentru a vedea group membership-ul user-ului ca sa il adaugam in grupurile din care a facut parte inainte.

PS: Backup is still Backup. Don’t forget about it.