Gestione dei backup in piccole infrastrutture

La problematica dei backup nelle piccole infrastrutture è spesso gestita in maniera sommaria a causa del fatto che le politiche di salvataggio sono state messe in essere di solito in tempi diversi. Questo comporta sistemi eterogeni sia di salvataggio che di rispristino.

Ovviamente la soluzione ottimale, budget permettendo, è valutare un prodotto dedicato al backup come ad esempio Data Protection Manager della suite System Center.

Di seguito invece analizzerò quello che si può provare a fare per realizzare un sistema di backup più strutturato utilizzando hardware eventualmente già disponibile in casa. In particolare ipotizzerò di avere:

• un computer dedicato al backup che può essere un server anche datato con due schede di rete da 1GB per velocizzare le copie e spazio su disco sufficiente per mantenere in locale il backup
• Un paio di piccoli NAS con spazio sufficiente  per mantenere i backup
• Un Tape RDX per poter portare all’esterno i backup

L’idea che sta alla base di questo tipo di soluzione per infrastrutture è quella di recuperare eventuale hardware presente e di poter avere più “livelli” di backup su supporti diversi per avere una rapidità di rispristino e situazioni temporali diverse dei dati.

Scendendo nel dettaglio si potrebbe ipotizzare la seguente politica di backup:

1. Se i server e le workstation che detengono dati da mettere al sicuro hanno spazio sufficiente eseguono il backup dei dati e dello stato del sistema in locale, in caso contrario eseguiranno il backup su una share del server di backup.
2. Il server di backup in modo schedulato accede ai server e alle workstation per copiare in locale il backup
3. Il server di backup in modo schedulato riversa la propria copia locale di backup su NAS e RDX

Di seguito un esempio della distribuzione temporale delle fasi di backup:

In questo modo su ogni server si avrà sempre l’ultimo backup eseguito, in questo modo sarà possibile eseguire un rapido ripristino.

La copia server di backup garantirà il ripristino nel caso in cui il server non fosse più accessibile.

I NAS garantiranno l’accessibilità di una copia anche nel caso in cui anche server di backup non fosse disponibile, inoltre utilizzano due NAS sarà possibile mantenere le copie degli ultimi due giorni (se i NAS sono sufficientemente capienti è possibile mantenere su ciascuno più copie coprendo così più giorni).

Tramite gli RDX è possibile portare all’esterno i backup e in base al numero di RDX disponibili si mantenere più copie.

Nell’infrastruttura che ho rappresentato in figura si può notare che grazie alla doppia scheda di rete sul server di backup è possibile isolare fisicamente i backup da accessi tramite la LAN aziendale. Questo in certe situazioni può essere necessario per questioni di sicurezza, ovviamente è anche possibile una soluzione in cui il server di backup ha una scheda di rete sola.

In entrambe le soluzioni l’accortezza che occorre avere per allungare i tempi di backup è quella di avere server di backup e server di produzione sullo stesso switch e per la stessa ragione anche i NAS e il server di backup dovranno essere sullo stesso switch.

Altre accortezze per velocizzare le copie dei backup di avere sui NAS interfacce di rete a 1 GB, schede di rete 1 GB sui server di produzione e sul server di backup.

Per quanto riguarda il Tape RDX personalmente preferisco quelli esterni perché i questo modo è possibile montarli velocemente su u  altro computer se necessario, sempre nell’ottica di velocizzare le copie utilizzare Tape RDX USB 2 o meglio USB 3 se il computer supporta tale versione dell’USB.

Per quanto riguarda l’esecuzione delle copie dal server di backup è possibile utilizzare vari software gratuiti o a pagamento, personalmente non mi trovo male con SyncBack di cui esiste anche una versione freeware scaricabile al seguente link SyncBack Free – freeware version of the ultimate data backup software.

SynckBack permette di fare copie speculari con possibilità di avere dei log, i vari task di copia vengono configurati per essere eseguiti tramite operazioni pianificate.

Come detto esistono anche altre soluzioni gratuite come Cobian Backup che però per scelta non esegue l’eliminazione dei file non più presenti durante la sincronizzazione, oppure SyncToy che però offre meno opzioni di SynckBack per la gestione della sincronizzazione.

Terminato il backup il backup è importante verificarne l’esito se si decide di utilizzare SyncBack è possibile farsi inoltrare per mail il log di esecuzione però utilizzando il software ho notato che se il log è troppo grande l’invio mail fallisce quindi la soluzione che personalmente ho adottato è quella di impostare in formato testuale e non Html i log in quanto occupano meno spazio, inoltre tramite Log Parser mi sono creato uno script che estrapola solo gli errori presenti nel log riversandoli su di un file (SyncBackErrors.txt).

Di seguito il contenuto del file AnalyzeSynBackLogs.sql che esegue la query di estrazione dai file di logs:

SELECT EXTRACT_FILENAME(LogFilename) AS File, Text AS Error
INTO C:\Scripts\SyncBackErrors.txt
FROM ‘C:\Software\SyncBack Freeware V3.2.26.0\SyncBack_NI_IT\*_Log.txt’
WHERE Text LIKE ‘%Impossibile copiare il file%’

Volendo è poi possibile inviare il file SyncBackErrors.txt per mail utilizzano lo script sendmail.vbs che avevo pubblicato nel seguente Inviare un’email tramite script.

Una problematica che può verificarsi soprattutto se si esegue la copia di file da file server per averli rapidamente disponibile in caso di necessità di recupero e quella del fallimento della copia a causa del path troppo lungo.

Il limite della lunghezza del path è per default di 260 caratteri come indicato nel seguente Naming Files, Paths, and Namespaces:

In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is “D:\some 256-character path string<NUL>” where “<NUL>” represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.)

Sempre in Naming Files, Paths, and Namespaces viene comunque indicato che il limite dei 260 caratteri può essere superato grazie a Unicode.

Quello che può verificarsi è che gli utenti utilizzino i file tramite un percorso di rete mappato tramite una lettera di volume e creino poniamo il caso un file con un nome completo di circa 250 caratteri, quando il server di backup ci accederà lo farà però tramite il path UNC e quindi i caratteri relativi alla nome del server e della share causeranno lo sforamento dei 260 caratteri impendendo la copia del file.

X:\Path file da 250 caratteri (con X: mappato su \\server\share)

\\server\share\Path file da 250 caratteri –> il nome file risultante sarà di 250+15=260

Per verificare se esistono file con nomi così lunghi è possibile usare una utility come LONG PATH Tool per individuare e sistemare preventivamente questi file di cui in caso contrario non verrebbe eseguito il backp, in ogni caso i log di SyncBack riporteranno questo tipo di errori.