Condividi tramite

  • Articolo

Pianificazione del recupero di emergenza

Quando si gestisce un database di SQL Server, la preparazione del recupero da potenziali emergenze è fondamentale. Un piano di backup e di ripristino ben progettato e testato per i backup di SQL Server è fondamentale per il recupero dei database dopo un'emergenza. Per ulteriori informazioni, vedere Introduzione alle strategie di backup e ripristino in SQL Server. Inoltre, per verificare che sia possibile ripristinare rapidamente il funzionamento di tutti i sistemi e dati in caso di emergenza, è necessario creare un piano di ripristino di emergenza. Quando si crea questo piano, prendere in considerazione scenari relativi ai diversi tipi di emergenze che potrebbero colpire l'attività. Questi includono disastri naturali, ad esempio un incendio, ed emergenze di carattere tecnico, ad esempio un errore su due dischi in una matrice RAID-5. Quando si crea un piano di ripristino di emergenza, è necessario identificare e preparare tutti i passaggi necessari per rispondere a ogni tipo di emergenza. È necessario testare i passaggi di recupero per ogni scenario. È consigliabile verificare il piano di ripristino di emergenza tramite la simulazione di un disastro naturale.

Quando si progetta il piano di backup e ripristino, è consigliabile considerare, ai fini della pianificazione del ripristino di emergenza, le specifiche esigenze dell'ambiente operativo e dell'azienda. Si supponga ad esempio che un incendio distrugga il centro di assistenza tecnica continua. Occorrerà chiedersi se il recupero è possibile, quanto tempo sarà necessario per rendere nuovamente disponibile il sistema e quale sarà il livello di perdita di dati tollerabile.

In linea teorica, un piano di ripristino di emergenza deve stabilire il tempo necessario per il recupero e lo stato finale del database previsto. Ad esempio, si potrebbe stabilire che il recupero può essere completato in 48 ore, dopo l'acquisizione dell'hardware necessario, e che è possibile garantire il recupero dei dati solo fino alla fine della settimana precedente.

Un piano di ripristino può essere strutturato in molti modi diversi e contenere vari tipi di informazioni. Di seguito sono indicati alcuni tipi di piani di ripristino di emergenza:

  • Un piano per l'approvvigionamento di componenti hardware.

  • Un piano per le comunicazioni.

  • Un elenco di persone da contattare in caso di emergenza.

  • Istruzioni per contattare le persone che parteciperanno alle operazioni di recupero.

  • Informazioni sul responsabile della gestione del piano.

  • Un elenco di controllo di attività necessarie per ogni scenario di recupero. Per semplificare l'esame dell'andamento del ripristino di emergenza, contrassegnare ogni attività man mano che viene completata e indicare l'ora di completamento nell'elenco di controllo.

Modelli di recupero di SQL Server

SQL Server offre tre modelli di recupero alternativi: con registrazione minima, con registrazione completa e con registrazione minima delle transazioni bulk. Il modello di recupero è una proprietà del database che consente di controllare il comportamento di base di operazioni di backup e ripristino per un database. La selezione del modello di recupero più adatto per ogni database è una parte fondamentale della pianificazione della strategia di backup e ripristino. La scelta del modello di recupero per un determinato database dipende in parte anche dai requisiti specifici a livello di disponibilità e di recupero. e influisce a sua volta sulla possibilità di ripristino di un database in caso di emergenza.

Per informazioni introduttive sui modelli di recupero, vedere Panoramica del modello di recupero.

Gestione dei supporti di backup

È consigliabile che il piano di backup tenga conto delle esigenze a livello di gestione dei supporti di backup e includa, ad esempio:

  • Un piano di verifica e gestione per l'archiviazione e il riutilizzo dei set di backup.

  • Una pianificazione per la sovrascrittura dei supporti di backup.

  • Per un ambiente multiserver, la scelta tra backup centralizzati e backup distribuiti.

  • Un metodo per la registrazione della vita utile dei supporti.

  • Una procedura per ridurre al minimo gli effetti della perdita di un set o di un supporto di backup, ad esempio un nastro.

  • La scelta di archiviare i set di backup in sede o fuori sede, con analisi dell'impatto sui tempi di recupero.

Per informazioni sull'utilizzo dei dispositivi e dei supporti di backup in SQL Server, vedere Utilizzo di supporti di backup in SQL Server.

Esecuzione di uno script di funzionalità di base

Il piano di ripristino di emergenza include in genere uno script delle funzionalità di base, allo scopo di confermare il corretto funzionamento di tutti gli elementi. Uno script di funzionalità di base costituisce uno strumento affidabile per consentire all'amministratore del sistema o del database di verificare che il database sia stato riportato in uno stato utilizzabile, senza dipendere dagli utenti finali per questa verifica.

Uno script di funzionalità di base è specifico di un'applicazione e può assumere varie forme. Ad esempio, in un sistema di supporto decisionale o di gestione dei report, lo script può semplicemente essere una copia di alcune delle query chiave di gestione dei report. In un'applicazione per l'elaborazione delle transazioni in linea (OLTP, Online Transaction Processing) può essere un batch di stored procedure che eseguono istruzioni INSERT, UPDATE e DELETE. Ad esempio, uno script di funzionalità di base potrebbe essere un semplice file con estensione sql che invia istruzioni SQL batch al server dall'utilità sqlcmd. Un altro esempio è rappresentato dall'utilizzo di un file con estensione bat contenente i comandi bcp e osql.

Valutazione del livello di preparazione alle emergenze

Per verificare di essere pronti per un'emergenza, è consigliabile eseguire periodicamente le attività seguenti:

  • Verificare accuratamente le procedure di backup e di recupero prima del verificarsi di un errore effettivo. L'esecuzione di test contribuisce ad assicurarsi che siano disponibili i backup necessari per eseguire il recupero in seguito a diversi errori, che le procedure siano definite e documentate in modo chiaro e che possano essere eseguite senza difficoltà e rapidamente da qualsiasi operatore qualificato.

  • Eseguire backup regolari dei database e dei log delle transazioni per ridurre al minimo la perdita di dati. È consigliabile eseguire il backup sia dei database utente che di sistema.

  • Gestire i registri di sistema con misure di protezione adeguate. Tenere traccia di tutti i service pack installati in Microsoft Windows e SQL Server. Tenere traccia delle librerie di rete utilizzate e della modalità di protezione. Se in SQL Server è in esecuzione l'autenticazione in modalità mista (Autenticazione di SQL Server e di Windows), registrare la password sa in una posizione protetta. Per ulteriori informazioni, vedere Sicurezza e protezione (Motore di database).

    Nota importanteImportante

    L'autenticazione di Windows offre una protezione decisamente maggiore rispetto all'autenticazione di SQL Server. Se possibile, utilizzare l'autenticazione di Windows.

  • In un altro server determinare i passaggi necessari per il recupero in seguito a un'emergenza. Se è necessario, modificare i passaggi secondo le necessità in base all'ambiente server locale e testare i passaggi modificati.

  • Creare e gestire uno script di funzionalità di base per la valutazione rapida delle capacità minime necessarie.

Controllo e riduzione degli errori utente potenzialmente gravi

Uno degli scenari di recupero più complessi è il recupero da un errore grave, ad esempio l'eliminazione involontaria di oggetti del database. In questa sezione vengono elencati alcuni strumenti utilizzabili per il controllo, e talvolta per la regolazione, delle modifiche al database.

  • Trigger DDL (Data Definition Language)

    Questi trigger possono essere creati per il controllo e la regolazione di determinate modifiche allo schema del database. I trigger DDL attivano stored procedure in risposta a varie istruzioni DDL. Si tratta essenzialmente di istruzioni che iniziano con CREATE, ALTER e DROP. L'ambito di un trigger DDL è un particolare database o un'intera istanza server. Per ulteriori informazioni, vedere Informazioni sui trigger DDL.

  • Notifiche di eventi

    Le notifiche degli eventi vengono eseguite in risposta a varie istruzioni DLL Transact-SQL ed eventi di Traccia SQL e inviano informazioni relative a tali eventi a un servizio di Service Broker.

    È possibile programmare le notifiche degli eventi per molti degli eventi acquisiti dalla funzionalità Traccia SQL. A differenza della creazione di tracce, le notifiche degli eventi possono essere utilizzate per eseguire un'azione all'interno di un'istanza di SQL Server in risposta a eventi. Poiché le notifiche degli eventi vengono eseguite in modo asincrono, queste azioni non utilizzano risorse definite dalla transazione immediata. Per ulteriori informazioni, vedere Notifiche degli eventi (Motore di database).

    [!NOTA]

    Nei trigger DDL non è possibile utilizzare tutti gli eventi DDL. Alcuni eventi sono destinati esclusivamente a istruzioni asincrone non incluse in transazioni. Non è ad esempio consentita la specifica di un evento CREATE DATABASE in un trigger DDL. Per tali eventi è invece necessario utilizzare le notifiche degli eventi.

  • SQL Server Agent

    Si tratta di un servizio di Windows che esegue attività amministrative pianificate, dette processi. Per l'archiviazione delle informazioni sui processi, in SQL Server Agent viene utilizzato SQL Server. Tra le altre cose, SQL Server Agent può eseguire un processo in risposta a un evento specifico, ad esempio errori con un livello di gravità o un numero di messaggio specifico.

    Per un'introduzione a SQL Server Agent, vedere Automatizzazione delle attività amministrative (SQL Server Agent). Per informazioni sull'utilizzo di SQL Server Agent, vedere Monitoraggio e risposta agli eventi.

  • Traccia SQL

    Traccia SQL offre stored procedure di sistema Transact-SQL per la creazione di tracce in classi di evento selezionate dall'utente in un'istanza di Motore di database di SQL Server. Queste stored procedure di sistema possono essere utilizzate all'interno delle applicazioni dell'utente per creare tracce manualmente. Per ulteriori informazioni, vedere Introduzione a Traccia SQL.

    [!NOTA]

    SQL Server Profiler è un'interfaccia utente grafica per Traccia SQL che consente di monitorare un'istanza di Motore di database o Analysis Services. Per ulteriori informazioni, vedere Utilizzo di SQL Server Profiler.