Backup e Restore di
Exchange 2003
Ivan Riservato
Andrea Garattini
Agenda
• Active Directory
• La struttura dei DB di Exchange
– Jet
• Concettti dei Database di Exchange
– Storage Groups / Database
• Streaming Backup
• Streaming Restore
Active Directory
•
•
•
•
Inside Active Directory
Backup
Authoritative Restore
Utility
– Ntdsutil
– Esentutl
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”
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)
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).
Inside Active Directory
• Checkpoint File: contiene il puntatore
all’ultima transazione registrata nel
database NON nei log (edb.chk)
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
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
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
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
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
– Restore oggetto
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
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
Ntdsutil
• Esempio per spostare il DB
– Ntdsutil
– Files move DB (log) to destinazione
– Quit
– Quit
– Riavviare il domain controller
Ntdsutil
• Per compattare il database
– Ntdsutil
– Files
– Compact to destinazione
– Quit
– Quit
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
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
Esentutl
Azione
Defrag
Recovery
Verifica
Repair
Checksum
Dump
Parametro di esentutl
/D database /opzioni
/R /opzioni
/G database /opzioni
/P database /opzioni
/K database /opzioni
/M [modificatori] nome del file
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
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
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
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
Esempio di un b-tree
Root Page
Page /
Pagina
Internal
Record
Leaf
Page
Pointer/
Puntato
re alla
pagine
succes
siva
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
Indici
• Gli indici secondari possono essere creati
o cancellati dinamicamente
• I record possono essere nascosti dagli
indici
– Un esempio è il Deleted item recovery
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
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
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
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
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
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
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
Transazioni
• Se va in crash?
– Se la transazione era tutta completata il msg
sarà nella folder di destinazione se non era
completata nella sorgente
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
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
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)
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
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)
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
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
Riassumendo…
Database completo =
EDB + STM + file di log
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)
Exchange con 2 SG:
STORE
Storage Group 1
Storage Group 2
ESE Instance
ESE Instance
LOG
LOG
LOG
EDB
STM
LOG
LOG
LOG
EDB
STM
EDB
STM
EDB
STM
EDB
STM
Tipologie di backup
Tipo
Copia i DB Copia i Log Elimina i Log
Full(Normal)
X
X
Copy/Daily
X
X
Incremental
X
Differential
X
Offline
X
X
X
X
Non
consigliato
Tape necessari per il recovery
Streaming Backup
Processo di backup “streaming”
Il Backup chiama
APIs Called
le API
ESE
ESE
in Backup
“BackupMode
Mode”
Begin
Inizio Backup
Backup
• Lo Store informa ESE che
• Il pgm di Backup
comunica allo store che è entrato nella modalità
backup
inizierà il tipo di backup
selezionato
dall’amministratore
Backup
BackupCompletato
Complete
ESE
ESE
in Normal
“NormalMode
Mode”
• L’agent richiede le pagine
del DB in modo sequenziale
• Le pagine saranno verificate
con il cheksum
Fine
End Backup
• Tutte le pagine sono lette
• I file di log sono copiati sul tape
• I log sono cancellati dal HD
• Il backup è terminato
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
Verificare manualmente i
checksum
Se si volesse effettuare un controllo
manuale sui Checksum è possibile
utilizzare l’utility eseutil:
• Eseutil /k
• Eseutil /ml
Gli errori 1018
• Se il checksum non è corretto viene generato un
event id con errore 1018
• Di conseguenza il Backup 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.)
Gli errori 1018
• Come test è possibile usare jetstress per
verificare se il problema è riproducibile o
se avete rimosso la causa
• Se è corrotto un file di log è necessario
effettuare un restore dal backup
Restore
• MSExchangeIS deve essere in
esecuzione per effettuare un restore
• I Database da ripristinare devono essere
smontati
• Gli altri database possono rimanere
montati
• Il System Attendant non è usato durante il
restore
Restore
• Se si utlizzano programmi di backup
certificati per Exchange
– vengono inserite automaticamente nei registry
le chiavi
– viene creato il file restore.env
• E’ possibile forzare a mano la “chiusura”
delle transazioni con Eseutil /cc
Restore o Recovery
• Restore
– Il programma di Backup è l’unico responsabile
per il restore dei dati
• Recovery
– Rende il db “consistente”
– Effettua le transazioni non ancora completate
che sono memorizzati nei file di log
– Soft recovery = “in place recovery” (almeno ci
provo!)
– Hard recovery = recovery dal tape
Recuperare i file
• Database
– Il programma di Backup chiede allo
Store dove posizionare I file in base alla
GUID del DB
– Lo Store sovrascrive il database
• I file di Log
– Vengono posizionati in una directory
temporanea decisa dall’amministratore
• Viene creato Il file Restore.env
Restore.env
• Sostituisce la chiave del registry “Restore
In Progress Key”
• Viene creato automaticamente nella
directory che contiene i file di log
Restore.env
Contiene le seguenti informazioni:
• Percorso del Restore
• Il percorso dei log
• Lo Storage group
• I parametri di sistema per il restore dello SG
• Il range dei file di log
• Il tempo trascorso per effettuare il Restore
Restore: Il replay dei file di log
• Viene verificato il checksum
• I file di log sono “riapplicati” in ordine:
– prima dalla dir temporanea
– poi dai file di log presenti nello SG
• Poichè all’interno di uno SG possiamo
avere più DB, durante il replay vengono
scartate tutte le transazioni che non
riguardano il DB che si sta recuperando
Più restore simultanei
• Non consigliato, meglio uno alla volta
• Va effettuato manualmente
– utilizzare il restore in una directory
temporanea diversa per ciascun DB
– Non impostare il flag “Last Backup Set”
– Eseguire eseutil /cc in ogni directory
temporanea
Il Restore
Il flusso per effettuare il restore
Dismount Database
ESE in Restore Mode
•Il pgm di backup o
l’amministratore
effettua il dismout
del db
• Lo Store informa ESE
ed entra in restore mode
• Viene creata la dir
Restore SG
Restore Completato
ESE in Normal Mode
• Il DB viene montato
dallo SG
• I dati cancellati dalla
dir temporanea
Inzio Restore
• L’agent copia I file EDB/STM
dal Tape alla path del DB
• I Log files dal backup
alla dir temporanea
Fine Restore
• I Log sono processati
dall’istanza di “ESE restore”
• Viene eliminara il
Cleanup/Restore SG
Recovery Storage Group
• Figata!
• È uno SG da utilizzare SOLO per il restore
• Presente sia nella versione standard che
nella versione enterprise
Benefici
• E’ il restore da utilizzare per recuperare la singola
mail/mailbox
• Non occorre avere una foresta parallela
• Non occorre cambiare il software di backup o le
procedure
– Attenzione se si utilizza sw di terze parti
• Minimizza il disservizio durante I restore “lunghi”
Caveat
• Non di può utilizzare come un normale SG
• I client non si possono connettere al RSG
• Le Mailboxes non sono connesse agli oggetti
user di Active Directory
• Non sono applicate le system e mailbox policy
• Non esiste l’online maintenance
• I Database non effettuano il mount
automaticamente
• Un solo RSG per server
Chi puo utilizzare il RSG
• I Database possono provenire da un
server diverso
• I database devono provenire da server
dello stesso Administrative Group
• Il Backup può anche provenire da un server
Exchange 2000 SP3
Il Dialtone Restore
• Avete un problema con un DB ..
• Salvate tutti i file di log (li userete successivamente per
ripristinare I dati)
• Cancellate il DB e configurate agli utenti un DB vuoto il
“dial tone DB”
– Non ci saranno, regole etc.
• Create il RSG con Exchange Admin
– Copiate I file di log nella dir dei log
– Restorate il db dall’ultimo backup nello RSG
– Eseguite il soft recovery
• Effettuate lo Swap del dial tone database con quello
restorato
• Utilizzate Exmerge per estrarre il contenuto del DB dial
tone ed importarlo nel database “completo e restorato”
Domande?
Altrimenti Ivan vi interroga... vedete un pò voi
