Backup e restore con SQL Server 2005

In genere, realizzare un backup di file significa farne delle semplici copie di sicurezza per prevenire i disastri più disparati che possano coinvolgere tali file. Per SQL Server non si intende esattamente la stessa cosa, dato che i file di un database risultano in uso fintanto che risulta avviato il servizio SQL Server dell'istanza a cui il database è connesso. Per cui sarà impossibile realizzare una copia "fisica" dei file di database mentre il servizio è avviato. (Esiste solo un'eccezione a questo comportamento e si verifica quando nessun utente è connesso al database e l'opzione di database denominata AUTO_CLOSE è impostata a TRUE).

Perciò, chi ignora la procedure corretta di backup/restore di un database SQL Server, è indotto a pensare che per realizzare un backup sia necessario fermare l'istanza, quindi copiare file di dati e file di log, ottenendo così delle copie consistenti ad un determinato momento. Questo approccio può aver senso per applicazioni Desktop, ma è assolutamente irragionevole in ambienti Enterprise in cui la multi-utenza e la disponibilità del dato sono prerequisiti indispensabili per il servizio di database. Per cui nella maggioranza dei casi, è opportuno utilizzare i meccanismi nativi di backup di cui SQL Server dispone. Tali meccanismi sono piuttosto articolati e completi per effettuare backup idonei alle diverse situazioni.

Quali database includere nel backup

È bene precisare sin dall'inizio che una corretta strategia di backup di SQL Server coinvolge oltre ai database utente, ovvero quelli creati appositamente per essere acceduti dalle nostre applicazioni, anche alcuni database di sistema, cioè quei database utilizzati internamente dal Database Engine per archiviare meta-dati.

Sicuramente, non si devono escludere il database MASTER (il più importante database di sistema) così come il database MSDB da una strategia di backup efficace. Essi, infatti, ospitano tutte le informazioni relative all'intera istanza di SQL Server (database, login, job, etc.) e, se esclusi dal backup, implicano la ricostruzione manuale di tutti questi oggetti a livello di istanza in caso di un loro danneggiamento.

Struttura di un database

Si è già accennato al fatto che un database comprende file di dati e file di log. Per comprendere appieno i meccanismi di backup e restore, abbiamo bisogno di approfondire meglio questo aspetto. Dunque, un database è fatto sempre da almeno due file:

• uno di dati detto file primario (solitamente con estensione .mdf) che ospita i dati del singolo database;
• un file di log (solitamente con estensione .ldf), che ospita il log delle transazioni e che risulta essere di vitale importanza per la vita di un database quanto quello dei dati.

Internamente, i dati sono memorizzati nel file di dati, organizzati in blocchi o pagine di diverso tipo. Ogni pagina, organizzata in gruppi da otto che sono denominati Extent, ha una dimensione fissa di 8k.

Le pagine contengono dati relativi proprio alle righe di tabella, agli indici o altri tipi di dati cosiddetti Large Object (text, varchar(max), image, xml). Altri tipi di pagine servono per la manutenzione interna del database.

Il file di log delle transazioni, che invece non è organizzato in pagine, rende possibile mediante un sistema denominato "write ahead log", l'implementazione di un meccanismo fondamentale per un RDMS che assicura la consistenza dei dati garantendo le proprietà ACID (Atomicity, Consistency, Integrity, Durability) delle transazioni.

All'interno del log delle transazioni vengono scritte in modo sequenziale tutte le operazioni comandate al Database Engine. Ogni volta che una sessione lancia una richiesta di modifica di dati, il server individua le pagine interessate dall'operazione nella buffer cache oppure le legge direttamente da disco riportandole nella buffer cache dove attua l'operazione di modifica. La stessa modifica viene aggiunta sequenzialmente nel file di log. Poi un processo interno e ricorrente di SQL Server denominato CHECKPOINT provvede a replicare le transazioni completate nel file di dati. Tale funzionamento del log delle transazioni fa sì che, in caso di system failure, si possa riportare il database a uno stato consistente.

Infatti, in presenza di failure, alla ripartenza dell'istanza, ogni suo database è coinvolto in un processo denominato recovery (altrimenti detto di ripresa a caldo), il quale passa in rassegna l'intero log delle transazioni a partire dall'ultimo checkpoint, analizzando tutte le transazioni per decidere quali debbano essere annullate perché non concluse prima del failure o perché concluse con un ROLLBACK (operazione di roll-back o undo), e quali invece debbano essere confermate perché completate con un COMMIT ma non ancora passate nel file di dati (operazione di roll-forward o redo).

Dopo questa analisi, SQL Server si mette all'opera attuando la fase di redo prima, e di undo subito dopo. Dopo il redo, il database è già disponibile, fatta eccezione per le transazioni che tentano di accedere ai dati in fase di annullamento. Tali transazioni vengono bloccate in attesa che termini la fase di undo.

Recovery Model

Strettamente legato al log delle transazioni è il Recovery Model, che definisce la quantità di transazioni che devono essere mantenute nel file di log. Da esso dipendono indirettamente le tipologie di backup applicabili a un database.

Il recovery model può essere impostato a

• FULL: con cui tutte le transazioni vengono mantenute anche dopo essere state processate dal checkpoint;
• BULK-LOGGED: che può essere vista come una versione "light" della modalità full, in quanto registra meno informazioni per determinate operazioni (ad esempio creazione di indici e bulk load) in modo da ottimizzare lo spazio del file di log;
• SIMPLE: dove le transazioni vengono mantenute nel log solo per il tempo necessario ad essere processate dal CHECKPOINT, quindi subito dopo troncate.

Per impostare il recovery model mediante T-SQL:

In termini di spazio occupato, mentre un file di log in modalità SIMPLE non necessita di alcuna manutenzione, in presenza di modalità FULL o BULK-LOGGED è bene sapere che è proprio uno speciale backup (appunto del LOG) che realizza il troncamento delle transazioni già processate dal checkpoint.

Backup device

I backup sono realizzati sui backup device, in altre parole: un'unità nastro o un file su file system o file su share di rete. Per un singolo backup si possono usare da 1 a 64 device, l'importante è che i device siano dello stesso tipo, in altre parole non possiamo mischiare file con tape.

Se il backup viene realizzato su più di 1 device, avviene uno striping dei dati su di essi, ovvero i dati vengono distribuiti su tutti i device fisici.

Per usare come device un file condiviso via share di rete, occorre farvi riferimento tramite percorso UNC (Universal Network Connection), per esempio:

nome_computershare_namebackup_file_name

tenendo ben presente che il backup viene eseguito nel contesto di esecuzione dell'utente di servizio del motore di sql server, ovvero l'utente di windows che esegue il servizio windows di sql server. Per cui questo utente associato al servizio deve poter accedere e detenere il permesso di scrittura nella condivisione di rete in cui intende fare il backup.

Per backup device si intende anche il nome logico associato a un device fisico. Una volta creato un device logico, possiamo utilizzare il suo nome per indirizzare direttamente il file o il tape nei comandi di backup e restore. Ecco un esempio di utilizzo della stored procedure si sistema sp_addumpdevice per la creazione di un device logico:

Backup FULL

Sono diversi i tipi di backup nativo di cui si può far uso in accordo con il recovery model a cui impostato un database. Il più semplice, nonché la base di partenza per gli altri tipi di backup di database, è quello di tipo FULL che realizza un salvataggio delle pagine dati dell'intero database più le transazioni del log intervenute dal momento in cui il backup è iniziato. In tal modo, il ripristino di un backup di tipo completo è in grado di riportare lo stato del database al momento esatto in cui ha avuto termine l'operazione stessa di backup.

Una strategia di backup che include unicamente backup di tipo completo, prevede la generazione relativamente frequente di singoli backup, di fatto indipendenti tra loro. Più frequenti saranno, minori saranno le probabili perdite di dati in caso di ripristino.

Supponendo di aver pianificato un backup full una volta al giorno alle ore 17:00. Se alle ore 13:00 di un martedì avvenisse un failure che costringesse al ripristino dell'ultimo backup utile a disposizione, dovremmo ricorrere al backup realizzato il giorno precedente alle 17:00, perdendo così tutte le transazioni intervenute dal termine del backup in questione, il quale risale al lunedì pomeriggio, fino alle ore 13:00 del martedì in cui è avvenuto il guasto.

Un esempio di backup completo di un fantomatico database nominato "myDataBase" lanciato su un device logico creato in precedenza dal nome "myDiskDevice":

BACKUP LOG

In aggiunta a un backup di tipo completo, possono essere effettuati backup del log del database, a patto che il recovery model del database sia impostato a FULL o BULK-LOGGED.

Un backup del LOG realizza un salvataggio delle transazioni mantenute nel log a partire dall'ultimo backup completo o differenziale o del log. Nel contempo, il backup del log tronca il file di log dalle transazioni backuppate.

In particolare, se il database è in modalità bulk-logged, è possibile che il file di backup risultante sia più grande del transaction log stesso. Questo può accadere poiché in modalità BULK-LOGGED per alcune operazioni sono registrare solo informazioni di allocazione/deallocazione di pagine, che vengono, invece, risolte nelle operazioni complete in fase di backup del transaction log. Di seguito un esempio del comando di backup del transaction log:

Una tipica strategia di backup che coinvolge il backup del log, prevede per forza di cose un backup di tipo completo a monte, a cui seguono più o meno frequenti backup del log. Supponiamo, per esempio, di far seguire ad un backup completo realizzato ogni domenica, un backup del log fatto ad intervalli regolari di un'ora.

In caso di failure avvenuto un martedì alle 13:00, siamo in grado di ripristinare lo stato del database a un'ora prima, applicando il ripristino prima del backup completo della domenica precedente, quindi in sequenza tutti i backup del log fino all'ultimo disponibile che risale alle 12:00 di martedì.

In tal modo, però, abbiamo comunque perso le transazioni intercorse nell'ultima ora prima dell'avvenuto disastro, così come era accaduto nell'applicare il solo backup full giornaliero. Come possiamo quindi recuperare le transazioni intervenute dall'ultimo backup del log? Realizzando, o quanto meno tentando di realizzare, un ulteriore backup del log, detto anche backup della coda del log. Tale ultimo backup sarà possibile se il/i file di log non sono stati danneggiati e quindi sono ancora disponibili e collegati all'istanza.

In questo caso particolare in cui il database danneggiato, occorre specificare l'opzione WITH NO_TRUNCATE:

Questo rappresenta, forse, il motivo principale che dovrebbe indurre il DBA a posizionare i file di log e quelli dei dati su dischi separati, in modo da scongiurare la perdita di entrambi i file in caso di danneggiamento di un disco.

È bene notare che il backup della coda del log può essere realizzato anche nel caso in cui la nostra strategia di backup si limiti a comprendere backup di tipo full, a patto che il recovery model non sia impostato a simple, e che di fatto contenga tutte le transazioni intervenute dall'ultimo backup full (ovvero non siano stati lanciate istruzioni di troncamento esplicito del log - vedi l'articolo Un database SQL Server compatto).

Backup differenziale

Una terza tipologia di backup è quella differenziale, in cui vengono salvati gli extent (e non le singole pagine) modificati dall'ultimo backup completo, o backup parziale o da backup di file. Questi ultimi sono backup speciali che saranno esaminati nel seguito dell'articolo. Limitandoci adesso a considerare come base del differenziale il backup completo, dal momento che sostanzialmente un backup differenziale registra le modifiche intervenute dall'ultimo backup completo, in caso di ripristino dovremo applicare il restore del backup full seguito dal solo ultimo backup differenziale a disposizione, senza quindi la necessità di applicare l'intera sequenza dei backup differenziali come invece avviene per backup del transaction log. Ecco un esempio di backup differenziale:

Si noti come, il fatto che il backup differenziale prenda in considerazione gli extent modificati e non le singole pagine modificate, porta ad avere file di backup differenziale man mano sempre più grande in modo imprevedibile, causando eventuali problemi di spazio sul supporto che ospita i backup.

È bene, perciò, in funzione del volume di transazioni a cui è assoggettato il database, intervallare i backup differenziali con opportuni backup completi.

Il backup differenziale può essere lanciato indipendente dal recovery model, a patto che sia stato già realizzato un backup completo. In presenza di recovery model di tipo FULL o BULK_LOGGED, possiamo implementare una strategia di backup che includa tutte e tre le tipologie.

Supponiamo, per esempio di avere un database il cui backup completo dura molto tempo perché particolarmente voluminoso. Si potrebbe pensare di optare per una strategia mista che includa un backup completo la domenica, mentre durante i giorni feriali un backup del log lanciato a intervalli regolari di 1 ora, e ogni sera un backup differenziale.

Se dobbiamo fare il ripristino, perché alle 13:00 di martedì c'è stato un guasto, sarà bene innanzitutto provare a fare un backup della coda del log, quindi cominciare con l'applicare il restore dell'ultimo backup completo a disposizione, ovvero quello della domenica prima, seguito dall'ultimo differenziale a disposizione, ovvero quello della sera giorno prima, quindi tutta l'esatta sequenza dei log che terminerà con backup della coda del log. Di fatto, i transaction log di lunedì (quelli compresi fra il backup completo e il differenziale) non sono di alcun utilità se si intende ripristinare il database a un momento prima del guasto. Questo perché tutte le modifiche intervenute lunedì sono già comprese nel differenziale di lunedì sera.

BACKUP FILE e FILEGROUP

Ci sono altre tipologie di backup, utilizzate di sovente in scenari più complessi che necessitano di maggiore flessibilità e velocità in fase di backup e/o ripristino. Si tratta sostanzialmente di backup di tipo completo che prendono però di mira solo porzioni del database contenute nel file o filegroup specificato.

Lo scenario tipico di applicazioni di tali backup vede la presenza di database molto grandi, i cosiddetti VLDBs (Very Large Databases), il cui backup (e quindi ripristino) da un full impiegherebbe troppo tempo. In tali casi, un backup a rotazione dei file o dei filegroup del database permette di avere una base di backup per i backup del transaction log. Un esempio di istruzione T-SQL che fa un backup di un file e un filegroup:

Supponiamo per esempio di adottare una strategia che includa backup di tipo full, file e transaction log. Impostiamo un database full una volta al mese, durante la prima domenica del mese. Quindi in tutti i giorni feriali un backup del log a intervalli di 1 ora, infine ogni sera alle 17:00, a rotazione, il backup di file di cui è composto il database.

Ipotizzando che i diversi file di database su dischi distinti, e supponendo di subire il guasto di un solo disco, quindi di un solo file. Dobbiamo, innanzitutto, tentare un backup della coda del log. Quindi lanciare il ripristino del solo backup del file danneggiato seguito dalla sequenza dei log a partire dal primo successivo al backup del file fino al backup della coda del log.

PARTIAL BACKUP

Introdotto con SQL Server 2005, un backup di tipo parziale realizza un backup di tipo full o differential solo di parti predeterminate del database: il filegroup primario e i filegroup in lettura e scrittura. In altre parole trattasi di un backup completo o differenziale che esclude i filegroup di sola lettura.

Un ipotesi di utilizzo potrebbe prevedere un backup completo parziale (che quindi esclude i filegroup che sono in sola lettura perché ospitano dati storici), un backup dei filegroup in sola lettura, quindi backup differenziali parziali ricorrenti i quali escluderanno sempre i file appartenenti ai filegroup di sola lettura. Per fare un backup parziale occorre specificare READ_WRITE_FILEGROUPS nell'istruzione di backup. Ecco un esempio:

BACKUP COPY-ONLY

Introdotto con SQL Server 2005, un backup di tipo copy-only, è un backup (completo, differenziale o del log) indipendente dai backup che vengono fatti regolarmente, ovvero non lascia traccia dell'avvenuto backup, quindi non tronca il transaction log né interrompe la sequenza dei log.

Il suo utilizzo è indicato per il ripristino occasionale del database su un'altra macchina, che non alteri la sequenza dei backup e di conseguenza rovini letteralmente la strategia di backup adottata. Supponiamo, ad esempio, sia stata implementata una strategia che prevede un backup completo ogni sera e un backup del transaction log a intervalli di 1 ora durante tutto il giorno.

Supponiamo di dover ripristinare il database aggiornato su un'altra macchina. Potremmo dotarci del backup completo della sera prima e di tutti i backup del transaction log che lo hanno seguito. Inoltre, per ripristinare i dati fino all'ultimo momento, dovremmo fare un backup del log per catturare le transazioni attive ancora presenti nel log.

A questo punto nasce il problema: un normale backup del log entrerebbe a far parte della sequenza di backup del log, per cui andrebbe conservato insieme agli altri, altrimenti avremmo alterato la catena dei log. Se invece realizzassimo un backup del log con l'opzione copy-only questo pericolo è scongiurato. Un esempio:

Backup dei cataloghi full-text

I cataloghi full-text sono inclusi nel backup di tipo full, differential e di file. È bene considerare, però, che il servizio viene temporaneamente sospeso, per dare modo di consolidare i dati su disco dai buffer e il catalogo rimane in sola consultazione fino al termine dell'operazione di backup. Le modifiche non ancora processate dal motore di full text vengono messe in coda e processate a al termine del backup.

Backup Mirroring

Introdotto con SQL Server 2005, il backup mirroring, permette di eseguire un backup mirror su più backup device durante l'operazione di backup canonica. Il backup device che ospita il mirror conterrà una copia integrale del backup device standard. Ad esempio:

Nessuno ci vieta di effettuare striping e mirroring contemporaneamente. Per esempio, un backup striping su due unità nastro, tape0 e tape1, con mirroring su un altro stripe di unità nastro costituito da tape2 e tape3.

Verifica dell'affidabilità dei backup

SQL Server 2005 introduce nuovi meccanismi interni di controllo dell'affidabilità dei dati che operano a livello di database, backup e restore.

Per quanto riguarda il database nel suo complesso, possiamo scegliere di impostare la proprietà PAGE_VERIFY scegliendo fra TORN_PAGE DETECTION (che era l'impostazione di default in SQL Server 2000) e CHECKSUM. Quest'ultima è da preferire alla prima in quanto più accurata e precisa, ma di contro più impegnativa per SQL Server e quindi più onerosa in termini di impiego di risorse. Di seguito la sintassi T-SQL per impostare la proprietà di PAGE_VERIFY:

Prima di passare a analizzarne le differenze, soffermiamoci a considerare il motivo di fondo che può generare una pagina corrotta, in gergo torn page. Quando SQL Server comanda la scrittura di una sua pagina data al sistema operativo, delega allo stesso la scrittura degli 8Kb di cui è composta la pagina, ma Windows Server divide questi 8Kb in 16 blocchi che provvede a scrivere uno dopo l'altro, questo perché Windows scrive blocchi da 512Kb.

Il problema sta nel fatto che per SQL Server, l'operazione è andata a buon fine già quando la scrittura dal parte di Windows del primo blocco di 512 Kb ha avuto esito positivo. Ecco, dunque, che in caso di failure potremmo ritrovarci con pagine corrotto di cui neanche SQL Server ne conosce l'esistenza, ma grazie al torn page o al checksum è in grado di rilevare le torn pages qualora qualcuno vi accede.

Con la torn page detection, ogni qual volta viene scritta una pagina, SQL Server mantiene una bitmap per ogni blocco di 512 byte di dati nella pagina, di modo che una lettura successiva potrà determinare se l'I/O è stato completo correttamente o meno.

Con la page checksum, al posto della bitmap viene calcolato un valore di controllo (checksum appunto) per l'intera pagina e salvato nella pagina stessa. L'operazione di I/O sulla pagina, determina la correttezza della pagina ricalcolando il checksum e confrontandolo con quello salvato nella pagina letta.

Per quanto riguarda l'affidabilità dei dai salvati nel backup, è possibile sfruttare l'opzione CHECKSUM del comando di BACKUP.

Mentre in SQL Server 2000 esiste un sistema di verifica del backup non del tutto affidabile, SQL server 2005 simula con il comando RESTORE VERIFYONLY un vero e proprio restore, fatta eccezione per la fase di scrittura su disco.

Vediamo come funziona. Durante l'operazione di backup, di ogni pagina letta viene fatto un controllo della bitmap di torn o del checksum a seconda dell'opzione PAGE_VERIFY del database. Inoltre viene calcolato un checksum dell'intero backup che di default è disabilitato. Quindi viene tenuto traccia delle pagine per le quali viene trovato un checksum non coerente. Così, in fase di restore è possibile controllare il checksum delle singole pagine scritte in fase di backup oltre che il checksum del backup completo. Un esempio:

Restore

Ripristinare un database di SQL Server significa ripristinare i file che compongono un database ricreandoli o solo copiando i dati dal backup verso i file. Questo per quanto riguarda i backup ti tipo completo o differenziale.

In presenza poi di backup del transaction log, il ripristino potrebbe coinvolgere la sequenza dei backup del log che riverserebbe le transazioni backuppate all'interno del file di log. Dopo il ripristino dell'ultimo backup occorre riportare in linea il database, applicando il processo di recovery di database. In altre parole, l'opzione recovery o norecovery del comando di restore implica, rispettivamente, che alla fine dell'operazione di restore il database sarà in linea passando per il processo di recovery oppure non in linea in attesa che si lanci il processo di recovery.

È inteso che per tutti i restore che precedono l'ultimo, occorre invece lasciare il database in uno stato di no-recovery, altrimenti non sarà possibile applicare altri restore. L'impostazione di default per il Restore è WITH RECOVERY. In caso ci si dimentichi con l'ultimo backup di specificare l'opzione recovery, è possibile comandarlo esplicitamente - senza dover ripetere l'intera catena dei backup - con il comando:

Restore point in time

Una caratteristica del restore molto utile è rappresentata dalla possibilità di ripristinare i dati a un momento specifico o un marcatore definito a priori all'interno del transaction log.

Supponiamo di voler ripristinare un database che in cui è stata erroneamente cancellata una tabella alle ore 12:30:45 di martedì. Abbiamo quindi la necessità di riportare i dati a uno suo stato consistente risalente esattamente a qualche istante prima dell'avvenuto errore, per esempio alle 12:30:10 dello stesso giorno.

Supponendo di disporre dell'ultimo backup completo che risale 17:00 della sera prima e dell'intera sequenza di log, dobbiamo iniziare al solito col ripristino del backup full, seguito eventualmente dall'ultimo differenziale precedente all'errore logico che vogliamo riparare, quindi tutti i backup del log, tranne l'ultimo che contiene anche la transazione errata. Infatti, per quest'ultimo (che è bene tener presente potrebbe anche essere quello ricavato dalla coda del log) dobbiamo proprio specificare il point-in-time, ovvero il giorno e l'ora esatta a cui deve fermarsi il ripristino, nel nostro esempio le 12:30:10:000 del martedì. Un esempio:

Restore di una pagina

Con SQL server 2005 è stata introdotta una caratteristica molto utile in tema di restore, ovvero la possibilità di ripristinare una determinata pagina di dati. L'utilità sta nel fatto che per database parecchio voluminosi, in caso di poche pagine danneggiate, un ripristino di questo tipo si può risolvere in pochi minuti o addirittura secondi anziché ore.

È supportata in tutte le edizioni di SQL Server 2005 e non solo dall'Enterprise come spesso accade per feature avanzate. Gli unici vincoli sono rappresentati dal recovery model, che deve essere full o bulk-logged, e dal fatto che i file o filegroup devono essere esclusivamente in lettura/scrittura.

Si consideri che per assicurare la consistenza logica dei dati, occorre che il ripristino inizi da un full backup (o del file o filegroup), per poi continuare con la sequenza di backup del log, fino alla coda del log.

Tutto ciò è necessario perché, presa una pagina X dalla prima versione disponibile in un backup full o di file e di filegroup, l'applicazione dei transaction log backuppati assicura che eventuali modifiche intervenute nella pagina interessata dal restore siano riapplicate alla pagina stessa.

Per identificare il numero di pagina danneggiato occorre, innanzitutto, assicurarsi che l'opzione di database PAGE_VERIFY sia impostata a TORN_PAGE_DETECTION o CHECKSUM.

In tal modo, nel momento in cui una pagina dati viene acceduta in qualche modo dal servizio SQL Server (per esempio con una SELECT o un BACKUP o un DBCC CHECKDB), lo stesso si preoccupa di tracciare nella tabella suspect_pages, che si trova nel database di sistema MSDB, l'avvenuto l'accesso a una torn page, specificandone numero di file e di pagina, ovvero quanto basta per identificarla anche in fase di restore della singola pagina.

Le stesse informazioni possono essere recuperate dall'error log di SQL Server come anche dai risultati del comando DBCC CHECKDB. Ecco come recuperare le informazioni sulle torn page dalla tabella suspect_pages, quindi applicare un restore della singola pagina dall'ultimo backup full a disposizione applicando in ultimo il backup della coda del log:

Restore On-Line

Un'altra nuova funzionalità in tema di restore introdotta con SQL server 2005, anche se supportata nella sola Enterprise edition, è il ripristino del database on-line.

Fatta eccezione per il file primario (il quale contiene il catalogo di sistema), con il restore online si può fare un ripristino dell'intero database, di uno o più file specifici, così come di una singola pagina mentre il database è ancora on-line, in altre parole disponibile. Per l'esattezza, la disponibilità è relativa ai filegroup. Quindi, mentre sta avvenendo il ripristino di un filegroup, questo è inaccessibile mentre tutti gli altri invece sono accessibile. Di conseguenza, i diversi filegroup saranno, a turno, ripristinati e resi accessibile al termine del loro restore.