• Articolo

Percorsi di recupero

La comprensione del concetto di percorso di recupero è importante se si utilizzano backup differenziali o backup dei log e si esegue il recupero di un database fino a un punto nel tempo precedente tramite uno dei metodi seguenti:

  • Esecuzione di un ripristino temporizzato

  • Esecuzione di un recupero senza prima ripristinare tutti i backup dei log o il backup differenziale più recente.

Se si recupera un database da un punto di recupero precedente e si inizia a utilizzare il database da tale punto, verrà creato un nuovo percorso di recupero. Il percorso di recupero è la sequenza di dati e di backup dei log che hanno portato un database a un particolare punto nel tempo, tramite il normale utilizzo del database o tramite un ripristino specifico dei dati e del log. Un percorso di recupero è costituito da un set unico di trasformazioni specifiche che hanno determinato la modifica del database nel corso del tempo, mantenendone tuttavia la consistenza. Nella figura seguente viene illustrata la relazione tra un punto di recupero e i percorsi di recupero risultanti.

Punto di recupero e percorsi di recupero risultanti

Nelle situazioni seguenti viene creato un nuovo percorso di recupero in quanto il database non viene ripristinato fino alla fine. Esistono quindi backup che possono determinare la creazione di due o più percorsi di recupero, ognuno dei quali utilizzerà lo stesso intervallo di LSN.

  • Ripristino di un backup completo del database e recupero del database senza utilizzare altri tipi di backup.

  • Recupero del database fino alla fine di un backup differenziale diverso dal più recente.

  • Ripristino di un backup completo e di un backup differenziale del database e recupero del database senza applicare i backup esistenti del log delle transazioni.

  • Recupero del database fino alla fine di un backup del log delle transazioni diverso dal più recente.

  • Recupero del database fino a un punto specifico nel tempo o fino a una transazione contrassegnata all'interno di un backup del log delle transazioni.

In generale, se un punto di recupero provoca il rollback delle transazioni viene avviato un nuovo percorso di recupero. È possibile che i numeri di sequenza del file di log (LSN) dei backup preesistenti siano ora maggiori dell'LSN del punto di recupero. Gli LSN in questi backup si trovano su un ramo di recupero diverso dal nuovo ramo creato dall'operazione di recupero corrente.

Procedura consigliata Per evitare la creazione di un percorso di recupero con più fork di recupero, eseguire un set completo di backup dei dati non appena possibile dopo il recupero del database. Questo approccio garantisce che tutti i backup siano eseguiti su un ramo di recupero singolo. Per effettuare la verifica, è possibile esaminare la colonna last_recovery_fork_guid nella tabella backupset o nel set di risultati RESTORE HEADERONLY dopo avere eseguito il backup dei dati.

Esempio di percorso di recupero

All'inizio, tutti i backup di un database compongono un unico percorso di recupero, come mostrato nella figura seguente. In questa figura, il percorso di recupero include un backup di database, effettuato all'ora t1 e tre backup del log, effettuati alle ore t2, t3 e t4.

Percorso di recupero originale

Nella figura seguente viene mostrato un fork di recupero che è il risultato di un recupero del database fino un punto precedente. In seguito a un problema con il backup t4, l'amministratore del database effettua il recupero del database alla fine del backup del log t3. Questo ripristino provoca un fork di recupero. All'ora t5, un nuovo backup del log avvia un nuovo ramo di recupero, il ramo di recupero 2.

Creazione di un secondo ramo di recupero

[!NOTA]

Il backup del log t5 contiene metadati del fork di recupero che consentono di connettere questo backup al backup del log t3 sul ramo di recupero 1. Per informazioni sui metadati del fork di recupero, vedere "Gestione dei fork di recupero", di seguito in questo argomento.

Nell'esempio della figura precedente viene creato un nuovo percorso di recupero, mostrato nella figura seguente. Il nuovo percorso di recupero include alcuni backup del ramo di recupero 1 (da t1 a t3) e tutti i backup del log del ramo di recupero 2 (da t5 a t9). Secondo la prospettiva di questo percorso di recupero, il backup del log t4 è obsoleto.

Nuovo percorso di recupero

Dopo un ripristino temporizzato, il backup successivo produce sempre un fork di recupero. Nella figura seguente, un ripristino temporizzato viene completato a metà del backup del log t4. Il recupero del database fino a quel momento produce un fork di recupero. Quindi, un backup del log viene creato sul database recuperato all'ora t5, determinando un ramo di recupero 2 e creando un nuovo percorso di recupero. Il primo backup del log sul nuovo ramo, t5, include lo stesso LSN del backup del log t3 e lo sostituisce. Pertanto, entrambi i backup di t3 e t4 risultano obsoleti sul nuovo percorso di recupero.

Nuovo percorso di recupero dopo un ripristino temporizzato

Per ripristinare i backup su questo nuovo percorso di recupero, la sequenza di ripristino è: t1, t2 e t5. Quando sul ramo di recupero 2 verranno effettuati i backup futuri, essi saranno incorporati nel nuovo percorso di recupero.

Per eseguire un ripristino e un rollforward su un vecchio percorso

In genere, quando esistono più percorsi di recupero, il più recente è il percorso preferito per il ripristino del database. È consigliabile evitare di utilizzare un percorso di recupero precedente, Tuttavia, se necessario, è possibile eseguire il rollforward mediante un percorso di recupero precedente seguendo la sequenza di backup eseguiti prima della creazione del percorso di recupero corrente. Ad esempio, è possibile utilizzare i backup eseguiti prima di un recupero temporizzato, in modo da raggiungere i punti più recenti del vecchio percorso.

Ad esempio, in base ai backup creati nella figura precedente, dopo la creazione del backup del log t5, è sempre possibile eseguire il ripristino a partire dal backup completo del database effettuato all'ora t1, fino alla fine del backup del log t4, che si trova nel percorso di recupero obsoleto.

Per ripristinare ed eseguire il rollforward di un percorso completo precedente su un nuovo percorso

Motore di database di SQL Server impedisce l'utilizzo, da parte di una sequenza di ripristino, dei backup non compatibili tra loro, ovvero che tentano di eseguire il rollforward su percorsi di recupero diversi. Tale limitazione consente di mantenere la coerenza di un database dopo un recupero.

Per eseguire un ripristino e un rollforward su un nuovo percorso di recupero, creare sequenze di ripristino distinte per i backup precedenti al punto di recupero e per i backup successivi al punto di recupero:

  1. Ripristinare i backup eseguiti prima del recupero che ha preceduto il nuovo percorso di recupero. Escludere il backup che include il punto di recupero.

  2. Eseguire il rollforward sul nuovo percorso di recupero ripristinando i backup eseguiti dal momento della creazione del percorso di recupero.

Gestione dei fork di recupero

Un ramo di recupero è un intervallo di numeri di sequenza del file di log (LSN) che condividono lo stesso GUID. Un percorso di recupero descrive un intervallo di numeri di sequenza del file di log da un punto di inizio (LSN,GUID) a un punto di fine (LSN,GUID). È possibile che l'intervallo di numeri di sequenza del file di log attraversi uno o più rami di recupero dall'inizio alla fine. Un nuovo ramo di recupero viene generato quando si crea un database e quando RESTORE WITH RECOVERY genera un fork di recupero.

Un fork di recupero è il punto (LSN,GUID) in cui inizia un nuovo ramo di recupero, ogni volta che si esegue RESTORE WITH RECOVERY. Ogni fork di recupero determina una relazione padre-figlio tra i rami di recupero.

Il recupero del database imposta l'intero stato del database, incluso l'LSN successivo, sul punto di recupero. Gli LSN vengono quindi riutilizzati, a partire da fork_point_lsn. Quando si crea una sequenza di ripristino, pertanto, è necessario che i backup siano collegati tramite fork di recupero e tramite LSN, in quanto è possibile che lo stesso LSN esista su più fork. Nella figura seguente viene illustrato il riutilizzo degli LSN. Essa mostra in che modo gli LSN vengono riutilizzati nei diversi fork di recupero. Le caselle verdi presenti nella figura indicano due backup che utilizzano lo stesso LSN.

Modalità di riutilizzo dei numeri LSN in fork di recupero diversi

Se è necessario che una sequenza di ripristino incorpori i backup che attraversano un fork di recupero, la sequenza di ripristino dovrà essere creata in modo che i backup utilizzati seguano il percorso di recupero corretto fino al punto di recupero. A tal fine, i backup includono un GUID del primo fork di recupero e un GUID dell'ultimo fork di recupero.

Questi GUID, insieme agli altri metadati attinenti alla registrazione di percorsi di recupero, vengono archiviati nella tabella della cronologia backupset e vengono restituiti anche dall'istruzione RESTORE HEADERONLY. Nella tabella riportata di seguito sono riepilogati i valori dei metadati relativi alle sequenze di ripristino che attraversano un fork di recupero. Per questi valori i nomi delle colonne sono diversi per quanto riguarda la tabella della cronologia e il set di risultati dell'istruzione RESTORE HEADERONLY:

LSN

Descrizione

backupset - nome della colonna

RESTORE HEADERONLY - nome della colonna

GUID del primo fork di recupero

ID per il fork di recupero iniziale.

first_recovery_fork_guid

FirstRecoveryForkID

GUID dell'ultimo fork di recupero

ID per il fork di recupero finale.

last_recovery_fork_guid

RecoveryForkID

Primo LSN

Numero di sequenza del file di log del primo record di log o del record di log meno recente nel set di backup

first_lsn

FirstLSN

Ultimo LSN

Numero di sequenza del file di log del record di log successivo dopo il set di backup.

last_lsn

LastLSN

LSN del punto di fork

Numero di sequenza del file di log di un punto di fork se il GUID del primo punto di recupero è diverso (≠) dal GUID dell'ultimo punto di recupero. In caso contrario, nel backup non si verifica alcun fork di recupero e il punto di fork LSN è NULL.

fork_point_lsn

ForkPointLSN

GUID a base differenziale

Per un backup differenziale basato su un solo backup, il valore è l'identificatore univoco del backup differenziale.

Per i backup differenziali basati su più backup, il valore è NULL e la base differenziale deve essere determinata a livello di file. Per ulteriori informazioni, vedere backupfile (Transact-SQL).

Per i tipi di backup non differenziale il valore è NULL.

differential_base_guid

DifferentialBaseGUID

Nella restante parte di questa dissertazione vengono utilizzati solo i nomi dei valori presenti nella tabella di cronologia backupset.

  • Il GUID dell'ultimo fork di recupero e il GUID del primo fork di recupero vengono utilizzati per collegare i backup e garantire che la sequenza segua il fork corretto. Per ogni backup del log nella sequenza da ripristinare, first_recovery_fork_guid deve essere uguale a last_recovery_fork_guid del backup precedente nella sequenza.

    first_recovery_fork_guid = last_recovery_fork_guid

  • È inoltre necessario collegare i backup di dati e differenziali.

    Se il backup del log include sia l'ultimo LSN di un backup completo del database o un backup differenziale del database sia un punto di fork, il test di collegamento dipende dal percorso dell'ultimo LSN rispetto al punto di fork.

    I test di collegamento sono i seguenti, utilizzando i valori di backupset:

    • Se last_lsn è minore o uguale a fork_point_lsn, last_recovery_fork_guid del backup di dati o differenziale deve essere uguale a first_recovery_fork_guid del backup del log. Nella figura seguente viene illustrato un caso in cui last_lsn è minore di fork_point_lsn.

      last_lsn è minore di fork_point_lsn

    • Se last_lsn è maggiore di fork_point_lsn, last_recovery_fork_guid del backup di dati o differenziale deve essere uguale a last_recovery_fork_guid del backup del log. Nella figura seguente viene illustrato un caso in cui last_lsn è maggiore di fork_point_lsn.

      last_lsn è maggiore di fork_point_lsn

  • Per un backup differenziale, è possibile individuarne la base utilizzando backupset.differential_base_guid.

    Se il backup differenziale include più basi, backupset.differential_base_guid è NULL ed è necessario determinare le basi del backup differenziale per ogni file utilizzando backupfile.differential_base_guid.