5 modi per tenere al sicuro i tuoi dati

Diciamocelo: quante aziende possono dire con certezza che, nel caso di un qualsiasi malaugurato evento, riuscirebbero a ripristinare il loro ambiente di gestione dei database con velocità e senza perdere (quasi) nessun dato? Nelle esperienze fatte quotidianamente durante i nostri health check posso dire, molto poche.

Ci sono vari fattori che giustificano questa affermazione (l'inconsapevolezza, la "pseudo" complessità del tema, la competenza del personale, la pigrizia, etc) ma sta di fatto che, quando accade l'evento funesto, ci si trova di fronte agli utenti che, nel giro di pochi minuti, alzano il telefono o si presentano in ufficio, con aria più o meno minacciosa, e chiedono quando sarà possibile utilizzare nuovamente il loro software e se avranno perso dati.

In qualità di amministratore dell'infrastruttura, dobbiamo sapere come sviluppare procedure e piani di ripristino di emergenza che proteggano adeguatamente una serie di processi aziendali alimentati da SQL Server. Vediamo, molto velocemente e rimandando alle prossime settimane per un approfondimento, quali sono le tecnologie native di SQL Server che possono aiutarci ad avere sonni più tranquilli.

Il backup rimane la tecnologia DR fondamentale. Sono supportati backup completi del database, backup differenziali e backup dei file di registro. La maggior parte delle organizzazioni esegue regolarmente un backup completo del database accompagnati da backup differenziali e frequenti backup dei log delle transazioni durante il giorno. I backup dei log consentono di ripristinare il database in un momento specifico. Sono supportati sia la compressione che la crittografia. SQL Server consente di eseguire il backup dei database utilizzando SQL Server Management Studio (SSMS), comandi T-SQL BACKUP o PowerShell. Disponibile in tutte le edizioni di SQL Server. Leggi l'approfondimento sul backup in Microsoft SQL Server.

La distribuzione dei log delle transazioni fu inclusa in SQL Server dalla versione di SQL Server 2000, ma era possibile implementare la stessa funzionalità anche nelle versioni precedenti. Si può dire quindi che questa tecnica è sempre esistita. La distribuzione dei log è supportata sia nelle edizioni Standard che Enterprise di SQL Server.

In uno scenario di Log Shipping, sono disponibili almeno due server SQL, il server primario (di produzione) e uno secondario. Questo meccanismo consente di effettuare il backup del log delle transazioni di un database, spedirlo al server secondario e ripristinarlo automaticamente. Ciò significa che c'è molto meno lavoro manuale da fare rispetto al ripristino completo di un backup e meno possibilità di perdita di dati poiché tale eventualità sarebbe limitata ai transaction log non ancora spediti e ripristinati. Ad esempio, se si creano registri delle transazioni ogni 15 minuti, nel peggiore dei casi si perderebbero i dati relativi agli ultimi 15 minuti.

Non è necessario avere un cluster windows ed il costo è limitato solo al possesso delle licenze SQL su entrambi i nodi nell'ipotesi che entrambi siano attivamente utilizzati dalle applicazioni. La tecnica del log shipping non consente un failover automatico.

Disponibile nelle edizioni Enterprise, Standard e Web.

SQL Server AlwaysOn è un termine di marketing che fa riferimento alla soluzione di HA e di ripristino di emergenza introdotta con SQL Server 2012.

 Nel dettaglio, SQL Server AlwaysOn è costituito da due tecnologie: 

• AlwaysOn Failover clustering (FCI)
• Gruppi di disponibilità AlwaysOn (AlwaysOn AG)

Sebbene entrambe le tecnologie presentino somiglianze come la necessità di un cluster a livello di sistema operativo Windows come base per la sua implementazione (Windows Server Failover Clustering), ciascuna di esse ha alcune particolarità:

Le istanze appartenenti ad un failover cluster AlwaysOn (FCI) forniscono protezione a livello di server da errori non prevedibili attraverso un failover automatico e garantendo, con alcune eccezioni, nessuna perdita di dati. Come anticipato, all'interno dei server windows, AlwaysOn FCI richiede l'installazione di un cluster e SQL Server deve essere installato su ciascun nodo utilizzando l'opzione di installazione in cluster di SQL Server. 

Su Linux, utilizzando la versione di SQL Server 2017 o superiore (ebbene sì: la scorsa settimana è stata ufficialmente annunciata la versione 2019), è necessario utilizzare la tecnologia Pacemaker. AlwaysOn FCI è supportato nelle edizioni Standard ed Enterprise di SQL Server 2017 con l'unica limitazione di due nodi nella versione Standard. AlwaysOn FCI può essere utilizzato per DR utilizzando il geo-clustering in cui i diversi nodi del cluster si trovano in posizioni fisiche separate a volte in regioni completamente diverse. Windows Server 2008 e versioni successive supporta cluster multi-sito.

Disponibile nelle edizioni Enterprise e Standard (limitato a due nodi). 

AlwaysOn Availability Groups (AG) è la principale tecnologia HA e DR di SQL Server. AlwaysOn AG viene fornito sia nell'edizione Enterprise che in quella Standard ma con grosse limitazioni (vedi più avanti).

La distribuzione di AlwaysOn AG comporta la configurazione di uno o più gruppi di disponibilità. Ciascun gruppo di disponibilità definisce un set di database utente che può eseguire il failover come singola unità sfruttando un failover cluster di Windows esponendo quindi un unico nome e indirizzo IP di SQL Server alle applicazioni.

La predisposizione del meccanismo di AG prevede l’esecuzione di un backup del database primario e successivo ripristino su uno o più sistemi secondari. All'avvio dell'AG tutte le transazioni dal database primario vengono inoltrate a uno o più database secondari. AlwaysOn AG consente di disporre di entrambi i database secondari in modalità sincrona, in modo da implementare alta disponibilità, oppure asincrona per uno scenario di disaster recovery.

Disponibile nell'edizione Enterprise.

Con SQL Server 2016 Standard Edition è possibile utilizzare AG di base che funzionano esattamente come AlwayOn AG nell'edizione Enterprise, ma con alcune grosse limitazioni:

• Limite di due repliche (primaria e secondaria).
• Nessun accesso in lettura sulla replica secondaria.
• Nessun backup sulla replica secondaria.
• Nessun controllo di integrità sulle repliche secondarie.
• Supporto per un singolo database
  
  

Nella sostanza i BAG sostituiscono la funzionalità deprecata di mirroring del database (vedi sotto) e garantiscono un livello simile di supporto della funzionalità.

Le AG di base richiedono la scelta tra replica sincrona per HA o replicazione asincrona per DR.

Disponibile nell'edizione Standard.

Le ultime versioni di SQL Server includono una tecnologia denominata Database Mirroring in grado di fornire HA o DR. Tale funzionalità è limitata ad un singolo database ed è anche in questo caso possibile scegliere tra la replica sincrona o asincrona. Diversamente dalle AG, il mirroring del database non richiede un cluster di failover di Windows Server (o Pacemaker su Linux). Tuttavia, Microsoft ha deprecato tale funzionalità, il che significa che non verrà inclusa nelle future versioni di SQL Server a favore dell'utilizzo di AlwaysOn AG o Basic AG.

Il disastro può colpire in qualsiasi momento. Si presenta in diverse forme che vanno dall'hardware difettoso alle catastrofi naturali, all'errore umano. Basta veramente poco per prendere consapevolezza del problema e mettere in campo le misure minime per poter reagire con prontezza e senza particolari disagi ad un situazione potenzialmente grave.

di Cristiano Gasparotto, pubblicato il 24 agosto 2018