Perché un backup differenziale non può specificare la sua base?

Questo è il mio primo post su DBA.SE, quindi per favore informatemi di eventuali errori, grazie!

Sono un nuovo DBA (non un professionista IT, solo nessun altro in azienda per farlo), quindi più la spiegazione è basilare, meglio è. Ho letto delle strategie di backup del database (o, come ho imparato a chiamarle, "ripristinare le strategie"). Comprendo cosa fanno i backup completi, differenziali e dei registri delle transazioni, ma voglio sapere perché un backup differenziale può essere basato solo sul backup completo più recente.

Se un backup differenziale è tutto ciò che è cambiato dall'ultimo backup completo, perché il differenziale non può essere basato su alcun backup di mia scelta? Per essere più chiari, sto chiedendo di specificare la base quando viene eseguito il backup , non durante il ripristino. Suppongo che durante il ripristino si scelga la base corretta e il differenziale corrispondente per eseguire il ripristino (non utilizzare un differenziale creato dalla base B per ripristinare dalla base A).

Qual è il motivo che impedisce che questa funzionalità sia possibile? Immagino che ci debba essere un motivo, semplicemente non so cosa sia.

Nota: capisco che la base non può essere specificata, ma la mia domanda è: perché no ? (Inoltre, non sono interessato alla discussione sul "perché dovresti?")

Analogia

Ecco un'analogia per come capisco un backup differenziale:

Ho un file Excel con alcuni dati nelle celle.

Il primo giorno, faccio una copia di questo file e lo memorizzo altrove (il "backup completo").

Il giorno 2, guardo il file e lo confronto con la copia di backup che ho fatto il giorno 1, e noto tutte le celle che sono cambiate e quali sono i loro nuovi valori (un "backup differenziale"). Non sto notando ogni modifica apportata a una cella, solo quale sia il suo valore finale. Se la cella A1 fosse iniziata come "Alfred", cambiata in "Betty", "Charlie", quindi "Dave", noterei solo che "A1 ora è Dave".

Il giorno 3, confronto nuovamente il file corrente con il file di backup e prendo atto delle modifiche (un altro "backup differenziale" con la stessa base del giorno 2). Ancora una volta, notando solo i valori finali per cella al momento osservato, non tutti i valori che la cella è stata durante il giorno.

Il giorno 4, confronto nuovamente e prendo atto delle modifiche. Continuando con la cella A1, ora dice "Sarah", anche se c'erano altri 10 nomi durante il giorno, e tutto ciò che noto è "Ora A1 è Sarah".

Il giorno 5, il mio file viene incasinato; quindi, guardo la copia di backup che ho fatto il giorno 1, quindi gli stati finali annotati il ​​giorno 4, e applico le modifiche annotate alla copia di backup e ora ho il file "ripristinato" come era il giorno 4 Quindi, guardo il backup effettuato il giorno 1, vedo che il giorno 4 la cella A1 è terminata come "Sarah" e cambio la cella di backup A1 in "Sarah".

Perché dovrebbe importare se avessi fatto un'altra copia di backup ("completa") del file il giorno 2? Perché non sarebbe ancora possibile confrontare (leggere, "eseguire un backup differenziale di") il file il giorno 3 o 4 con la copia fatta il giorno 1? A quanto ho capito, SQL Server mi richiederebbe di confrontare (quando si esegue un altro backup differenziale) con un backup completo eseguito il giorno 2 (se ne fosse stato effettuato uno) - nessun'altra opzione.

Un backup differenziale utilizza quella che viene definita la mappa di modifica differenziale per creare un elenco di pagine che sono state modificate dall'ultimo backup completo. Questo elenco è un elenco "differenziale", da cui il nome del tipo di backup e il motivo per cui il backup può essere ripristinato solo in cima al backup completo associato.

L'esecuzione di un backup completo ripristina la mappa delle modifiche differenziali. Da quel momento in poi, qualsiasi pagina modificata viene registrata nella mappa. Se si prende quindi un differenziale, quel backup contiene solo pagine che sono state modificate dall'ultimo backup completo e registrate nella mappa.

Nella tua analogia, i due backup completi, che fungono da base per l'intero processo di ripristino, avrebbero probabilmente contenuti diversi e quindi mappe differenziali diverse. Se si ripristina un diff basato sul primo backup sul secondo backup, è probabile che il database sia danneggiato. In effetti, SQL Server impedisce il ripristino di un backup diff su qualsiasi cosa ad eccezione del backup completo originale su cui si basa.

Quando si richiede a SQL Server di eseguire un backup differenziale, l'unica "base" per il differenziale è la singola mappa di modifica differenziale presente nel database al momento dell'avvio del backup differenziale. Questo è il motivo per cui non è possibile specificare la base per il backup differenziale.

In risposta a un commento di @MartinSmith, potresti essere in grado di utilizzare i COPY_ONLYbackup per ripristinare un backup differenziale su un numero di backup completi. Considera il seguente scenario:

1. BACKUP DATABASE xyz TO DISK = 'path_to_backup.bak';
2. BACKUP DATABASE xyz TO DISK = 'path_to_backup_2.bak' WITH COPY_ONLY;
3. BACKUP DATABASE xyz TO DISK = 'path_to_backup_3.bak' WITH COPY_ONLY;
4. BACKUP DATABASE xyz TO DISK = 'path_to_backup_4.bak' WITH COPY_ONLY;
5. BACKUP DATABASE xyz TO DISK = 'path_to_backup_diff.bak' WITH DIFFERENTIAL;

Il backup differenziale nel passaggio 5 dovrebbe essere in grado di essere ripristinato su uno qualsiasi dei backup eseguiti nei passaggi da 1 a 4, poiché la mappa di modifica differenziale viene cancellata solo quando si verifica il backup completo nel passaggio 1. I COPY_ONLYbackup nei passaggi 2, 3 e 4 non ripristinano la mappa delle modifiche. Poiché la mappa delle modifiche differenziali accumula le modifiche apportate dal backup completo, ciascuno dei COPY_ONLYbackup successivi contiene informazioni sufficienti affinché il backup differenziale funzioni con uno qualsiasi dei 4 backup precedenti.

Anche se sembra che dovrebbe funzionare, in pratica, il ripristino di un differenziale sopra un backup copy_only provoca il seguente errore:

Messaggio 3136, livello 16, stato 1, riga 1
Questo backup differenziale non può essere ripristinato perché il database non è stato ripristinato allo stato precedente corretto.
Messaggio 3013, livello 16, stato 1, riga 1
RIPRISTINA DATABASE si sta chiudendo in modo anomalo.

Ho creato una repro della piattaforma SQL Server 2012 per testare i ripristini differenziali e copy_only e ho salvato il file su gist.github.com - ATTENZIONE lo script eliminerà qualsiasi database indicato RestoreTestcome primo passo.

La funzionalità desiderata potrebbe esistere in linea di principio. Non sarebbe efficiente con le attuali strutture di database (vedi la risposta di Max Vernon). SQL Server dovrebbe mantenere un set di mappe diff o confrontare i contenuti del database corrente con il backup completo specificato come base.

Esistono applicazioni che deduplicano file di grandi dimensioni. È possibile eseguire due backup completi e in realtà verranno archiviati solo i dati modificati. Questo è come un diff con base personalizzata. exdupeper esempio può farlo.

La cosa bella è che funziona con qualsiasi set di file di backup. Infatti, a partire dal terzo file di backup completo, pagherai solo un utilizzo dello spazio incrementale (non differenziale). L'utilizzo dello spazio è la differenza rispetto al file di backup precedente (non al primo). La memorizzazione con deduplicazione ha un comportamento simile.

Perché la funzione che descrivi non esiste? Ogni funzione consuma budget, impedendo la presenza di altre funzionalità. Questo apparentemente non lo ha fatto abbastanza lontano nell'elenco delle priorità. Non sono sicuro di cosa sarebbe utile. Sembra un requisito abbastanza esoterico per usare basi personalizzate.

Non confondere i backup del registro delle transazioni con backup differenziali, hanno scopi diversi! Quello che stai chiamando un "backup differenziale", per cui "annoti tutte le modifiche alle celle", è in realtà un registro delle transazioni .

Lo scopo di un backup differenziale è quello di mantenere ridotte le dimensioni del file di backup risultante registrando solo le informazioni che sono state modificate dall'ultimo backup completo e di mantenere il tempo di ripristino all'interno dell'obiettivo del tempo di recupero (RTO).

Lo scopo di un backup del registro delle transazioni è quello di consentire di riprodurre le transazioni in un momento arbitrario - spesso, ma sicuramente non necessariamente "al più recente di tutto ciò che accade".

Ciò di cui stai parlando è infatti possibile, ma è necessario ripristinare il backup completo e quindi ripristinare i registri delle transazioni.

Se hai il backup completo del giorno 1 e tutti i backup del registro delle transazioni tra il giorno 1 e il giorno 5, non c'è nulla che ti impedisca di ripristinare il backup del giorno 1 e riprodurre il registro delle transazioni fino a quando non hai i dati come erano il giorno 4. Tu potrebbe anche iniziare dal backup del secondo giorno, che sarebbe leggermente più veloce da ripristinare, in quanto si riproducono meno transazioni. È inoltre possibile ripristinare il backup completo del giorno 1, il backup differenziale del giorno 3 e quindi ripristinare i registri delle transazioni al giorno 4.

Modifica: OK, la tua analogia modificata ha un po 'più senso. La risposta è quindi "perché puoi già ottenere ciò che desideri con i backup del registro delle transazioni". Un backup differenziale è semplicemente un modo economico e conveniente per registrare un sacco di attività del registro delle transazioni. Non offre granularità per il recupero dei dati che non offre un backup del registro delle transazioni. Ci sono solo così tante funzionalità che offrono "semplice praticità" che lo rendono un prodotto.

Dare un'analogia con Excel sta confrontando mele e arance. Perché ? Excel non è un database in quanto privo di integrità dei dati. Excel è una bella applicazione per fogli di calcolo e potrebbe essere un complemento del database.

SQL Server è un sistema di database relazionale che consente di archiviare tutti i dati e fornisce un meccanismo per interrogarli. La parte importante è "Relazionale" poiché la relazione con i dati è importante insieme all'integrità dei dati (proprietà ACID).

Nozioni di base:

I dati nel database sono organizzati in componenti logici (tabelle, viste, processi, trigger, ecc.) Visibili all'utente. Come minimo, un database viene anche fisicamente implementato come due (file di dati e file di registro) o più (file di dati secondari) sul disco.

• Un database contiene una pagina che è l'unità fondamentale di archiviazione dei dati utilizzata per archiviare i record .
• Una pagina di database è un blocco di 8192 byte (8 KB) di un file di dati del database.
• 8 pagine fisicamente contigue (8 * 8 KB = 64KB) in un file di database di moduli di misura .
• Una pagina IAM (Index Allocation Map) tiene traccia di circa 4 GB di spazio in un singolo file, allineato su un limite di 4 GB. Questi pezzi da 4 GB sono chiamati intervalli GAM .

perché un backup differenziale può essere basato solo sul backup completo più recente. - oppure - Se un backup differenziale è tutto ciò che è cambiato dall'ultimo backup completo, perché il differenziale non può essere basato su alcun backup di mia scelta?

Sulla base della tua analogia su Excel, quello che stai facendo è applicare ciò che è cambiato al primo. Questo sta applicando tutte le transazioni impegnate dal registro delle transazioni with STOP AT(nota: il giorno 5 il file viene incasinato e ti fermi al giorno 4)

In ogni sezione da 4 GB (chiamata intervallo GAM) di ogni file di dati è presente una pagina di database speciale denominata bitmap differenziale che tiene traccia delle parti (chiamate estensioni) di quella sezione da 4 GB che sono state modificate dall'ultimo backup completo, indicando che i dati sono stati modificati o stato aggiunto al database.

Un backup differenziale analizza queste bitmap e esegue il backup solo delle estensioni dei file di dati contrassegnate come modificate. Le bitmap vengono reimpostate dal successivo backup completo (quindi un backup differenziale può essere basato solo sul backup completo più recente) , quindi è possibile notare che, man mano che un numero sempre maggiore di database cambia, un numero maggiore di esso verrà contrassegnato nelle bitmap differenziali e i backup differenziali successivi saranno sempre più grandi.

È anche possibile utilizzare questo script per scoprire Quanto del database è cambiato dall'ultimo backup completo? .

Le informazioni sulla base differenziale sono memorizzate nel masterdatabase - sys.database_fileo ( sys.master_files- utile quando il database è read_only o offline).

Esistono 3 colonne importanti che memorizzano le informazioni relative alla base differenziale .

• La differential_base_lsnè la base per i backup differenziali. Le estensioni di dati che vengono modificate successivamente differential_base_lsnverranno incluse nel backup differenziale.
• Il differential_base_guidè l'identificatore univoco del backup di base su cui si basa un backup differenziale.
• Il differential_base_timeè il tempo corrispondente adifferential_base_lsn

Un backup differenziale è utile per accelerare l'RTO (Recovery Time Objective = tempo impiegato per ripristinare il database) al contrario di backup completi più frequenti che saranno un problema per database di grandi dimensioni o ripristinano il volume dei backup del log delle transazioni in quanto potrebbero aumentare nel tempo.

Nota: un backup completo COPY_ONLY non ripristina la base differenziale, quindi un backup COPY_ONLY non può fungere da base differenziale.

Riferimenti :

• Anatomia di una pagina
• Anatomia di un disco
• Comprensione dei backup di SQL Server