Attualmente, nel settore esistono molte tecnologie di ripristino dopo un disastro (DR) tra cui il mirroring del database, la clusterizzazione e le soluzioni di replica. Tuttavia, l'invio dei log è un metodo più semplice da configurare e gestire. Questo articolo illustrerà i passaggi per il ripristino dopo un disastro di SQL Server utilizzando l'invio dei log.
Soluzione di Ripristino da Disastri con Log Shipping
Il log shipping mantiene principalmente le copie di backup su un server secondario e prende il controllo del server principale quando necessario, al fine di migliorare la disponibilità complessiva del database. In altre parole, quando il database principale diventa indisponibile a causa di un disastro, è possibile attivare manualmente il database secondario per continuare a fornire i servizi.
Per configurare il log shipping per un database, SQL Server crea i seguenti tre processi agente per automatizzare le operazioni di backup, copia e ripristino:
Il primo processo viene eseguito sull'istanza primaria. Esegue il backup del registro delle transazioni sul database primario.
Il secondo processo viene eseguito sul server secondario. Esso copia i backup dei log dal server principale al server secondario.
Anche il terzo processo viene eseguito sul server secondario. Esso ripristina i backup dei log e aggiorna le voci del registro nel database secondario.
Considerazioni prima di configurare il log shipping in SQL Server
Anche se la configurazione del log shipping non è difficile, devono essere tenute in considerazione alcune cose prima dell'implementazione:
Protezione a livello di database: Se è necessario proteggere solo un numero ridotto di database in caso di disastro, questo livello è sufficiente. Tuttavia, se si desidera mantenere più database a livello dell'istanza di SQL Server, una soluzione log shipping autonoma non è adeguata.
Failover manuale sul server secondario: La spedizione dei log da sola non può effettuare automaticamente il failover dal server primario al server secondario. È necessario attivare manualmente il database secondario.
Configurazione manuale dell'accesso SQL: Gli accessi SQL non vengono trasferiti automaticamente dal server principale al server secondario. È necessario trasferire le credenziali di accesso dall'istanza del server principale a quella del server secondario per sincronizzare gli accessi. Inoltre, spesso è necessario creare manualmente vari piani di manutenzione, server collegati, e pacchetti SSIS (SQL Server Integration Services) sul server secondario.
Rischio di perdita di dati: In genere, quando il database primario diventa non disponibile, è possibile ripristinare soltanto l'ultimo backup del registro delle transazioni. Questo significa che tutte le transazioni avvenute dopo l'ultimo backup del registro inviato al server secondario andranno perse. Ad esempio, se il server primario si guasta alle 9:00 e l'ultimo backup copiato nell'istanza B del server secondario era alle 8:45, allora tutti i dati dalle 8:45 alle 9:00 andranno persi.
Reverse log shipping: Questa funzionalità è utile quando si modificano i ruoli dei server senza eseguire un backup completo del database. Ad esempio, se si dispone di un backup di grandi dimensioni e si desidera trasferire i dati dal server secondario a un server primario remoto, potrebbe essere necessario molto tempo per copiare l'intero backup.
Come configurare e utilizzare il log shipping?
Normalmente, il processo di configurazione del log shipping può essere suddiviso in due passaggi distinti:
Passo 1 – Inizializzare il Database sul Server Secondario
Supponiamo di avere due database nell'istanza del server principale e di dover spedire i log per TestDB1 a un server secondario che inizialmente non ha database. È importante notare che per configurare il log shipping, il database deve essere in modalità di recupero FULL o BULK-LOGGED. Se il database è in modalità di recupero SIMPLE, il log shipping non riuscirà perché non si potranno utilizzare i backup del log delle transazioni.
1. Per prima cosa, è necessario eseguire un backup completo del database e un backup del log delle transazioni. È possibile eseguire le seguenti query T-SQL per creare backup "completi" e backup del "log delle transazioni":
backup database TestDB1 to disk = 'c:\backup\TestDB1.bak'
backup log TestDB1 to disk = 'c:\backup\TestDB1.bak'
2. Successivamente, ripristinare il backup sul server secondario.
3. Nell'interfaccia Restore Database, selezionare Device come origine dati e fare clic sul relativo icona.
4. Nella finestra di dialogo Select backup devices, fare clic su Add.
5. Selezionare il file di backup da ripristinare e fare clic su OK.
6. Esegui il ripristino del backup TestDB1.
7. Fare clic su Select a page e andare su Files per modificare, se necessario, i percorsi dei file del database fisico.
8. Successivamente, fare clic su Options sulla sinistra. Nella pagina Options, selezionare RESTORE WITH STANDBY dall'elenco a discesa Recovery state. Tenere presente che la selezione di RESTORE WITH STANDBY garantisce che il database rimanga in modalità sola lettura. Se si sceglie RESTORE WITH NORECOVERY, il database non sarà accessibile.
9. Dopo aver selezionato lo stato di recupero appropriato, fare clic su OK per garantire un ripristino corretto. Verrà così ripristinato TestDB1 in modalità Standby (sola lettura) sull'istanza del server secondario.
A questo punto, il database è stato inizializzato correttamente sul server secondario.
Passo 2 – Abilita il Database Primario
1. Fare clic con il tasto destro su TestDB1 nell'istanza del server primario e selezionare Properties.
2. Selezionare Enable this as the primary database in the log shipping configuration.
Per impostazione predefinita, il log delle transazioni viene eseguito il backup ogni 15 minuti. Tuttavia, a volte il log delle transazioni può diventare troppo grande per essere copiato e ripristinato entro il limite di tempo prestabilito. Per risolvere questo problema, è necessario pianificare backup aggiuntivi del log. Fare clic su Impostazioni backup, specificare il percorso del file di backup nell'interfaccia delle impostazioni del backup del log delle transazioni, quindi fare clic su Pianifica e modificare la frequenza del backup in modo che venga eseguito ogni 1-2 minuti.
3. Fare clic su Add per configurare il database secondario. Il sistema ti chiederà di connetterti all'istanza del server secondario.
4. Come configurato nel passaggio 1, nell'interfaccia Secondary Database Settings , selezionare No, the secondary database is initialized.
5. Procedere alla copia dei file specificando il percorso della cartella di backup del server secondario, impostando la frequenza del backup e facendo clic su OK.
6. Nell'interfaccia Restore Transaction Log, impostare lo stato del database su Standby mode e selezionare Disconnect users in the database when restoring backups. Dopo aver impostato l'intervallo di backup, fare clic su OK.
7. Per aggiungere l'istanza del server secondario e il database, fare clic su OK per creare processi dell'agente SQL Server.
Sotto l'agente SQL Server sul server principale, troverai il processo di backup del log delle transazioni.
Nell'ambito di SQL Server Agent sul server secondario, verranno individuati due nuovi processi: uno che copia i backup del log delle transazioni dal database principale e un altro che ripristina i backup del log delle transazioni sul database secondario.
8. A questo punto, la soluzione di disaster recovery con il trasporto dei log è completamente configurata. Se il database primario dovesse smettere di funzionare, è possibile attivare immediatamente il database secondario. È inoltre possibile eseguire la seguente query per verificare che il database secondario abbia terminato la modalità standby:
Select * from Products
RESTORE DATABASE TestDB1 WITH RECOVERY
9. Aggiornando il database, noterai che TestDB1 sul server secondario è ora online.
Strategia di protezione dei dati più completa per SQL Server
Durante l'implementazione di soluzioni di ripristino da disastri come il trasporto dei log, le aziende richiedono spesso una strategia di protezione dei dati più completa ed efficiente. Vinchin Backup & Recovery offre una soluzione automatizzata per backup e ripristino progettata specificamente per macchine virtuali e database come SQL Server, supportando backup completi, incrementali e differenziali. Grazie alle tecnologie integrate di deduplica e compressione dei dati, riduce significativamente il consumo di storage e il tempo di backup.
Inoltre, la soluzione di backup Vinchin elimina la necessità di interventi manuali complessi, permettendo una protezione automatica del database e supportando la migrazione tra piattaforme e l'archiviazione nel cloud. In caso di guasti al server SQL, Vinchin aiuta gli amministratori a ripristinare rapidamente i database, prevenendo la perdita di dati e lunghi tempi di inattività, offrendo così alle aziende una garanzia più completa per il ripristino da disastri.
Per creare processi di backup del database SQL Server, visitare la pagina Backup fisico > Backup database > Backup:
1. Selezionare i database da cui eseguire il backup.
2. Selezionare un nodo di backup su cui si desidera che i dati di backup vengano elaborati e archiviati.
3. Configura le strategie di backup in base alle tue esigenze.
4. Rivedi e conferma le impostazioni.
Fai clic sul pulsante qui sotto per provare la prova gratuita di 60 giorni di Vinchin e scoprire una soluzione efficiente e affidabile per il backup e il ripristino dei dati!
Domande frequenti sul ripristino di emergenza di SQL Server
1. Qual è la differenza tra disponibilità elevata (HA) e ripristino di emergenza (DR)?
HA garantisce un tempo di inattività minimo utilizzando cluster di failover, gruppi di disponibilità Always On o mirror del database, mentre DR si concentra sul ripristino del servizio dopo guasti catastrofici, spesso utilizzando backup fuori sede o centri dati secondari.
2. Cos'è un'istanza del cluster di failover di SQL Server (FCI) e come contribuisce alla gestione del disastro (DR)?
Un FCI è una soluzione ad alta disponibilità che utilizza Windows Server Failover Clustering (WSFC) per fornire un failover automatico a livello di istanza SQL Server. Richiede una memorizzazione condivisa (SAN, Storage Spaces Direct o soluzioni basate su cloud). È ideale per l'alta disponibilità on-premises, ma non è una soluzione DR da sola, poiché non protegge contro i guasti a livello di sito.
Conclusione
Il log shipping è una soluzione economica, efficiente e semplice per il ripristino da disastri in SQL Server. È la scelta ideale per il ripristino da disastri a livello di database. Tuttavia, per il ripristino da disastri a livello di istanza, è consigliabile valutare altre tecniche di ripristino come il mirroring del database o i cluster di failover. Inoltre, il log shipping può causare perdita di dati. Se è necessario recuperare dati eliminati o inaccessibili da un database SQL danneggiato, valutare l'uso di un software professionale per il recupero di SQL.
