Perché è così importante eseguire il backup del registro delle transazioni?

Attualmente stiamo implementando una soluzione di backup per un client e la loro soluzione ERP utilizza SQL Server.

La soluzione ERP è stata creata da un'altra società. E loro mi dicono che è super importante eseguire il backup e troncare il log delle transazioni.

Ho letto un po 'su questo registro delle transazioni e non capisco perché questo è così importante quando eseguo comunque il backup dell'intera macchina (Stiamo usando ArcServe UDP, che è a conoscenza di SQL Server e usa VSS). Sono consapevole che le attività di pulizia sulla VM di SQL Server si stanno già occupando del troncamento del registro, tuttavia UDP consente anche il troncamento del registro di SQL Server.

Sono consapevole del fatto che il registro delle transazioni può essere utilizzato per ripristinare database danneggiati, perché, beh, è ​​un registro di tutte le transazioni. Ma ho già un backup orario dell'intero database, quindi perché dovrei preoccuparmene?

Devi farlo solo se la tua modalità di recupero DB è impostata su "pieno". Se è impostato su "semplice" non è necessario eseguire un backup del registro delle transazioni. Ma fai attenzione alla differenza tra queste due opzioni!

Prima di tutto: se vuoi essere in grado di ripristinare il DB in un determinato momento devi usare la modalità "full". (Penso che sia possibile regolare i tempi in modo accurato da poter specificare anche i millisecondi per il punto di ripristino) In modalità "semplice" è possibile tornare all'ultimo backup completo .

Se non si esegue il backup / troncamento del registro delle transazioni, aumenterà per tutto il tempo (in modalità completa). Ho visto database in cui il file .trn era più del doppio rispetto al database stesso. Ciò dipende dalla frequenza con cui sono state apportate modifiche al DB.

Un altro punto è che un backup del registro è normalmente più veloce di un backup completo.

Quindi penso che il tuo piano di backup per fare un backup completo ogni ora non sia ottimale. Ma dipende dalla tua situazione:

Se dici: Va bene se riesco a ripristinare il DB nell'ultima ora intera, va tutto bene. -> Puoi anche pensare di impostare la modalità di ripristino su "semplice" se desideri mantenere il backup completo ogni ora.

A mio avviso, un'idea migliore sarebbe quella di eseguire un backup completo al mattino presto e quindi eseguire un backup del registro delle transazioni ogni ora. Dovrebbe essere molto più veloce e sarai in grado di ripristinare in qualsiasi momento tu voglia. E anche il tuo file .trn non crescerà troppo ...

Spero che sia di aiuto.

Bene. Ti preoccupi perché se hai il tuo modello di recupero impostato su pieno e non esegui il backup del registro delle transazioni utilizzando il backup di SQL (e non il backup del server), il registro delle transazioni continua a crescere fino a consumare tutto lo spazio disponibile sul disco. (Una volta ho visto un collega minore installare SQL Server sull'unità di sistema e non eseguire mai il backup del registro delle transazioni. Ha mangiato Windows .)

Sì, ripristinerà anche in un determinato momento. Giù al minuto. Come dice Twinkles, sì, la gente lascia cadere i tavoli e simili.

Non so cosa stai usando per il backup orario dell'intero database e se è lo stesso prodotto di quello che stai usando per l'intera macchina. In tal caso, una soluzione di backup non compatibile con SQL non è supportata per i ripristini. Il tempo impiegato da VSS per copiare i file MDF e LDF può, ad esempio, causare una mancata corrispondenza data / ora interna.

Gestiamo anche diversi sistemi ERP. E il problema è spesso che di notte ci sono spesso lavori batch di lunga durata che sincronizzano i dati con altri sistemi. E a volte impiegano un'ora o più. Quindi, ciò che vuoi fare in caso di crash è saltare a un punto in cui hai dati coerenti. (Il che significa giusto tra due lavori batch.) Se si guarda solo l'ora, è possibile che non si sappia sempre esattamente quale fosse lo stato della banca dati in quel momento.

Ma ovviamente dipende dalla situazione. Se non hai alcun lavoro automatizzato, ecc. Puoi star bene con un backup orario.

Esistono diversi motivi per cui vuoi farlo:

1. Un sistema di database è di solito occupato, forse facendo migliaia di transazioni al secondo. I dati potrebbero essere distribuiti su più file su diversi file system. Non è banale assicurarsi che il database sia in uno stato coerente (ovvero utilizzabile) dopo il ripristino. Se la tua soluzione di backup è all'altezza dell'attività, ottima, ma è meglio esserne sicuri prima di scommettere sul lavoro.
2. Un esempio: qualcuno elimina per errore una tabella con dati importanti. Se si dispone di un backup del database con capacità di recupero temporizzato, è possibile ripristinare rapidamente i dati, senza dover ripristinare l'intero sistema.
3. Se il database è in modalità di recupero completo, il registro delle transazioni di SQL Server aumenterà. Lo spazio di archiviazione nel registro delle transazioni viene riutilizzato solo se è stato eseguito il backup del registro delle transazioni. Se non si esegue regolarmente il backup del registro delle transazioni, il file system verrà riempito fino a quando non rimane spazio. A quel punto tutto si fermerà immediatamente , poiché non è possibile avviare nuove transazioni.

Quando il tuo database si espande oltre ciò di cui puoi eseguire il backup in un'ora, hai bisogno di un modello diverso.

Un backup completo del database troncherà i tuoi registri, ma deve essere "SQL consapevole", perché in quello scenario, è il software di backup che dice al server SQL cosa ha eseguito il backup e cosa troncare.

Come altri menzionano, se si dispone di un database nel modello di recupero "Completo", il registro delle transazioni aumenterà indefinitamente, fino a quando non si esegue un backup compatibile con SQL completo.

Il recupero è davvero il problema qui, non il backup. E non è una decisione tecnica, è una decisione commerciale!

Se i titolari delle aziende sono d'accordo nel perdere un'ora o più delle transazioni del database (che possono essere MOLTO difficili o impossibili da ripetere!), Il modello funziona. Se sono a posto con il sistema inattivo per ore mentre si ripristina l'intero database dal backup, il modello funziona.

Tuttavia, se la tua azienda considera il proprio sistema ERP come una risorsa fondamentale per il loro funzionamento (non tutti?), Impostare un tempo di recupero massimo accettabile (noto anche come RTO, Recovery Time Objective) per i tuoi servizi critici sarà una decisione aziendale.

Inoltre, i proprietari delle imprese o le parti interessate del sistema devono definire la quantità di dati che sono disposti a rischiare di perdere in un incidente, noto anche come RPO (Recovery Point Objective).

La risposta se gli chiedi potrebbe essere "NESSUN dato può essere perso! Il sistema ERP deve essere disponibile 24/7/365!" ... che tutti sappiamo è altamente improbabile che sia conveniente. Se si presentano loro i costi associati alla costruzione di un sistema non-stop completamente ridondante, si otterrà una cifra più ragionevole ..;)

Il punto è che, se puoi evitare di perdere qualsiasi transazione, stai salvando la tua attività potenzialmente centinaia o migliaia di ore di lavoro perse. Ciò equivale a enormi risparmi in qualsiasi azienda e cresce con le dimensioni della tua azienda ...

Tutti hanno avuto ottime risposte a questo, ma vorrei aggiungere un'altra nota importante ... o due.

Conoscere i dettagli dei modelli di recupero di SQL Server e i requisiti aziendali per la perdita di dati sono entrambi molto importanti; tuttavia, in questo caso è indispensabile comprendere come funziona il prodotto di backup con SQL Server. (Sulla base dei commenti sopra, sembra che si stia eseguendo il backup dei volumi del disco tramite VSS copy, il che significa che i backup di SQL Server possono o non possono essere richiesti in aggiunta.)

Dopo aver recentemente valutato un prodotto simile, alcuni dei punti importanti che potresti dover chiedere sono:

• Come vengono eseguiti i ripristini fino a un certo punto nel tempo per un database in pieno recupero?
• Come viene gestito il backup iniziale per un nuovo database in pieno recupero?
• Il prodotto di backup richiede i backup dei log di SQL Server per il ripristino fino a un certo momento? (Nel mio caso, la risposta è stata sì.)
• La tua infrastruttura di archiviazione può gestire il volume di dati per le copie / differenziali VSS (a un determinato intervallo) oltre al normale carico SQL?

Spero sia utile.

L'esperienza del mio team con la nostra recente valutazione ha fornito alcune risposte molto interessanti alle domande precedenti. Una cosa è certa, i backup sono più complessi per noi con un prodotto di backup VSS.

Come molti altri hanno già detto, se si utilizza uno strumento di terze parti per eseguire il backup / snapshot della VM o dell'archiviazione, si corre comunque il rischio di non disporre di un backup valido. Tutti gli strumenti di terze parti che gestiscono i backup di SQL Server implementeranno e si collegheranno a SQL Server tramite VSS. Lo fa per richiedere che SQL Server sospenda tutti gli I / O sui file di dati in modo da poter eseguire uno snapshot coerente. In caso contrario, è possibile avere molte transazioni in vari stati e un ripristino non saprà se tali transazioni possono essere eseguite in avanti o indietro.

Non ho lavorato con tutti gli strumenti di snapshot VM / Storage di terze parti là fuori, ma quelli con cui ho lavorato non sono mai stati in grado di eseguire lo snapshot di archiviazione in cui si trovavano i database di sistema - SQL Server non è in grado di sospendere quei database. Tutti hanno eseguito il backup di quei database in modo streaming, ovvero ... eseguendo i comandi BACKUP DATABASE e quindi eseguendo lo snap del file di backup stesso.

Inoltre, come molti hanno anche detto, se si è nel modello di recupero COMPLETO e non si emettono regolarmente le istruzioni BACKUP LOG, il registro delle transazioni continuerà a crescere fino a quando non c'è più spazio sul disco.

La vera domanda che devi porre e che potrei aver perso sopra ... hai ripristinato con successo da questi backup diverse volte e sei soddisfatto della coerenza dei dati in quei ripristini. Personalmente, anche quello non sarebbe abbastanza per me, sembra comunque un lancio di dadi, ed è qualcosa che un buon DBA non prende mai quando si tratta di backup e ripristino.

Riconosci che i registri delle transazioni non sono semplicemente un meccanismo di recupero. Una corretta manutenzione dei registri può anche svolgere un ruolo critico nelle prestazioni complessive del database (ad esempio, la velocità effettiva delle transazioni).

Il backup frequente dei file di registro fa un paio di cose:

1. Riduce il conteggio VLF nei file di registro fisici che è buono per le prestazioni.
2. È meglio prepararsi a utilizzare i backup del registro nel caso in cui sia necessario ripristinare un database.
3. È un po 'più veloce di un backup completo

Se riesci a cavartela facendo un backup completo ogni ora, non sei sicuro di quanto trarrai beneficio da backup del registro più frequenti. Dopo tutto, come ho capito, un backup completo eseguirà anche il backup di tutto il registro necessario per garantire un ripristino completo.

D'altra parte, se l'app genera tonnellate di transazioni tra i backup completi orari, ciò potrebbe spiegare perché gli sviluppatori originali hanno suggerito una manutenzione più granulare dei log. Molte transazioni potrebbero aumentare il conteggio VLF nei registri, il che può comportare una penalità di prestazione fino a quando il registro non viene troncato. Ho visto questo espresso come un errore di "timeout query scaduto" all'interno di un'applicazione (poco prima che si blocchi).

Le raccomandazioni relative alla manutenzione dei registri delle transazioni sono descritte molto bene in questo articolo 8 Passaggi per migliorare la velocità di trasmissione dei registri delle transazioni . Inoltre, questo articolo Suggerimenti per una manutenzione efficace del database menziona un conteggio VLF alquanto arbitrario per puntare a (<200) che ha funzionato molto bene per me.

Altre persone hanno già fornito la maggior parte dei motivi per un backup del translog ecc. Sembra esserci qualche dubbio sul perché questa sia una buona strategia quando si esegue già il backup del server.

Un paio di buone ragioni sono emerse per me che non sono al di sopra. Cosa succede se l'app di terze parti non riesce a eseguire un backup che è possibile ripristinare? Hai provato a ripristinare il backup? Che dire di un nuovo server che hai appena creato dai tuoi modelli (pensa a DR)? Che dire di un altro server sul tuo dominio che ha regole di confronto diverse? o istanza SQL?

Prendo backup ridondanti per nessun motivo diverso da quello a volte la tua app di terze parti non è il modo più veloce per ripristinare. A volte anche lo spazio di archiviazione su cui viene salvata l'app di terze parti è interessato o è danneggiato per motivi propri.