%--------------------------------------------------------------------
\chapter{Sauvegardes} \label{chap:backups}
%--------------------------------------------------------------------

	\begin{chapterquote}
	Le matériel est fiable de façon indéterminée.\\
	Le logiciel n'est pas fiable de façon déterminée.\\
	Les gens ne sont pas fiables de façon indéterminée.\\
	La nature est fiable de façon déterminée.\\
	\end{chapterquote}

	\noindent
Ce chapitre explique pourquoi, comment, et quand il faut faire des sauvegardes, et comment récupérer les données à partir
de ces sauvegardes.

\section{Sur l'importance des sauvegardes}

Les données ont de la valeur. Cela co\^ute du temps et du travail pour les recréer, et cela co\^ute de l'argent ou, en tous 
cas, du chagrin et des larmes. Quelques fois, elles peuvent m\^eme  \^etre recrées, par exemple si c'est le résultat de 
quelque expérimentation. Puisqu'elles représentent un investissement, on doit les protéger et faire en sorte d'éviter de
les perdre.

Il y a quatre raisons de base pour lesquelles on peut perdre ses données~: pannes matérielles, erreurs logicielles, actions
humaines, ou désastres naturels.\footnote{La cinquième raison est << autre chose >>.}
Bien que le matériel moderne tende à \^etre plut\^ot fiable, il peut quand m\^eme tomber en panne de façon apparemment 
spontanée. La partie du matériel la plus critique pour le stockage des données est le disque dur, qui suppose que les 
minuscules champs magnétiques resteront intacts dans un monde rempli de bruit électromagnétique. Les logiciels modernes
n'essaient m\^eme pas d'\^etre fiables ; un programme solide est une exception, pas une règle. Les humains ne sont
pas trop fiables, soit ils font une erreur, soit ils sont malicieux et détruisent les données en connaissance de cause. La
nature peut ne pas \^etre un démon, mais elle peut faire des ravages tout en restant bonne. De plus, c'est un petit 
miracle quand tout marche correctement.

Les sauvegardes sont un moyen de protéger les investissements en données. En ayant plusieurs copies de ces données, si l'une est détruite, cela ne pose pas de problème (le co\^ut est simplement celui de la récupération des données perdues à partir de la sauvegarde).

Il est important de faire les sauvegardes correctement. Comme tout ce qui est lié au monde physique, les sauvegardes se planteront t\^ot ou tard. Une part importante dans la confection de bonnes sauvegardes est de s'assurer qu'elles fonctionnent ; 
on ne souhaite pas réaliser que les sauvegardes ne fonctionnent pas.\footnote{Ne riez pas, cela arrive à beaucoup de gens.}
En ajoutant l'insulte à la douleur, on peut avoir un plantage au moment où l'on fait la sauvegarde ; si l'on n'a qu'un
seul support de sauvegarde, il peut donc \^etre détruit en ne laissant que les cendres fumantes d'un dur labeur. On
peut aussi s'apercevoir, lorsque l'on veut restaurer, que l'on a oublié de sauvegarder quelque chose d'important, comme
la base de données utilisateurs sur un site de 15000 utilisateurs. Le mieux est que toutes les sauvegardes peuvent fonctionner correctement mais que le seul lecteur capable de lire les bandes utilisées pour ces sauvegardes est maintenant  noyé dans un seau d'eau.

Quand on parle de sauvegardes, la parano\"\i a est le ma\^\i tre mot.

\section{Choix du support de sauvegarde}

La décision la plus importante concernant les sauvegardes est le choix du support. On peut prendre en compte le co\^ut,
la fiabilité, la rapidité, la disponibilité et la facilité d'utilisation.

Le co\^ut est un critère important car il est préférable d'avoir une capacité de stockage plusieurs fois supérieure aux 
besoins des données. Un support peu cher est généralement un must.

La fiabilité est extrêmement importante car une sauvegarde ab\^\i mée peut rendre malheureux un homme d'age m\^ur.
Un support de sauvegarde doit pouvoir garder des données sans problème pendant des années. La façon dont on utilise le
support affecte sa fiabilité comme support de sauvegarde. Un disque dur est normalement très fiable, mais
il n'est pas très fiable comme support de sauvegarde s'il est dans le m\^eme ordinateur que le disque que l'on
sauvegarde.

La vitesse n'est pas trop importante si les sauvegardes peuvent \^etre fa\^\i tes sans interaction. Cela ne pose
pas de problème qu'une sauvegarde dure deux heures tant qu'elle n'a pas besoin d'\^etre surveillée. D'un autre c\^oté, 
si la sauvegarde ne peut s'effectuer seulement au moment où l'ordinateur est inactif, alors la vitesse devient
critique.

La disponibilité est évidemment nécessaire car on ne peut utiliser un support de sauvegarde s'il n'existe pas. Ce qui est moins évident est que le support doit \^etre disponible dans le futur, et sur d'autres ordinateurs que le sien. Sinon, on 
peut ne pas pouvoir récupérer les données après un désastre.

La facilité d'utilisation est un facteur important de la fréquence des sauvegardes. Plus les sauvegardes sont faciles
à faire, mieux c'est. Un support de sauvegarde ne doit pas \^etre difficile ou pénible à utiliser.

Les choix classiques sont les disquettes et les bandes. Les disquettes sont très peu chères, plut\^ot fiables, pas très rapides, très disponibles mais peu utilisables pour des gros volumes de données. Les bandes sont peu chères à chères, plut\^ot 
fiables et rapides, disponibles, et --~selon la taille de la bande~-- plut\^ot confortables.

Il existe d'autres choix. Ils ne sont généralement pas très bons en termes de disponibilité mais, si cela ne pose pas de
problème, ils peuvent \^etre meilleurs sur d'autres points. Par exemple, les disques magnéto-optiques peuvent avoir les
bons c\^otés des disquettes (ils sont à accès direct, ce qui permet une récupération rapide d'un simple fichier) et
des bandes (ils contiennent beaucoup de données).

\section{Choix de l'utilitaire de sauvegarde}

Il existe de nombreux utilitaires pour faire les sauvegardes. Les outils UNIX traditionnels utilisés sont
\cmd{tar}, \cmd{cpio}, et \cmd{dump}.  De plus, un grand nombre de produits (gratuits ou commerciaux) peuvent aussi \^etre
utilisés. Le choix du support peut affecter le choix de l'outil.

	\cmd{tar} et \cmd{cpio} se ressemblent et sont relativement équivalents du point de vue des sauvegardes. Tous
deux peuvent stocker des fichiers sur des bandes et récupérer des fichiers à partir de celles-ci. Tous deux
peuvent utiliser la plupart des supports car les pilotes de périphériques du noyau s'occupent de la gestion de bas
niveau des périphériques qui se présentent ainsi de la m\^eme façon aux programmes utilisateurs. Certaines
versions UNIX de \cmd{tar} et \cmd{cpio} peuvent avoir des problèmes avec certains fichiers (liens symboliques, 
fichiers pilotes de périphériques, fichiers avec de très long noms, etc.), mais les versions Linux devraient gérer
ceux-ci correctement.

	\cmd{dump} est différent en ce sens qu'il lit directement le système de fichiers et non en passant par lui. Il est
aussi écrit spécifiquement pour les sauvegardes ; \cmd{tar} et \cmd{cpio} sont, en fait, destinés à l'archivage des
fichiers, bien qu'ils fonctionnent aussi pour les sauvegardes.

Le fait de lire directement le système de fichiers présente certains avantages. Cela permet de sauvegarder les fichiers sans 
modifier leur dates ; avec \cmd{tar} et \cmd{cpio}, on devrait d'abord monter le système de fichiers en lecture seulement. Cette lecture directe est aussi plus efficace si tout doit \^etre sauvegardé car cela peut \^etre fait avec beaucoup moins de
mouvement des t\^etes du disque. Le principal désavantage est que le programme de sauvegarde doit \^etre spécifique à 
un type de système de fichiers ; le programme \cmd{dump} de Linux ne fonctionne  qu'avec le système ext2.

\cmd{dump} supporte aussi directement les niveaux de sauvegarde (dont on parlera plus loin) ; avec \cmd{tar} et
\cmd{cpio} cela doit \^etre implanté à l'aide d'autres utilitaires.

Une comparaison entre les utilitaires de sauvegarde existants par ailleurs sort du cadre de ce livre. La Linux Software Map
donne une liste de plusieurs de ceux-ci existant en  freeware. 	

\section{Sauvegardes simples}

Un procédé simple de sauvegarde est d'abord de tout sauvegarder, puis de ne sauvegarder ensuite que ce qui a été
modifié depuis la sauvegarde précédente. La première sauvegarde est appelée \defin{sauvegarde complète}, les suivantes sont
les \defin{sau\-ve\-gardes incrémentales}. Une sauvegarde complète est souvent plus laborieuse que les in\-cré\-men\-tales car il 
y a plus de données à écrire sur la bande et parce que tout peut ne pas tenir sur une seule bande (ou disquette). La restauration à partir de sauvegardes in\-cré\-men\-tales peut représenter beaucoup plus de travail qu'à partir d'une
complète. La restauration peut \^etre optimisée si l'on sauvegarde toujours tout ce qui a été modifié depuis la
sauvegarde complète précédente ; de cette façon, les sauvegardes représente un peu plus de travail mais il n'y aura plus
besoin que de restaurer une sauvegarde complète et une sauvegarde in\-cré\-men\-tale.

Si l'on veut faire des sauvegardes tous les jours et que l'on a six bandes, on doit utiliser la bande~1 pour la première
sauvegarde complète (par exemple, le vendredi), et les bandes~2 à~5 pour les sauvegardes in\-cré\-men\-tales (lundi à jeudi). 
Puis, on refait une nouvelle sauvegarde complète sur la bande~6 (deuxième vendredi) et on recommence les sauvegardes incrémentales sur les bandes~2--5. On ne doit pas écraser la bande~1 tant que l'on n'a pas fait une nouvelle sauvegarde complète
de crainte qu'il ne se passe quelque chose pendant la sauvegarde complète. Lorsqu'une sauvegarde complète a été faite
sur la bande~6, on peut garder la bande~1 dans un autre endroit pour avoir au moins quelque chose à récupérer si toutes
les autres bandes sont détruites par le feu. Lors de la prochaine sauvegarde complète, on utilisera la bande~1 et on conservera la bande~6.

Si l'on a plus de 6 bandes, on peut utiliser celles en plus pour des sauvegardes complètes. A chaque fois que l'on fait une sauvegarde complète, on utilisera la bande la plus ancienne. Ainsi, on peut avoir des sauvegardes complètes datant de plusieurs
semaines, ce qui est pratique si l'on veut retrouver un ancien fichier, maintenant détruit, ou une ancienne version d'un fichier.

\subsection{Sauvegardes avec \cmd{tar}}

Une sauvegarde complète peut \^etre facilement faite avec \cmd{tar}~:
		%
		\begin{tscreen}
\# tar --create --file /dev/ftape /usr/src \\
tar: Removing leading / from absolute path names in the archive \\
\# 
		\end{tscreen}
		%
	L'exemple ci-dessus utilise la version GNU de \cmd{tar} et  les noms longs des options. La version traditionnelle
de \cmd{tar} ne reconna\^\i t que les options avec un seul caractère. La version GNU sait aussi gérer les sauvegardes
qui ne tiennent pas sur une seule bande ou disquette. Elle sait aussi gérer des noms de chemins très longs, les versions
traditionnelles ne savent pas toutes faire ça. (Linux utilise seulement la version GNU de \cmd{tar}.)
	
Si la sauvegarde ne tient pas sur une seule bande, on doit utiliser l'option \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}
		%
On notera que l'on doit formatter les disquettes avant de commencer la sauvegarde, ou alors utiliser une autre fen\^etre ou
un autre terminal virtuel et le faire lorsque \cmd{tar} demande une nouvelle disquette.

Lorsque la sauvegarde est terminée, on doit la vérifier en utilisant l'option \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}
		%
Ne pas vérifier une sauvegarde signifie que l'on ne s'apercevra pas que les sauvegardes ne fonctionnent pas jusqu'au
moment où on aura perdu les données originales.
	
Une sauvegarde incrémentale avec \cmd{tar} se fait en utilisant l'option \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}
		%
Malheureusement, \cmd{tar} ne peut s'apercevoir que l'information d'un inode de fichier a changé, par exemple que ses bits 
de permission ou son nom ont été modifiés. Ceci peut \^etre contourné en utilisant \cmd{find} et en comparant
l'état du système de fichiers actuel avec la liste des fichiers précédemment sauvegardés. Des scripts et des programmes
réalisant cette opération se trouvent sur les sites ftp Linux.
	
\subsection{Restauration des fichiers avec  \cmd{tar}}

	L'option \texttt{--extract} (\texttt{-x}) de \cmd{tar} extrait des fichiers~:
		%
		\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}
		%
On peut aussi n'extraire que des fichiers ou répertoires spécifiques (ce qui inclut tous leurs fichiers et sous-répertoires)
en le précisant sur la ligne de commande~:
		%
		\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}
		%
Si l'on veut simplement conna\^\i tre les fichiers se trouvant sur un volume de sauvegarde, on utilise 
l'option \texttt{--list} (\texttt{-t})~:
		%
		\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}
		%
On notera que \cmd{tar} lit toujours séquentiellement le volume, ce qui est plut\^ot lent pour les gros volumes. Il n'est
pas possible d'utiliser les techniques d'accès directs lorsqu'on utilise un lecteur de bande ou tout autre support
séquentiel.
	
	\cmd{tar} ne gère pas correctement les fichiers détruits. Si l'on a besoin de restaurer un système de
fichiers à partir d'une sauvegarde complète et d'une incrémentale, et que l'on a détruit un fichier entre les
deux sauvegardes, il existera à nouveau après cette restauration. Ceci peut \^etre un gros problème si le fichier
contient des données sensibles qui ne devraient plus \^etre disponibles.

\section{Sauvegardes multi-niveaux}

La méthode de sauvegarde simple décrite dans la section précédente est la plupart du temps adaptée à une utilisation personnelle ou pour de petits sites. Pour une utilisation plus intensive, les sauvegardes multi-niveaux sont plus appropriées.

La méthode simple a deux niveaux de sauvegarde~: sauvegardes complète et incrémentale. Ceci peut se généraliser à un
nombre quelconque de niveaux. Une sauvegarde complète serait de niveau~0, et les différents niveaux des sauvegardes
incrémentales seraient de niveaux~1, 2, 3, \dots A chaque niveau de sauvegarde incré\-men\-tale, on sauvegarde tout ce qui a 
changé depuis la sauvegarde précédente de niveau égal ou inférieur.

La raison de cette façon de faire est qu'elle permet facilement un \defin{historique des sauvegardes} plus long. Dans 
l'exemple de la section précédente, l'historique des sauvegardes remonte à la sauvegarde complète précédente. On peut 
l'étendre en ayant plusieurs bandes, mais uniquement une semaine par nouvelle bande, ce qui peut s'avérer trop
co\^uteux. Un historique des sauvegardes plus long est utile car les fichiers détruits ou ab\^\i més ne sont
souvent pas notés pendant longtemps. M\^eme une version d'un fichier qui n'est pas trop à jour est préférable
à pas de fichier du tout.

Avec de multiples niveaux, l'historique des sauvegardes peut \^etre étendu de façon peu co\^uteuse. Par exemple, si l'on
achète dix bandes, on peut utiliser les bandes~1 et~2 pour les sauvegardes mensuelles (premier vendredi de chaque mois), les
bandes~3 à~6 pour les sauvegardes hebdomadaires (autres vendredi ; on notera qu'il peut y avoir cinq vendredi dans un mois, on
a donc besoin de 4 bandes), et les bandes~7 à~10 pour les sauvegardes journalières (lundi à jeudi). Avec seulement quatre
bandes de plus, on a pu étendre l'historique des sauvegardes de deux semaines (après que toutes les bandes journalières aient
été utilisées) à deux mois. Il est vrai que l'on ne peut restaurer chaque version de chaque fichier pendant ces deux mois,
mais ce que l'on peut récupérer est souvent suffisant.

	La figure~\ref{fig:backup-history-timeline} montre quel est le niveau de sauvegarde utilisé chaque jour, et
les sauvegardes qui peuvent \^etre restaurées à partir de la fin du mois.

	\begin{figure}[t]
	\begin{center}
	\includegraphics{backups/backup-timeline.ps}
	\end{center}
	\caption{Un procédé simple de sauvegarde multi-niveaux.}
	\label{fig:backup-history-timeline}
	\end{figure}

Les niveaux de sauvegarde peuvent aussi \^etre utilisés pour minimiser le temps de restauration d'un système de fichiers. 
Si l'on a plusieurs sauvegardes incrémentales avec des numéros de niveaux croissant de façon monotone, on doit tous
les restaurer si l'on veut reconstruire l'ensemble du système de fichiers. Au lieu de ça, on peut utiliser des numéros
de niveaux qui ne sont pas monotones et diminuer le nombre de sauvegardes à restaurer.

Pour minimiser le nombre de bandes nécessaires à la restauration, on peut utiliser un niveau plus bas pour chaque bande
incrémentale. Cependant, le temps consacré aux sauvegardes augmente alors (chaque sauvegarde copie tout depuis la dernière
sauvegarde complète). Un procédé plus efficace est suggéré dans les pages du manuel en ligne de \cmd{dump} et décrit par
le tableau~\ref{tab:efficient-backup-levels}.  On utilise la succession des niveaux de sauvegarde suivante~:
 3, 2, 5, 4, 7, 6, 9, 8, 9\dots  Ceci réduit les temps de sauvegarde et de restauration. Le plus que l'on a à sauvegarder
est deux jours de travail. Le nombre de bandes pour une restauration dépend du temps écoulé entre deux sauvegardes 
complètes, mais c'est moins que dans le cas des procédés simples.

\begin{figure}[htb]
\begin{center}
\begin{tabular}{r l l l}
Bande &	Niveau &	Sauvegarde &	Restauration \\
      &        &	(jours)    & bandes \\
\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}
\caption{Procédé de sauvegarde efficace utilisant plusieurs niveaux de sauvegarde}
\label{tab:efficient-backup-levels}
\end{figure}
			
Un procédé exotique peut réduire le travail nécessaire, mais cela signifie qu'il y a plus de choses à se souvenir. On doit
décider si le jeu en vaut la peine.

\cmd{dump} possède un support intégré des niveaux de sauvegarde. En ce qui concerne
\cmd{tar} et \cmd{cpio} ils doivent \^etre implantés par des scripts shells.
	
\section{Que sauvegarder}

On veut sauvegarder le plus possible. La principale exception concerne les logiciels que l'on peut facilement 
réinstaller,\footnote{On peut décider de ce qui est facile. Certains considèrent qu'une installation  à partir d'une
douzaine de disquettes est quelque chose de facile.} mais, m\^eme dans ce cas, ces logiciels peuvent avoir des fichiers
de configuration qu'il est important de sauvegarder, de crainte d'avoir à refaire tout le travail de configuration.
Une autre exception importante est le système de fichiers \fn{/proc} ; puisqu'il ne contient que des données générées
automatiquement par le noyau, ce n'est \emph{jamais} une bonne idée de le sauvegarder. Notamment, le fichier
\fn{/proc/kcore} n'est pas nécessaire ; n'étant qu'une image de la mémoire physique disponible, il est plut\^ot gros.

Les autres parties à ignorer sont le spool des news, les fichiers diagnostiques et beaucoup d'autres choses dans
\fn{/var}.  On doit décider de ce que l'on considère comme important.

Les chose évidentes à sauvegarder sont les fichiers utilisateurs (\fn{/home}) et les fichiers de configuration du système
(\fn{/etc}), mais d'autres choses sont probablement disséminées à travers tout le système de fichiers.

\section{Sauvegardes compressées}

Les sauvegardes occupent beaucoup de place, ce qui peut co\^uter beaucoup d'argent. Afin de réduire cet espace, les
sauvegardes peuvent \^etre compressées. Il existe plusieurs façons de réaliser cela. Certains programmes intègrent cette
compression ; par exemple, l'option \texttt{--gzip} (\texttt{-z}) du \cmd{tar} GNU envoit l'ensemble de la sauvegarde au
programme de compression \cmd{gzip} avant de l'écrire sur le support de sauvegarde. 
	
Malheureusement, les sauvegardes compressées peuvent poser problème. A cause de la façon dont la compression fonctionne,
si un seul bit est erroné, tout le reste des données compressées sera inutilisable. Certains programmes de sauvegarde 
intègrent une correction des erreurs, mais aucune méthode ne peut gérer un nombre important d'erreurs. Ceci 
signifie que si la sauvegarde est compressée à la façon du \cmd{tar} GNU, avec la sortie tout entière compressée
en une seule unité, une seule erreur fait perdre tout le reste de la sauvegarde. Les sauvegardes doivent \^etre
fiables, et cette méthode de compression n'est pas bonne.
	
Une autre façon de faire est de compresser chaque fichier séparément. Ainsi, si un fichier est perdu, les autres restent
intacts. Le fichier perdu aurait été ab\^\i mé de toutes façons, la situation n'est donc pas pire que si l'on n'avait
pas utilisé de compression. Le programme \cmd{afio} (une variante de \cmd{cpio}) sait faire ça.
	
La compression prend du temps, ce qui peut emp\^echer le programme de sauvegarde d'écrire les données suffisamment
rapidement pour un lecteur de bandes.\footnote{Si un lecteur de bandes ne reçoit pas les données suffisamment vite,
il s'arr\^ete ; ceci ralentit d'autant les sauvegardes, et peut s'avérer mauvais aussi bien pour les bandes que pour
le lecteur.} On peut éviter cela en différant la sortie (soit de façon interne, si le programme de sauvegarde est 
suffisamment évolué, soit en utilisant un autre programme), mais m\^eme cela peut ne pas fonctionner suffisamment bien.
Ce problème n'appara\^\i t que sur les ordinateurs lents.
















