Backup e Restore di Exchange 2003

1. Backup e Restore di Exchange 2003 Ivan Riservato Andrea Garattini

2. Agenda • Active Directory • La struttura dei DB di Exchange • Jet • Concettti dei Database di Exchange • Storage Groups / Database • Streaming Backup • Streaming Restore

3. Active Directory • Inside Active Directory • Backup • Authoritative Restore • Utility • Ntdsutil • Esentutl

4. Inside Active Directory • La tecnologia usata prende il nome di Extensible Storage Engine (ESE) • Basato su Indexed Sequential Access Method (ISAM) • Composta da più file • Formalmente chiamata “JET Blue” da non confondersi con Access “JET Red”

5. Inside Active Directory • Database file: contengono lo schema di tutte le tabelle del database, i record di tutte le tabelle del database e gli indici (ntds.dit) • Transaction log file: contengono tutte le informazioni necessarie per riportare il database in uno stato consistente in caso di un qualunque errore (edb*.log)

6. Inside Active Directory • Temporary Transaction Log File: vengono utilizzati al raggiungimento della dimensione massima (10 MB) dei log. • Reserved Transaction Log File: vengono creati dal sistema all’avvio del servizio ed utilizzati solo in caso di saturazione dello spazio fisico del disco per consentire il corretto spegnimento del servizio (res1.log e res2.log).

7. Inside Active Directory • Checkpoint File: contiene il puntatore all’ultima transazione registrata nel database NON nei log (edb.chk)

8. Active Directory Backup • È sufficiente eseguire su un domain controller il backup del System State. • Questo comporta il backup di Active Directory e di tutti i componenti su cui si basa • System Registry • COM+ Class Registration Database • File Replication Services (SYSVOL) • Certificate Autority • DNS solo se integrato in AD

9. Active Directory Backup • Privilegi necessari: • Backup Operator • Local Administrator • Con i componenti standard è necessario effettuare il backup di ciascun domain controller nella foresta • Un backup di AD è valido per 60 giorni

10. Tombstone • Di default un oggetto è definitivamente eliminato da AD dopo 60 gg. • SP1 consente di estendere questo limite a 180 gg • All’interno del container CN=Directory Services, CN=Windows NT, CN=Services, CN=Configuration, DC=forest root domain utilizzare i due paramentri • tombstoneLifetime • garbageCollPeriod

11. Active Directory: Authoritative Restore • AD è basata su un modello di replica multimaster, quindi ogni domain controller può aggiornare in modo indipendente AD. • Dopo aver cancellato un oggetto, eseguendo un restore non autoritativo non saremo in grado di ritrovare l’oggetto in AD. • Questo poichè viene incrementato un contatore necessario per il corretto funzionamento di una replica multimaster

12. Authoritative Restore • È quindi necessario segnalare ad AD che l’operazione di restore che andiamo ad eseguire deve ignorare tale contatore • Per eseguire il restore in modo autoritativo • Riavviare il domain controller in Directory Server Restore Mode (F8) • Eseguire NTDSUTIL • Al prompt autoritative restore • Restoreoggetto

13. Authoritative Restore • Come oggetto va specificato il tipo di oggetto (ad esempio subtree) ed il suo Distinguish Name (DN) • Ntdsutil • autoritative restore • Restore subtree OU=test,DC=UGIMEX,DC=LAB • Quit • Quit • Riavvio del domain controller

14. Ntdsutil • Si trova nei support tools • Consente di eseguire le normali operazioni di manutenzione di AD – tutte queste operazioni devono essere effettuare da Directory Services Restore Mode • Spostare il database • Spostare i file di log • Compattare il database • Eseguire i restore

15. Ntdsutil • Esempio per spostare il DB • Ntdsutil • Files move DB (log) to destinazione • Quit • Quit • Riavviare il domain controller

16. Ntdsutil • Per compattare il database • Ntdsutil • Files • Compact to destinazione • Quit • Quit

17. Ntdsutil • Database integrity check • Ntdsutil • Semantic database analisys • Verbose on • Go fixup • Quit • Quit • Da eseguire solamente in caso di errori nel file dsdit.dmp.xxx

18. Esentutl • Ultima speranza ... prima di un restore di tutto AD • Da usare con MOLTA attenzione e cognizione di causa • È una utility di basso livello che accede direttamente alla struttura del database

19. Esentutl

20. Undocumented Esentutl • Esentutl –mh percorso db\ntds.dit • Per vedere gli header e lo status del database ntds.dit • Esentutl –ms percorso db\ntds.dit • Per vedere le tabelle e lo spazio disponibile

21. La struttura dei DB di Exchange • Tutta la struttura è un b-tree • E’ Indicizzata per un’accesso veloce • Struttura separata di tipo ‘long-value’ b-trees per i “data chunks” • La tabella (table) è una collezione di b-trees • Data tree • Long-value tree • Index trees

22. B-trees • Forniscono un’accesso veloce ai dati • Minimizzano il numero di I/Os per trovare un record nel DB • I dati contenuti nelle tabelle sono ordinati dalle chiavi definite nei client MAPI

23. B-trees • I dati sono memorizzati in pagine di 4K o 8K • 4K per Exchange • 8K per Active Directory • Le pagine sono memorizzate in RAM per aumentare le performance

24. Root Page Internal Leaf Esempio di un b-tree Page / Pagina Page Pointer/ Puntatore alla pagine successiva Record

25. Indici • Necessari per vedere i record ordinati in modo differente • Una chiave primaria b-tree ha un’indice secondario anch’esso b-tree • Gli indici secondari sono molto compatti paragonati ai dati contenuti nelle chiavi degli indici

26. Indici • Gli indici secondari possono essere creati o cancellati dinamicamente • I record possono essere nascosti dagli indici • Un esempio è il Deleted item recovery

27. Com’è fatto un DB di Exchange ? • Una tabella Globale che contiene: • Informazione correlate al Database • La versione del database e la GUID • La tabella delle Mailbox che contiene: • Un record per utente • Viene associato ad un’utente nella root folder • La tabella “Folders”: • Descrive la gerarchia delle folder • Contiente i counter degli item

28. Com’è fatto un DB di Exchange ? • Una tabella Message • Contiente tutti i messaggi • Una tabella degli Attachments • Normalmente si riconoscono perchè iniziano con un numero da 1 al 23 • Contengono tutti gli allegati sono memorizzati qui

29. Com’è fatto un DB di Exchange ? • La tabella MessageFolder • Hanno nomi N-N • Una per ogni folder • Gli indici sono creati quando si effettua un search da Outlook • Hanno un link (reference) alla tabella Message • Tabella Search • Creata usando “Advanced Find” • Hanno nomi S-N-N

30. Com’è fatto un DB di Exchange ? • La tabella Categorization • Creata usando la vista “Group By” • Memorizza quale item sono aperti/chiusi • Hanno nomi C-N-N • Per avere un’elenco delle tabelle • ESEUTIL /MS • visualizza anche lo spazio occupato • Per verificare la struttura si utilizza ISINTEG

31. Perchè usare i file di log ? • Se succede uno di questi eventi .. • Mancanza di corrente • Dischi che si rompono • Errori di sistema • Mantengono consistente il DB • Lo status delle transazioni è persistente e, per gli amanti dei DB relazionali, sono ACID • E’ molto efficiente

32. I file di log • Il file di log è suddiviso in più file chiamati ‘generations’ • I “generations” sono chiamati con ENNXXXXX.LOG • NN è lo storage group • XXXXX è la generation espresso in esadecimale • ENN.LOG è la più alta “generation” cioè l’ultimo

33. Transazioni • La transazione è l’unità elementare con cui lavora Jet • Es. Quando si sposta un msg da una cartella ad un’altra Jet • Cancella il msg dalla cartella sorgente • Inserisce il msg nella cartella di destinazione • Aggiorna la dimensione delle cartelle

34. Transazioni • Se va in crash? • Se la transazione era tutta completata il msg sarà nella folder di destinazione se non era completata nella sorgente

35. Il Version Store • Contiene un’elenco delle operazioni effettuta dalle transazione attive • Usato per effettuare il rollback delle transazioni • Se a causa di un problema Jet deve effettuare un rollback il version store può diventare molto lungo • JET_errVersionStoreOutOfMemory

36. Come funzionano i file di Log • “Write-ahead” logging • le pagine modificate in cache non vengono inserite immediatamente nei database • Vengono inserite in apped ai file di log • La scrittura nel database è un’operazione asincrona per ottenere delle buone performance • I Checkpoint file (*.chk) tengono traccia delle transazioni che sono state inserite del database (.edb e .stm) dai file di log

37. The streaming file • Contiene i dati ricevuti da un protocollo Internet • I dati sono memorizzati “raw” • Esistono in coppia con un file .EDB • Il file .edb contengono I puntatori agli oggetti contenuti nei corrispondenti .stm • ATTENZIONE: non ha i log… (a buon intenditor poche parole)

38. Il file di log Analogamente ad AD (ma Exchange è arrivato prima ) • ENNTMP.LOG è usato durante la creazione di un nuovo file di log • RESN.LOG viene utilizzato quando non c’è più lo spazio per la creazione dei file di log

39. I file di log • Un database e’ consistente quando tutte le transazioni sono state inserite nel database • Circular logging – autoelimina I file di log dopo averli inserite nel database (utilizza al massimo 4 file di log) ORRORE!!!! (si chiama anche masochismo o log Tafazzi)

40. I file di streaming (*.STM) • Il file .STM non è mai sovrascritto • Modificare un messaggio comporta la creazione di un msg nuovo e la cancellazione del vecchio • L’eventuale spazio utilizzato non viene rilasciato fino alla completazione della transazione • Il che significa che le non è possibile effettuare un roll back delle modifiche effettuate in un file .STM • Non ha alcun tipo di log

41. Dove risiedono quindi i msg ? • Nei log • I nuovi msg possono non essere scritti nel DB • Quando il database viene smontato in modo “pulito” significa che: • Tutte le transazioni sono state completate • Tutte le modifiche al database sono scritte sul disco (attenzione ai controller!!!) • Per verificare lo stato usare ESEUTIL /MH

42. Riassumendo… Database completo = EDB + STM + file di log

43. Storage Group • Un insieme di DB che condividono gli stessi file di log • Ogni SG ha un istanza separata di Jet • 4 Storage group per Server (Enterprise) • 5 Database per Storage Group (Enterprise) • 1 Storage Group particolare (il Recovery Storage Group o RSG)

44. Exchange con 2 SG: STORE Storage Group 1 Storage Group 2 ESE Instance ESE Instance LOG LOG LOG LOG LOG LOG EDB EDB EDB EDB EDB STM STM STM STM STM

45. Tipologie di backup Tipo Copia i DB Copia i Log Elimina i Log Full(Normal) Copy/Daily Incremental Differential Offline X X Non consigliato X X X X X X X X

46. Tape necessari per il recovery

47. Streaming BackupProcesso di backup “streaming” Streaming BackupProcesso di backup “streaming” Il Backup chiama le API Backup APIs Called ESE Backup Mode ESE in “Backup Mode” Begin Backup Inizio Backup • Lo Store informa ESE che è entrato nella modalità backup • L’agent richiede le pagine del DB in modo sequenziale • Le pagine saranno verificate con il cheksum • Il pgm di Backup comunica allo store che inizierà il tipo di backup selezionato dall’amministratore ESE Normal Mode ESE in “Normal Mode” End Backup Fine Backup Backup Complete Backup Completato • Tutte le pagine sono lette • I file di log sono copiati sul tape • I log sono cancellati dal HD • Il backup è terminato

48. Il checksum • Tutte le pagine dei Database e dei file di log vengono verificate con un checksum • Il checksum dei file di streaming è memorizzato all’interno del database • I checksum delle pagine sono verificate ad ogni operazione di lettura • I checksum dei database, dei file di streaming e dei file di log sono verificati solamente durante il backup

49. Verificare manualmente i checksum Se si volesse effettuare un controllo manuale sui Checksum è possibile utilizzare l’utility eseutil: • Eseutil /k • Eseutil /ml

50. Gli errori 1018 • Se il checksum non è corretto viene generato un event id con errore 1018 • Di conseguenza ilBackup NON andrà a buon termine • Un errore nel calcolo del checksum indica che i dati sono corrotti • L’errore solitamente deriva da un problema HW (verificate i controller, batteria tampone, memoria non ECC etc.)