Best Way of Your Business
You are here: HomeBlog MySQL: Disaster Recovery!

MySQL: Disaster Recovery!

 

by Vetim 918 views

Un “Disaster Recovery” nell’amministrazione delle basi di dati è in pratica un piano d’emergenza che può essere adottato nel caso in cui un database venga coinvolto da malfunzionamenti o danneggiamenti tali da rendere inaccessibili o inutilizzabili le informazioni archiviate.

Lo scopo di un piano di ripristino è in pratica quello di riportare quanto prima un database nelle condizioni precedenti al verificarsi della problematica che lo ha colpito, per cui è possibile affermare che un piano ben organizzato si contraddistingue per la velocità di risposta ad un malfunzionamento, l’obiettivo (oltre naturalmente a quello relativo alla salvaguardia dell’integrità dei dati) è diminuire quanto più possibile i tempi in cui un servizio rimane off line in attesa del completamento di un ripristino.

Nel corso di questa breve trattazione verranno esaminate le possibili cause di un grave malfunzionamento e i rimedi da pianificare in vista di un’eventuale riattivazione.

Le possibili cause di un disastro

In genere è possibile identificare una caratteristica che accomuna tutti i malfunzionamenti: essi giungono solitamente inaspettati; in generale è molto difficile, se non impossibile, prevedere quando una determinata problematica potrà avere luogo e con quali modalità si presenterà, per questo motivo un buon piano di ripristino può rivelarsi particolarmente utile.

Ma quali possono essere le cause di un disastro a carico di un database? Le tipologie sono molteplici ma è possibile creare alcune macrocategorie in grado di accomunarne la maggior parte:

  • cracking: si tratta di una categoria che ricomprende in sé tutte le tipologie di attacchi informatici provenienti dall’interno di una rete o dall’esterno tramite Internet, con lo scopo di arrecare danno ad un sistema o di sottrarre ai legittimi proprietari le informazioni da esso gestite.
  • errore umano: un evento spesso sottovalutato, che deve essere considerato invece con la massima attenzione perché giunge nella maggior parte dei casi inaspettato; un errore umano è dovuto generalmente all’errata digitazione di un’istruzione SQL come per esempio l’eliminazione di una tabella tramite il comando DROP, l’errato UPDATE di uno o più record, l’utilizzo del comando DELETE senza il ricorso alla clausola WHERE per specificare l’intervallo di record che dovrebbe essere correttamente interessato da un’istruzione per la cancellazione.
  • problematiche di sistema: si tratta di una categoria che racchiude tutti i possibili fattori ambientali che possono causare un danno a carico del funzionamento di una base di dati, di un’applicazione che si interfaccia ad un database o di un Database manager. Si pensi per esempio di dover effettuare un aggiornamento per un sistema operativo, si immagini inoltre di dover effettuare un riavvio della piattaforma e che al fine di questa procedura il sistema non riesca ad riattivare i processi arrestati (ad esempio per un kernel panic su Linux o una schermata blu su Windows), in questo caso è molto probabile che il DBMS non subisca alcun danno, ma non potrà funzionare in quanto l’Os non sarà in grado di attivarne il relativo processo.
  • problematiche hardware: anche per quanto riguarda questa categoria non ci si trova davanti ad un problema che riguarda direttamente le basi di dati o il DBMS che le gestisce, ma la macchina che ospita fisicamente i dati (physical disaster); con l’introduzione di tecnologie come per esempio i sistemi RAID per la condivisione e la duplicazione delle informazioni, questo tipo di problematiche sono oggi sempre meno comuni, ma la loro possibile occorrenza non è da escludersi a priori.

Le categorie elencate dimostrano che un buon recovery plan non debba essere mirato elusivamente al ripristino di una situazione precedente, ma anche alla messa in sicurezza dei dati in modo che l’evento alla base di un malfunzionamento, di un danneggiamento o di una violazione non possa ripetersi in futuro.