Iscriviti alla nostra newsletter

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.

1. Backup

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

2. Log shipping

La distribuzione dei log delle transazioni è stata 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. La distribuzione dei log dal server primario a quello secondario, parte con il backup dei database da proteggere, ripristinandoli nel o nei server di destinazione e eseguendo periodicamente una stored procedure per inoltrare e applicare i backup del log delle transazioni a uno o più server di destinazione. Log shipping consente un ritardo specificato dall'utente tra il momento in cui il server primario esegue il backup del transaction log e quando i server di destinazione applicano i backup del log. La tecnica del log shipping non consente un failover automatico.

Disponibile nelle edizioni Enterprise, Standard e Web.

AlwaysOn

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à:

3. AlwaysOn Failover Clustering (FCI)

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). 

 4717_Figure01

4. Gruppi di disponibilità AlwaysOn (AG) e gruppi di disponibilità di base (BAG)

AlwaysOn Availability Groups (AG) è la principale tecnologia HA e DR di SQL Server. AlwaysOn AG viene fornito solo nell'edizione SQL Server Enterprise e permette di proteggere più database con un failover automatico. AlwaysOn AG richiede un cluster su Windows Server o Pacemaker su Linux. AlwaysOn AG funziona eseguendo un backup del database primario e ripristinandolo 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 modod a implementare alta disponibilità oppure asincrona per un DR.

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.

 

4717_Figure02

 

5. Mirroring del database

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.

Conclusioni

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.

Condividi questo post nella tua rete!