%--------------------------------------------------------------------
\chapter{I backup} \label{chap:backups}
%--------------------------------------------------------------------

	\begin{chapterquote}
	L'hardware è indeterministicamente affidabile.  \\
	Il software è deterministicamente inaffidabile. \\
	Le persone sono deterministicamente inaffidabili. \\
	La natura è deterministicamente affidabile. \\	
	\end{chapterquote}

	\noindent
	Questo capitolo spiega perché, come e quando fare i backup, e come recuperare dati dai backup.

\section{Sull'importanza delle copie di backup}

	I vostri dati sono preziosi. Vi costerebbe tempo e sforzo ricrearli, e questo costa denaro o almeno nervosismo e lacrime; talvolta non si può neanche farlo, come ad esempio nel caso dei risultati di qualche esperimento. Dato che si tratta di un investimento, dovreste proteggerli e prendere provvedimenti per evitare di perderli.

	Ci sono principalmente quattro ragiorni per cui si possano perdere dei dati: guasti all'hardware, bachi del software, azione umana o disastri naturali.\footnote{La quinta ragione è ``qualcos'altro''.} Anche se l'hardware moderno sembra essere abbastanza affidabile, si può comunque rompere senza una ragione apparente. Le parti hardware più critiche per i dati sono gli hard disk, che si affidano al fatto che deboli campi magnetici rimangano intatti in un mondo pieno di rumore elettromagnetico. Il software moderno non tende nemmeno ad essere affidabile; un programma solido come una roccia è un'eccezione, non la regola. 
Gli essere umani sono piuttosto inaffidabili: possono fare uno sbaglio, o possono essere malvagi e distruggere dei dati volontariamente. La natura può non essere cattiva, ma può distruggere anche quando è buona. Tutto sommato, è un piccolo miracolo che qualcosa funzioni.

	I backup sono un modo per proteggere l'investimento in dati. Avendo diverse copie dei dati, non importa molto se una viene distrutta (il costo è solo quello di recuperare i dati dal backup).

	\`E importante fare bene i backup. Come tutte le cose correlate al mondo fisico, i backup possono andare male prima o poi. Parte del compito di fare bckup è assicurarsi che funzionino: non è bello notare che il proprio backup non funziona nel momento del bisogno.\footnote{Non ridete. \`E successo a diverse persone.} Aggiungendo la beffa al danno, il vostro computer può crashare mentre state facendo backup: se avete un solo mezzo di backup, potrebbe distruggersi anche quello, lasciandovi solo con le ceneri fumanti del vostro duro lavoro.\footnote{Mi è successo\dots} Oppure potete notare, nel momento in cui state recuperando i dati, che vi siete scordati di includere nel backup alcuni dati importanti, come il database degli utenti su un sito con 15.000~utenti. Meglio di tutti, tutti i vostri backup potrebbero essere perfettamente funzionanti, ma l'ultimo lettore di nastri che poteva leggere quel tipo che usavate era quello che ora ha dentro un secchio d'acqua.

	Quando si tratta di backup, il lavoro si può chiamare ``paranoia''.

\section{La scelta del mezzo di backup}

	La decisione più importante sui backup è la scelta del mezzo. Dovete considerare il costo, l'affidabilità, la velocità, la disponibilità e l'utilizzabilità. 

	Il costo è importante, dato che dovreste preferibilmente avere molto più materiale di quello che vi serve per i dati. Un mezzo economico è di solito indispensabile.

	L'affidabilità è estremamente importante, dato che un backup venuto male può fare piangere un uomo grande e grosso. Un mezzo di backup deve essere in grado di mantenere i dati invariati per anni.
	Il modo in cui si usa un mezzo di backup influisce sulla sua affidabilità. Un hard disk è di solito molto affidabile, ma come mezzo di backup non lo è, se si trova nello stesso computer del disco di cui state facendo backup.

	La velocità spesso non è molto importante, se si possono fare backup senza interazione. Non importa se ci vogliono due ore, se non c'è bisogno di alcuna supervisione. D'altra parte, se il backup non può essere fatto quando il computer non sarebbe comunque usato, allora anche la velocità è importante.

La disponibilità sul mercato è di certo necessaria, dato che non si può usare un mezzo di backup se non esiste. Meno ovvia è la necessità che il mezzo sia disponibile anche in futuro, e su computer diversi dal vostro, altrimenti potreste non essere in grado di recuperare i dati dal backup dopo un disastro.

	L'utilizzabilità è un fattore importante nella frequenza con cui vengono fatti i backup. Più facile è, meglio è. Un mezzo di backup non deve essere difficile o noioso da usare.

	Le tipiche alternative sono i floppy e i nastri. I floppy sono molto economici, piuttosto affidabili, non molto veloci, si trovano facilmente, ma non possono essere usati per grandi quantità di dati. I nastri vanno da quelli economici a quelli piuttosto costosi, sono abbastanza affidabili, veloci, disponibili sul mercato e---a seconda della grandezza del nastro---permettono di immagazzinare parecchi dati.

	Ci sono altre alternative: non sono di solito molto comuni sul mercato, ma se questo non è un problema possono essere migliori sotto altri aspetti. Ad esempio, i dischi magneto-ottici hanno dei vantaggi sia sui floppy (hanno alte capacità) che sui nastri (sono ad accesso casuale, rendendo così molto veloce il recupero di un singolo file).

\section{La scelta dello strumento di backup}

	Esistono molti strumenti che possono essere usati per fare i backup. Quelli usati tradizionalmente sotto UNIX sono \cmd{tar}, \cmd{cpio}, e \cmd{dump}; oltre a questi ne esistono un gran numero (sia freeware che commerciali). La scelta del mezzo di backup può influenzare quella dello strumento da usare.

	\cmd{tar} e \cmd{cpio} sono simili, e per lo più equivalenti dal punto di vista dei backup: entrambi possono immagazzinare dei file su nastro, e recuperarne file, entrambi riescono ad utilizzare quasi qualsiasi mezzo, dato che i device driver del kernel si occupano della gestione a basso livello dei dispositivi, ed i dispositivi stessi tendono a sembrare tutti uguali ai programmi a livello utente. Alcune versioni UNIX di \cmd{tar} e \cmd{cpio} possono avere problemi con file particolari (link simbolici, file di dispositivo, file con percorso molto lungo e così via), ma la versione Linux dovrebbe funzionare in tutti i casi.

	\cmd{dump} è diverso nel fatto che legge direttamente il filesystem, e non attraverso il filesystem. \`E anche scritto specificamente per i backup: \cmd{tar} e \cmd{cpio} in realtà sono fatti per archiviare file, anche se funzionano lo stesso per i backup.

	Leggere il filesystem direttamente ha alcuni vantaggi: rende possibile fare copie di backup dei file senza modificare i timestamp; per \cmd{tar} e \cmd{cpio} bisognerebbe montare prima il filesystem in modalità a sola lettura. Leggere direttamente il filesystem è anche più efficace se bisogna fare un backup completo, dato che lo si può fare senza spostare di molto la testina del disco. Lo svantaggio principale è che rende il programma di backup specifico per un tipo di filesystem: il programma \cmd{dump} per Linux riconosce solo il filesystem ext2.

	\cmd{dump} supporta anche direttamente i livelli di backup (di cui parleremo più sotto): con \cmd{tar} e \cmd{cpio} bisogna implementarli con altri strumenti.

	Un paragone tra gli altri strumenti di backup va oltre lo scopo di questo libro. La Linux Software Map elenca molti di quelli freeware. 


\section{Backup semplici}

	Uno schema di backup semplice è  di fare una copia di tutto una volta, e poi di copiare solo quei file che sono stati modificati dal precedente backup. Il primo viene chiamato \defin{backup completo}, i successivi sono \defin{backup incrementali}. Un backup completo è spesso più laborioso di quelli incrementali, dato che bisogna scrivere più dati sul nastro, e un solo nastro (o floppy) potrebbe non bastare. Recuperare dati da backup incrementali può essere molte volte più faticoso che da un backup completo. Il recupero può essere ottimizzzato facendo backup di tutto quello che è stato modificato dall'ultimo backup completo; in questo modo fare backup è un po' più laborioso, ma non ci dovrebbe mai essere bisogno di recuperare più che un backup completo e uno incrementale.

	Se volete fare backup ogni giorno ed avete sei nastri, potete usare il nastro~1 per il primo backup completo (diciamo di venerdì), e i nastri da~2 a ~5 per i backup incrementali (da lunedì a giovedì). Poi fate un nuovo backup completo sul nastro~6 (il secondo venerdì) e ricominciate a fare backup incrementali con i nastri~2--5. Non dovete riscrivere il nastro~1 finché non avete un altro backup completo, nel caso vi succedesse qualcosa mentre state facendo il secondo backup completo. Dopo che avrete usato il nastro~6 per il secondo backup completo, dovreste tenere il nastro~1 in qualche altro posto, in modo che se tutti gli altri nastri venissero distrutti da un incendio avreste ancora almeno un backup da usare. Quando dovrete fare il prossimo backup completo, prenderete il nastro~1 e lascerete il nastro~6 al suo posto.

	Se avete più di sei nastri, potete usare quelli che avanzano per i backup completi. Ogni volta che fate un backup completo, usate il nastro più vecchio. In questo modo avrete backup di diverse settimane passate, che va bene se volete trovare un file vecchio che avete cancellato, o una vecchia versione di un file.

\subsection{Fare backup con \cmd{tar}}

	Si può fare facilmente un backup completo con \cmd{tar}:
		%
		\begin{tscreen}
\# tar --create --file /dev/ftape /usr/src \\
tar: Removing leading / from absolute path names in the archive \\
\# 
		\end{tscreen}
		%
	L'esempio qui sopra usa la versione GNU di \cmd{tar} e le sue opzioni con nomi lunghi. La versione tradizionale di \cmd{tar} capisce soltanto le opzioni di un singolo carattere. La versione GNU può anche gestire backup che non entrano in un singolo nastro o floppy, ed anche percorsi molto lunghi: non tutte le versioni tradizionali lo fanno (Linux usa solo il \cmd{tar} GNU).

	Se il vostro backup non entra in un nastro, dovete usare l'opzione \texttt{--multi-volume} (\texttt{-M}):
		%
		\begin{tscreen}
\# tar -cMf /dev/fd0H1440 /usr/src \\
tar: Removing leading / from absolute path names in the archive \\
Prepare volume \#2 for /dev/fd0H1440 and hit return:  \\
\# 
		\end{tscreen}
		%
	Notate che dovreste formattare i floppy prima di iniziare il backup, oppure usare un'altra finestra o terminale virtuale e farlo quando \cmd{tar} chiede un nuovo floppy.

	Dopo fatto un backup, dovreste controllare che sia a posto, usando l'opzione \texttt{--compare} (\texttt{-d}):
		%
		\begin{tscreen}
\# tar --compare --verbose -f /dev/ftape \\
usr/src/ \\
usr/src/linux \\
usr/src/linux-1.2.10-includes/ \\
.... \\
\#
		\end{tscreen}
		%
	Se non controllate il backup noterete i vostri eventuali errori quando avrete perso i dati originali.

	Potete fare un backup incrementale con \cmd{tar} usando l'opzione \texttt{--newer} (\texttt{-N}):
		%
		\begin{tscreen}
\# tar --create --newer '8 Sep 1995' --file /dev/ftape /usr/src --verbose \\
tar: Removing leading / from absolute path names in the archive \\
usr/src/ \\
usr/src/linux-1.2.10-includes/ \\
usr/src/linux-1.2.10-includes/include/ \\
usr/src/linux-1.2.10-includes/include/linux/ \\
usr/src/linux-1.2.10-includes/include/linux/modules/ \\
usr/src/linux-1.2.10-includes/include/asm-generic/ \\
usr/src/linux-1.2.10-includes/include/asm-i386/ \\
usr/src/linux-1.2.10-includes/include/asm-mips/ \\
usr/src/linux-1.2.10-includes/include/asm-alpha/ \\
usr/src/linux-1.2.10-includes/include/asm-m68k/ \\
usr/src/linux-1.2.10-includes/include/asm-sparc/ \\
usr/src/patch-1.2.11.gz \\
\# 
		\end{tscreen}
		%
	Sfortunatamente, \cmd{tar} non nota quando sono state modificate le informazioni dell'inode di un file, ad esempio i suoi bit di permesso, o il suo nome. Questo può essere aggirato usando \cmd{find} e paragonando lo stato corrente del filesystem con una lista di file compresa nel precedente backup. Sui siti ftp su Linux potete trovare degli script che fanno proprio questo.
	
\subsection{Recuperare file con \cmd{tar}}

	L'opzione \texttt{--extract} (\texttt{-x}) di \cmd{tar} estrae dei file dall'archivio:
		%
		\begin{tscreen}
\# tar --extract --same-permissions --verbose --file /dev/fd0H1440 \\
usr/src/ \\
usr/src/linux \\
usr/src/linux-1.2.10-includes/ \\
usr/src/linux-1.2.10-includes/include/ \\
usr/src/linux-1.2.10-includes/include/linux/ \\
usr/src/linux-1.2.10-includes/include/linux/hdreg.h \\
usr/src/linux-1.2.10-includes/include/linux/kernel.h \\
... \\
\#  
		\end{tscreen}
		%
	Si possono anche estrarre file o directory specifiche (compresi tutti i file e le sottodirectory in esse contenuti) dandoli sulla linea di comando:
		%
		\begin{tscreen}
\# tar xpvf /dev/fd0H1440 usr/src/linux-1.2.10-includes/include/linux/hdreg.h \\
usr/src/linux-1.2.10-includes/include/linux/hdreg.h \\
\# 
		\end{tscreen}
		%
	Usate l'opzione \texttt{--list} (\texttt{-t}), se volete solo vedere quali file ci sono in un volume di backup:
		%
		\begin{tscreen}
\# tar --list --file /dev/fd0H1440  \\
usr/src/ \\
usr/src/linux \\
usr/src/linux-1.2.10-includes/ \\
usr/src/linux-1.2.10-includes/include/ \\
usr/src/linux-1.2.10-includes/include/linux/ \\
usr/src/linux-1.2.10-includes/include/linux/hdreg.h \\
usr/src/linux-1.2.10-includes/include/linux/kernel.h \\
... \\
\#  
		\end{tscreen}
		%
	Notate che \cmd{tar} legge sempre i volumi di backup sequenzialmente, quindi per volumi grandi è piuttosto lento. Non è possibile, comunque, usare delle tecniche di accesso casuale quando si usa un'unità a nastro o qualche altro mezzo ad accesso sequenziale.

	\cmd{tar} non gestisce in maniera corretta i file cancellati. Se dovete recuperare un filesystem da un backup completo e uno incrementale, ed avete cancellato dei file tra i due backup, questi esisteranno di nuovo dopo il recupero. Questo può essere un problema serio, se questi file hanno dati importanti che non dovrebbero essere più disponibili.	

\section{Backup multilivello}

	Il semplice metodo di backup descritto nella precedente sezione è spesso adeguato per l'uso personale o per siti piccoli; per un uso più pesante sono migliori i backup multilivello.

	Il metodo semplice ha due livelli di backup: completo ed incrementale. Questo schema può essere generalizzato a qualsiasi numero di livelli: il backup completo sarebbe di livello~0, i diversi livelli di backup incrementale sarebbero i livelli~1, 2, 3 \dots A ciascun livello incrementale si fa il backup di tutto quello che è cambiato dal precedente dello stesso livello o di un livello superiore.

	Lo scopo di questo è che permette in modo poco dispendioso una \defin{storia di backup} più lunga. Nell'esempio della sezione precedente la storia di backup andava fino al precedente backup completo; si poteva estendere con più nastri, ma solo alla frequenza di una settimana per ogni nastro, che poteva essere piuttosto dispendioso. Una storia di backup più lunga è utile, dato che i file cancellati o corrotti spesso non vengono notati per un lungo tempo. Anche una versione non molto aggiornata di un file spesso è meglio che niente.

	Con il multilivello la storia di backup può venire estesa in maniera più economica. Ad esempio, se compriamo dieci nastri, potremmo usare il numero~1 e il~2 per i backup mensili (il primo venerdì del mese), i nastri dal~3 al~6 per i backup settimanali (gli altri venerdì: notate che ci possono essere cinque venerdì in un mese, quindi abbiamo bisogno di altri quattro nastri), e i nastri dal~7 al~10 per i backup giornalieri (dal lunedì al giovedì). Con solo altri quattro nastri possiamo estendere la storia di backup da due settimane (dopo che tutti i nastri giornalieri sono stati usati) a due mesi. \`E vero che non potremo recuperare tutte le versioni di ciascun file durante questi due mesi, ma quello che possiamo recuperare è spesso più che sufficiente.

	La figura~\ref{fig:backup-history-timeline} mostra quali livelli di backup vengono usati in ciascun giorno, e da quali backup si possono recuperare i file alla fine del mese.

	\begin{figure}[t]
	\begin{center}
	\includegraphics{backups/backup-timeline.ps}
	\end{center}
	\caption{Un esempio di backup multilivello.}
	\label{fig:backup-history-timeline}
	\end{figure}

	I livelli di backup possono essere usati anche per mantenere il tempo di recupero dei filesystem al minimo. Se avete molti backup incrementali con i numeri di livello che crescono costantemente, dovrete usarli tutti se volete recuperare l'intero filesystem. Potete invece usare dei livelli non monotoni, e tenere basso il numero di backup da usare per il rcupero dei file.

	Per minimizzare il numero di nastri da cui recuperare potete usare un livello più basso per ciascun nastro incrementale. In questo caso, però, il tempo per fare backup cresce (ciascuna copia di backup contiene tutto quello che è stato modificato dal precedente backup completo). Uno schema migliore viene suggerito nella pagina man di \cmd{dump} ed è descritto in tabella~\ref{tab:efficient-backup-levels}.  Usate la seguente successione di livelli di backup: 3, 2, 5, 4, 7, 6, 9, 8, 9\dots  Questo mantiene bassi sia il tempo di backup che quello di recupero. Al massimo dovrete recuperare due giorni di lavoro. Il numero di nastri per recuperare tutto dipende da quanto tempo fate passare tra i backup completi, ma è meno che negli schemi semplici.

\begin{figure}[htb]
\caption{Un efficace schema di backup usando molti livelli}
\label{tab:efficient-backup-levels}
\begin{center}
\begin{tabular}{r l l l}
Tape 	&	Level 	&	Backup		&	Recupero \\
	&		&	(giorni)	&	nastri \\
\hline
1 &	0 &	n/a &	1 \\
2 &	3 &	1 &	1, 2 \\
3 &	2 &	2 &	1, 3 \\
4 &	5 &	1 &	1, 2, 4 \\
5 &	4 &	2 &	1, 2, 5 \\
6 &	7 &	1 &	1, 2, 5, 6 \\
7 &	6 &	2 &	1, 2, 5, 7 \\
8 &	9 &	1 &	1, 2, 5, 7, 8 \\
9 &	8 &	2 &	1, 2, 5, 7, 9 \\
10 &	9 &	1 &	1, 2, 5, 7, 9, 10 \\
11 &	9 &	1 &	1, 2, 5, 7, 9, 10, 11 \\
\dots &	9 &	1 &	1, 2, 5, 7, 9, 10, 11, \dots \\
\hline
\end{tabular}
\end{center}
\end{figure}
	
	Uno schema strano può ridurre il lavoro necessario, ma implica più cose da seguire. Dovete decidere se ne vale la pena.

	\cmd{dump} ha incluso il supporto per i livelli di backup. Per \cmd{tar} e \cmd{cpio} deve essere implementato con script di shell.
	
\section{Di che fare backup}

	Fate il backup di più cose possibili. L'eccezione principale è il software che si può facilmente reinstallare,\footnote{Dovete decidere cosa vuol dire ``facile''. Alcuni considerano facile reinstallare da dozzine di floppy.} che però può avere file di configurazione che è importante salvare, altrimenti dovrete riconfigurare tutto da capo. Un'altra eccezione importante è il filesystem \fn{/proc}; dato che contiene solo dati che i kernel genera automaticamente, non è \emph{mai} una buona idea farne il backup. Specialmente il file \fn{/proc/kcore} è del tutto inutile, dato che è solo un'immagine della memoria fisica; ed è anche piuttosto grande.

	A seconda dei casi potete fare o no il backup dello spool delle news, dei file di log, e di altre cose in \fn{var}. Dovete decidere che cosa considerate importante.

	La cosa ovvia di cui fare backup sono i file degli utenti (\fn{/home}) e dei file di configurazione di sistema (\fn{/etc}, ma probabilmente anche altre cose sparpagliate per il filesystem).

\section{Backup compressi}

	I backup prendono molto spazio, che può costare molti soldi; per ridurre lo spazio necessario si possono comprimere. Ci sono diversi modi di farlo: alcuni programmi hanno già un supporto interno per la compressione: ad esempio, l'opzione  \texttt{--gzip} (\texttt{-z}) per il \cmd{tar} GNU manda in pipe l'intero backup attraverso il comando di compressione \cmd{gzip}, prima di scriverlo sul mezzo di backup.

	Sfortunatamente, i backup compressi possono fare danni. Per come funziona la compressione, se un singolo bit è sbagliato vengono persi tutti i dati compressi. Alcuni programmi di backup hanno la correzione degli errori automatica, ma non esiste un metodo che può gestire un gran numero di errori. Ciò significa che se il backup è compresso come fa il \cmd{tar} GNU, con tutto l'output compresso in una singola unità, un solo errore fa perdere tutto il backup. I backup devono essere affdabili, e questo metodo di compressione non è una buona idea.	

	Un metodo alternativo è comprimere ciascun file separatamente. Questo significa sempre che quel file viene perso, ma tutti gli altri sono salvi. Il file perso sarebbe comunque corrotto, quindi questa situazione non è molto peggiore che non usare per niente la compressione. Il programma \cmd{afio} (una variante di \cmd{cpio}) supporta questo metodo.	

	La compressione può prendere del tempo, che può rallentare il programma di backup fino a renderlo troppo lento per scrivere su un nastro.\footnote{Se il drive dei nastri non riceve dati abbastanza velocemente, si deve fermare: questo rende il backup ancora più lento, e non fa bene al nastro né al drive.} Si può evitare facendo il buffer dell'output (sia internamente, se il programma di backup è abbastanza intelligente, sia usando un altro programma), ma anche questo può non funzionare abbastanza bene; dovrebbe però essere un problema solo su computer lenti.
