Fare il backup del proprio hard drive è un po’ come andare dal dentista: importante ma sgradevole, tanto da rimandarlo o dimenticarsene. Proprio per questo, il miglior modo per tenere al sicuro i propri dati è di programmare dei backup in modo regolare. Esistono in commercio diverse soluzioni, tra cui il software Apple .mac Backup, che però necessita la sottoscrizione del relativo servizio a pagamento e che l’utente si sia autenticato.
La tradizionale alternativa UNIX consiste nell’eseguire programmi di backup a linea di comand in uno script di cron, ma molti amministratori ignorano la varietà di opzioni disponibili per backup non controllati sotto Mac OS X.
Questo articolo tratta di alcuni aspetti inerenti la gestione dei backup e delle particolari considerazioni per i sistemi Mac OS X, la varietà delle opzioni che permettono la creazione delle copie e i trabocchetti nei quali si può cadere quando si sviluppa un sistema di backup. L’articolo non copre i flags BSD e i sistemi precedenti a Mac OS v10.4 (Tiger). Inoltre, per semplicità, si presumerà che nei filesystem per i quali si intende effettuare le copie, non siano attivi gli ACL (se si usa Mac OS X Server o fsaclctl). Ci sono alcune questioni su come questi programmi di backup interagiscono con gli ACL che esulano l’obiettivo di questo articolo e pertanto non verranno trattate. E’ possibile comunque consultare la documentazione di ogni programma in maniera più approfondita.
Un po’ di storia, dump e tar
Lo scopo principale di un backup è quello di riprodurre, nella maniera più accurata possibile, lo stato di un filesystem. Nella maggior parte dei casi la duplicazione del contenuto di un file non è sufficiente; la gerarchia del filesystem, i permessi, le date e le altre informazioni devono anch’esse essere preservate. I due principali programmi di backup UNIX, dump e tar, hanno approcci differenti sotto questo aspetto.Il programma dump legge la struttura sottostante il filesystem e ne produce una copia esatta. Fin dagli inizi di UNIX, dump esegue una scansione della tabella degli inode, crea una lista completa di tutti i file del disco e della struttura dei filesystem, analizza le directory e quindi il contenuto dei file. Questo approccio è dovuto alla particolare struttura di un filesystem UNIX, che è differente da un filesystem HFS+. Al contrario, tar usa le API del filesystem per creare l’immagine di una directory e dei file in esso contenuti. Questo approccio risulta più semplice e più portabile ma il formato del file tar non gestisce direttamente le peculiarità di Mac OS X come ad esempio le resource forks e i metadati del filesystem.
In tutti i casi, backup affidabili generalmente richiedono un filesystem inerte, ovvero un filesystem che non venga modificato durante il processo di copia. Per esempio, un file che viene spostato da una directory ad un’altra durante la creazione del backup, potrebbe risultare in entrambe all’interno del backup, o (peggio) in nessuna. Potrebbero verificarsi anche altri tipi errori, alcuni meno evidenti. Un file molto grande che viene riscritto durante il processo di copia, potrebbe venire troncato prima della fine o contenere dati non coerenti dove alcune parti provengono dalla versione originale e altre dalla versione modificata del file, con conseguente perdita di dati.
Sfortunatamente, i moderni sistemi sono spesso attivi 24 ore su 24, 7 giorni su 7, rendendo così impossibile la programmazione dei backup. Tuttavia, in una situazione del genere, una precisa strategia di backup diventa particolarmente importante, vista la più alta probabilità che un data copia di backup si corrompa in qualche modo. Inoltre potrebbe essere utile se si considerano strategie di backup che non operino a livello di filesystem; ad esempio, l’esportazione delle tabelle da un database è un operazione assicurata che produce un’immagine valida di quel databas, che può essere così tranquillamente copiato.
Considerazioni in merito a HFS/HFS+
Il filesystem HFS+ usato in Mac OS X ha una serie di funzionalità e caratteristiche molto diverse da quelle di un tradizionale filesystem UNIX. Più semplicemente, un programma di backup che si basa sulle API del filesystem, per questioni di portabilità, non è in grado di creare copie valide di un filesystem HFS+.
Innanzitutto ogni cosa ha una sua resource fork. Le resource fork vengono ignorate dalle API UNIX tradizionali, in quanto gestiscono solo la data fork di un file. Ci sono poi altre questioni che possono mettere in dubbio una strategia di backup. Gli attributi di un file (i flags del Finder, le date, il tipo di file e i riferimenti a chi lo ha creato) sono informazioni addizionali che un sistema di backup standard per UNIX non solo non ha modo di leggere, ma anche di registrare. Congiuntamente, questi dati sono riferiti da ora in poi come “attributi estesi”.
Il filesystem HFS+ non usa gli inode allo stesso modo dei filesystem UNIX (infatti gli hard link vengono emulati grazie ad un elaborato sistema che riproduce gli stessi effetti di un tradizionale hard link UNIX). Di conseguenza uan strategia di backup basata sulla scansione degli inode è praticamente impossibile.
Gli alberi binari del filesystem da sole potrebbero offrire una soluzione ma in pratica è meglio ignorare questa implementazione e concentrarsi sulle API; questo approccio offre risultati più consistenti ed è portabile.
A causa delle differenze tra i filesystem HFS + e gli UNIX tradizionali (come ad esempio UFS, il filesystem di Berkeley disponibile in Mac OS X) è necessario l’utilizzo di soluzioni particolari per la creazione e il ripristino delle copie di backup nei sistemi Mac OS X.
Inoltre i sistemi non-Mac non possono essere usati per la copia di file provenienti da un sistema Mac. Se si scompattano i file di un archivio su un’altra macchina e poi li si ricompatta, i datiche non possono essere rappresentati su quella macchina verrebbero irrimediabilmente persi.
Cosa funziona in Mac OS X v10.4 Tiger
Esistono alcune soluzioni commerciali per Mac OS X. Dettagli in merito allo loro compatibilità e funzionalità esulano da questo articolo, ma i relativi rivenditori saranno quasi con ogni probabilità felici di rispondere a tali domande. Assicuratevi di chiedere tutte le informazioni che vi servono secondo le vostre specifiche esisgenze. Non tutti i programmi compatibili con Mac OS X supportano pienamente tutte le sue funzionalità.
Ci sono alcune utilità già incluse in Mac OS X che possono essere utili allo scopo almeno in parte. Il più conosciuto è senz’altro ditto, un’utility specifica per Mac OS X che sin dalla nascita è stata in grado di gestire le resource fork dei file (nelle versioni precedenti la 1.4, il flag -rsrc deve essere passato per permettere a ditto di copiare le resource fork). Ditto può essere usato quasi in ogni tipo di situazione dal momento che può copiare interi file, archiviarli e ripristinarli. L’archivio crreato da ditto può essere sia nel formato PkZip che cpio. Siccome ditto può essere eseguito dalla linea di comando, è molto semplice programmare i backup e gestire eventuali problemi senza la necessità di una supervisione costante.
Un’altra opzione è tar che, a partire da Mac OS X 10.4, riconoscee gestisce le resource fork e gli attributi. Per contro non è in grado di gestire path molto lunghi e potrebbe non salvare i nomi dei file in maniera corretta (tale anomalia viene seganalata con un messaggio di errore). Tar può comunque archiviare e ripristinare le resource fork e gli attributi dei file. Nelle versioni più obsolete di Mac OS X tar non gestiva niente che non fosse solo il data fork e i permessi del file.
L’utilità pax è un’alternativa più flessibile rispetto a tar supportando le intestazioni di formati multipli. Preserva inoltre gli attributi estesi. Grazie a queste funzionalità pax è in grado di gestire path più lunghe.
L’utilità rsync offre performance migliori quando si eseguono copie di file particolarmente grossi. Per copiare gli attributi estesi occorre specificare il flag -E. rsync può essere usato in rete per centralizzare i backup.
In termini di affidabilità e velocità l’Apple Software Restore (ASR) è difficile da battere. Questo programma viene usato per la creazione di CD di ripristino in volumi HFS+. Per usare ASR, occorre creare un’immagine del disco usando Disk Utility (usare il comando Crea immagine da directory, no Crea immagine da dispositivo). Un backup creato in questo modo può essere ripristinato in altri dischi come nello stesso. ASR può ripristinare i dati sostiuendoli oppure ridormattando il disco e poi copiarli in esso. In ogni caso, il largo impiego è dovuto essenzialmente per la velocità but of course it does remove any existing files.
Le immagini disco usate da ASR sono immagini disco standard Mac e possono essere montate nel desktop per copiare file specifici.
Vi è anche un’utlità a riga di comando denominata asr che può essere usata allo stesso modo. Inoltre è possibile specificare un volume esistente come sorgente piuttosto che un un’immagine compressa. Se asr viene richiamato senza il flag -erase, il programma semplicemente estrae i dati nella posizione corrente. Da tenere presente che asr non è in grado di operare in sorgenti o destinazioni che non siano volumi, ovvero non è possibile copiare i file in una subdirectory.
Per effettuare il restore di macchine di cui si conosce perfettamente la configurazione. è possibile usare asr in modelità serve, in cui fornirà una stream da una immagine sorgente. I sistemi client non possono usare questo sistema per un ripristino in locale senza prima aver riformattato il volume di destinazione.Questo è un ottimo modo per effettuare il backup della configurazione del sistema, ma sarà necessario usare qualcos’altro per i file personali.
Avvertimenti
Ci sono alcune cose da tenere bene a mente quando si sviluppa una strategia di backup. Una delle cose più importanti è quella di testare il proprio sistema di backup in più circostanze differenti. Una delle cose più ovvie da testare è se è effettivamente possibile ripristinare i file. Un programmatore che ha sviluppato un’utilità per l’archiviazione a scopo ricreativo ha osservato che la gente rimane si è sempre impressionata per la qualità dei suoi backup senza chiedersi mai se era possibile effettuarne poi il ripristino. Prima di iniziare a fidarsi del proprio ssitema, è necessario effettuare il ripristino dei dati per testarlo! Ripristinare una gran varietà di file per testare tutte le possibilità: file con resource fork, file con l’ACL (se lo si utilizza), ecc.
I backup su sistemi attivi possono perdere dati significativi. Qualunque strategiadi backup che si adotta per questo tipo di sistemi devono tenere presente questo; se non si prevede questo rischio.
