I log di Microsoft Exchange Server

Exchange Server non salva i dati direttamente nel suo database, bensì in una serie di transaction log che vengono consolidati successivamente. Nel caso il db si dovesse rovinare, questi log possono essere utilizzati per un disaster recovery, ma se questi file non vengono gestiti in maniera adeguata possono crescere a dismisura riempendo lo storage e compromettendo le prestazioni del server.

Ci sono alcune buone ragioni per usare il modello log-commit. Intanto il processo di scrittura delle transazioni su un log con successivo consolidamento è più efficiente e sicuro: scrivere in file piccoli – i log sono 5 mega ciascuno – è più veloce e meno critico che modificare un bestione da diversi giga; il commit può essere poi fatto con processi a bassa priorità e non in tempo reale, senza bisogno di attendere in coda ad altre eventuali altre attività di scrittura su database. Inoltre i transaction log prendono parte al backup di Exchange Server: in considerazione del fatto che non è possibile salvare un file aperto, se i dati fossero scritti direttamente sul db esso dovrebbe essere chiuso prima di poter effettuare il salvataggio, con la conseguente interruzione del servizio durante il processo di backup, che per server con parecchie mailbox può durare anche diverse ore. Nel momento del backup i log esistenti vengono consolidati, il db chiuso e salvato mentre il servizio continuerà ad essere disponibile, visto che le nuove transazioni verranno scritte su nuovi file di log. Nel caso di un ripristino del database, i logfile esistenti possono essere utilizzati per aggiornare il db alle ultime transazioni effettuate dopo il backup, che altrimenti andrebbero perse.

La quantità di file log continua a crescere finché il successivo backup non effettua un commit: ecco il motivo per cui è necessario fare regolarmente il backup con una applicazione Exchange aware, altrimenti lo storage continuerà a popolarsi di nuovi file finché il loro numero eccessivo non comincerà ad inficiare le prestazioni.

Per preservare lo spazio su disco, Microsoft dà la possibilità di abilitare il logging circolare (circular logging), che limita a 4 il numero massimo di file log che possono essere creati; raggiunta la soglia viene effettuato un parziale commit dei dati più vecchi; in questo modo non ci saranno mai più di 4 file log in un dato momento, pari a 20 megabyte. Per quanto possa sembrare una buona idea abilitarlo, in realtà non lo è affatto: c’è la possibilità di perdere dati tra un backup e l’altro, inoltre non è più possibile effettuare backup differenziali o incrementali. Del perché sia rischioso è facilmente comprensibile facendo due conti con numeri semplici ed esposizione volutamente semplificata.

Partiamo da un db con il circular logging abilitato e contenente, ad esempio, 1000 record. E facciamo l’ipotesi che altri 200 record siano nei log. Il backup consolida, e salva quindi 1200 record. Nell’intervallo tra un backup e l’altro vengono fatte transazioni per 500 record, di cui 1300 nel db e sempre 200 nei log (perché sono fissi a causa del circular logging attivato). Se a questo punto sono obbligato a ripristinare il backup mi troverò ad avere 1200 record del db che avevo salvato più i 200 dei log che non ho toccato. Risultato: ho perso transazioni per 100 record.

Se non sbaglio su Small Business Server il circular logging è abilitato per default, al contrario delle versioni “normali” di Exchange Server. Per controllare l’impostazione, che viene fatta a livello di Information Store, da System Manager si va in Administrative Groups -> Il vostro administrative group -> Servers -> il server -> l’information store. Clic con il tasto destro –> Properties e nella linguetta General si trova il checkbox “Enable circular logging”.

Nel caso servisse, si può effettuare l’operazione di consolidamento a mano, e vedremo in un prossimo post come fare.

(Stesse cose qui, un articolo in inglese che ho usato come traccia.)