Copie dei dati e loro verifica

E’ fondamentale eseguire le copie dei dati. Al ns Ufficio Assistenza pervengono almeno tre quattro casi disperati all’anno che ci chiedono aiuto per recuperare i Documenti Gestionali e Contabili. Il ns intervento di solito è da remoto, telematico con l’accesso su consenso esplicito da parte dell’Utente al proprio Server dei dati.

Non ci crederete ma quando poniamo delle domande le risposte sono:

Domanda: a quando risalgono le copie? Risposta: non lo so esattamente
Domanda: in quale PC o Server sono archiviate? Risposta: non lo so, lo sa il mio installatore hardware
Domanda: ha mai controllato il contenuto delle copie ovvero ha mai provato a rileggerle? Risposta: rileggerle? Mai!

Nei casi più disperati le copie non sono recenti con perdita quindi dei Documenti Gestionali e Contabili dalla data della richiesta di aiuto a quella di ultima copia.

Un buon procedimento di Copia dei dati consiste di alcuni punti fondamentali:

a. frequenza delle copie: se eseguiamo la copia ogni settimana dobbiamo aspettarci di poter non recuperare al massimo i documenti di una settimana (disaster recovery time); se di un giorno un giorno e così via;

b. quanti dispositivi di copia fisica diversa utilizziamo? La norma prevede che la copia fisica stia al minimo su 2 dispositivi diversi (DVD, Blue-ray, NAS (unità a dischi RAID autonoma), nastro magnetico, penna digitale) e posti in edifici diversi; abbiamo visto sistemisti collocare il NAS (secondo dispositivo di copia) sopra il Server: in caso di scarica elettrica sul quadro che alimenta il Server l’extra tensione può facilmente danneggiare entrambi i dispositivi! Edifici diversi significa che il sistema di copia é a prova di incendio o allagamento se sono ben lontani!

Consigli per la tenuta di un sicuro sistema di Copia

A – copia dei dati
1. attivare il back-up automatico giornaliero nelle ore notturne quando gli operatori non lavorano
2. copiare il back-up automatico giornaliero automaticamente sul secondo dispositivo
3. se si ha il servizio presso una Server farm esterna di noleggio di spazio su disco, copiare automaticamente il back-up automatico giornaliero su di esso
4. fate si che il file dove viene memorizzato il colloquio della copia che ogni comando di copia produce Vi sia inviato dal Vs Server via email. Aprite l’allegato e verificate che i files che contengono i dati (per esempio con SWING/ARC2000 SiVE.mdf, SiCN.mdf, ecc) abbiano un numero di bytes superiore al rispettivo file del giorno prima*.

B – verifica della copia di back-up automatico giornaliero
5. con una frequenza che dipende dal disaster recovery time che si è disposti ad accettare, ma comunque almeno un paio di volte all’anno fate richiesta al Fornitore del Vostro Gestionale di rileggere in una area di prova uno degli ultimi backup giornalieri e di riprodurre alcune delle statistiche tipiche di utilizzo (Venduto, Acquistato, Valorizzazione del Magazzino, Bilancio di Verifica) confrontandole con le analoghe fatte precedentemente. Se sono uguali siate certi che le vostre copie sono esatte!

C – copie storiche
6. E’ molto diffuso il metodo di accantonare una delle copie di back-up giornaliero su due nuovi supporti ad esempio con cadenza mensile il primo e trimestrale il secondo. Poi una di queste verrà conservata per sempre ad esempio dopo le scritture di chiusura del Bilancio in Contabilità.

Forse con queste note non abbiamo illustrato completamente la metodologia di un buon sistema di copia ma siamo a disposizione per qualsiasi domanda.

Note
* conosciamo un paio di casi (in quasi quarant’anni di attività) dove questo non avveniva perché il controller dei dischi RAID corrodeva i files dati di backup senza esplicito avviso; in questo modo tutti i files giornalieri di backup erano corrotti senza avviso.
Quando il controller ha “tirato le cuoia” anzi, “funzionava e non funzionava” i cinque files di backup giornalieri erano parzialmente distrutti da diverso tempo ed illeggibili. In questo caso siamo ripartiti da una copia di servizio per lavori di personalizzazione di due mesi prima. Si in questo caso il disaster recovery time è stato di ben due mesi!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.