Appunti

 

Dalle mie parti si dice che “il calzolaio gira con le suole bucate” ed effettivamente mi chiedo quante siano le società del mercato italiano dell’IT che dispongano di un piano di Disaster Recovery: comunque questo è il mio. La mia è una micro-organizzazione paragonabile come operatività ad un qualsiasi studio professionale. La stesura di un piano di DR ha seguito le norme Cobit 4.1 debitamente adattate alla dimensione dell’organizzazione.  Ad ogni cambiamento del flusso di lavoro o degli strumenti a supporto dei processi il piano viene adattato di conseguenza;  nel piano sta anche scritto che dovrebbe essere controllato un paio di volte l’anno anche se fino ad ora è stato fatto raramente.

Analisi del sistema informativo

L’immagine rappresenta la situazione del sistema informativo prima del piano di DR. In linea di massima, architetturalmente, è composto da almeno quattro siti: la rete locale dello studio, l’hosting della posta elettronica, lo studio dei commercialisti e un sito in hosting di parte delle applicazioni di produzione. In locale sono stati installati due server: un file server (srv1) ed un sistema di laboratorio virtualizzato (srv2). Sul file server sono archiviati i dati non strutturati (documenti raggruppati in cartelle catalogate per categoria ed anno) e la banca dati dell’applicazione (MS Office SMB Accounting, purtroppo!!) per la gestione del business (contratti, anagrafiche, budget, scadenziari attivi e passivi, estrazione timesheets e consuntivazione, fatturazione, reporting). La contabilità effettiva oltre alle varie dichiarazioni ed i libri contabili sono tenuti presso lo studio del commercialista.

Non c’è un  server di posta interno, solo mailbox in hosting. I messaggi fluiscono direttamente dalle mailboxes POP3 esterne agli account in Outlook.  Su Outlook è stata abilitata l’archiviazione automatica settimanale per cui ogni account dispone di un file PST primario e di uno di archivio; il file primario rimane di piccole dimensioni mentre l’archivio cresce fino a raggiungere il gigabyte per alcuni account.

Per facilitare la ricerca e la collaborazione, il repository dei documenti verrà migrato a breve verso Sharepoint 2010 già presente su srv1. Se fosse disponibile una capacità di banda superiore si potrebbe acquisire un servizio in hosting.

La banca dati Sql Server di SMB Accounting non viene mai chiusa. I salvataggio dell’immagine del disco è “crash proof” grazie all’integrazione con Windows VSS che ne garantisce l’integrità transazionale; un eventuale restore dell’immagine richiederebbe una fase di recovery (automatica) della banca dati.

Il sito in hosting (emon) per la gestione della produzione fa uso di tre applicazioni Open Source di cui due personalizzate: Redmine, Subversion e Nagios+Centreon. Tutte le applicazioni fanno uso di banche dati MySql 5.1 tranne SVN che si appoggia su files tradizionali. Il servizio di hosting non dispone di Disaster Recovery. Le immagini di backup sono prese a caldo; un eventuale ripristino delle immagini di sistema, da punto di vista delle banche dati, è “crash proof” per i motori Innodb mentre il motore MyIsam richiede una fase di controllo e ripristino  aggiuntiva via MyIsamCheck.

Nota sui servizi professionali esterni

Gli studi professionali non dispongono quasi mai di un sistema di disaster recovery;  nel piano è necessario tenere presente questo problema. Nel nostro caso il problema coinvolge alcuni documenti ricevuti in formato cartaceo (normalmente fatture passive, scontrini) . Ognuno di questi documenti viene digitalizzato (scanner) prima dell’invio allo studio professionale. In caso di disastro presso lo studio professionale dovranno essere ricostruiti i libri contabili prelevando le informazioni dal repository documentale e dalla banca dati di SMB Accounting; le informazioni raccolte andranno poi ad integrarsi con l’ultima copia dei libri depositati presso la sede sociale.

Backup

Il piano di backup prevede il salvataggio delle immagini dei server srv1 (mensile) e srv2 (dopo ogni attività critica) su dischi esterni (NAS) mediante Windows Server Backup; vengono mantenute tre immagini mensili usate a rotazione. Il repository documentale e la banca dati di SMB Accounting vengono salvati giornalmente su disco esterno sempre mediante Windows Server Backup. Il sito esterno di produzione viene salvato giornalmente. Il servizio è incluso nel canone di hosting; anche qui vengono mantenute tre copie a rotazione delle immagini dei dischi. Le immagini delle stazioni di lavoro vengono salvate mensilmente mediante Windows Backup su disco esterno. I backup dei server e delle immagini delle stazioni di lavoro avvengono a caldo; sono completamente automatizzati e controllati mediante il servizio di monitoraggio interno che segnala via email eventuali problemi riscontrati durante il processo. Di ogni stazione di lavoro vengono salvate giornalmente (o quando si ricollega il portatile alla rete locale) su server mediante RSYNC la raccolta “documenti”, la cartella “Desktop”, la mailbox Outlook (file PST primari;  gli archivi PST sono già allocati su server). RSYNC viene lanciato manualmente mediante una icona presente sul desktop; i giorni senza backup vengono segnalati sulla dashboard del sistema di monitoraggio. Ogni portatile dispone di un disco esterno da 2.5” per i salvataggi non pianificati. La leggibilità dei supporti di backup viene verificata ogni mese  (in realtà “quando capita” ma mediamente ogni trimestre) mediante ispezione manuale; rimane aperto il problema del test di ripristino.

Inventario delle risorse critiche

Il piano include un inventario dei sistemi, delle applicazioni e delle informazioni. Questo è un estratto.

Leggenda:    

Piano di ripristino

Il sistema informativo non è soggetto a vincoli normativi o contrattuali che impongano livelli di servizio minimi al di là di quelli imposti dal D.lgs. 196/2003 (Disaster Recovery Plan e D.LGS 196/2003); ne consegue che RTO e RPO sono lasciati al buon senso. L’idea di base è quindi quella di usare il sito in hosting per il disaster recovery dello studio e quindi appoggiare il DR del sito in hosting su qualche servizio “in the cloud”; visto che c’è un account aperto su Amazon Web Services si usa questo.

Il primo problema da affrontare, come sempre, è la scarsa disponibilità di banda in upload.

• L’upload dei documenti (3.5 GB tot) richiederebbe circa 17 ore per il primo trasferimento; visto che è una operazione non presidiata (unattended) può essere fatta tranquillamente in un weekend. Per quantità di dati superiori sarebbe stato necessario accordarsi con il servizio di hosting per l’invio mediante un supporto esterno (un disco usb come nel caso di AWS Inport/Export). Le sincronizzazioni giornaliere trasferiscono poco più di qualche decina di MB.
• I database occupano poco più di 8GB ma la compressione riduce l’occupazione a poco più di 350MB.
• Il primo trasferimento degli archivi Outlook richiede circa 22 ore. Fattibile in un weekend.  L’archivio più grande è pari a 1GB e richiede un trasferimento da circa 5,5 ore. Bisogna tenere presente che ogni settimana viene trasferito l’intero archivio dell’anno corrente e questo trasferimento, verso fine anno, potrebbe richiedere lo stesso tempo.
• Poiché RSYNC implementa funzioni elementari di deduplicazione (invio dei soli blocchi modificati) ed opera su un tunnel SSH compresso si ottiene un notevole miglioramento dei tempi di trasferimento. Il normale throughput di upload  di una ADSL a 7Mb/sec (upload 480 Kb/sec) vale mediamente 50kB/sec; la sessione compressa “rsync --compress/ssh -C ” opera mediamente a circa 60/70kB/sec. L'invio dei soli blocchi modificati di un file PST da 1GB riduce i tempi di aggiornamento dalle  5 ore preventivate a qualche minuto. 

Per l’esecuzione dei salvataggi si procede come segue:

1)      Backup dei dati critici delle stazioni di lavoro via sincronizzazione di cartelle con il server (RSYNC già in opera).

2)      Backup giornaliero dei dati critici del server mediante sincronizzazione con il sistema in hosting di (RSYNC):

1. Cartella dati critici delle stazioni di lavoro.
2. Cartella dei backup pianificati di Sql Server (SMB Accounting).
3. Cartella del repository documentale.
4. Cartella delle configurazioni.

3)      Backup dei dati critici (database, cartelle delle applicazioni e delle configurazioni) del sito in hosting eseguito a conclusione della fase 2). Per i database viene eseguito una esportazione via mysqldump, l’ouput viene raccolto e compresso mediante il comando ‘tar’. Con lo stesso comando vengono salvate le cartelle delle applicazioni e delle configurazioni. I files di output del comando ‘tar’ vengono inviati al bucket ‘newitsdr’ su AWS S3 mediante l’utility ‘s3cmd put’. A fine aggiornamento le vecchie copie vengono eliminate; passo da eliminare qualora fosse necessaria una archiviazione storica.

Il tempo di trasferimento per una singola sessione di upload su linea a 10Mbits/sec è molto interessante come dimostra la seguente immagine.

Sicurezza

Nel nostro lavoro non trattiamo dati sensibili; tuttavia possiamo venire in possesso di alcune informazioni critiche per i nostri clienti che in ogni caso tendiamo a proteggere. Per questa ragione la cartella “Documentazione clienti” non è inclusa direttamente nel normale ciclo di sincronizzazione via RSYNC ma viene prima inviata ad una normale cartella compressa (.zip) , viene cifrata via GPG ed inserita nella cartella “Documentazione commerciale”; tutto questo prima che parta il normale processo di sincronizzazione.  Le chiavi GPG sono protette da un processo ad-hoc.

Costi

Ogni mese ci vengono addebitati circa 1,5€ per 1GB di spazio occupato e circa 16GB/mese di trasferimenti. Il numero di operazioni non è significativo.

Conclusioni

Il piano così implementato è classificabile secondo i seguenti parametri:

RPO:  Classe B: max 8 ore lavorative.

RTO:  Classe B: da 4 a 24 ore solari.

BS7799-2 MTPD (Maximum Tolerable Period of Disruption): NA.

Senza grandi costi ricorrenti (OPEX) o in conto capitale (CAPEX) è possibile implementare un piano di Disaster Recovery anche per le micro organizzazioni. Nel mio caso la consulenza è gratuita tuttavia i costi per l'implementazione sono più che abbordabili per qualsiasi micro o piccola organizzazione.