6. Seconde étape de la restauration

Au redémarrage de l'ordinateur, vérifiez dans le BIOS que l'heure est à peu près correcte.

Une fois la vérification terminée, sortez du BIOS et redémarrez sur le disque dur. Laissez simplement la séquence de démarrage normal de l'ordinateur se dérouler. Vous verrez un nombre important de messages d'erreurs, essentiellement de type «  Impossible de trouver bla-bla ! Ouahhh ! » Si vous avez bien travaillé jusqu'à maintenant, ces messages d'erreurs seront sans importance. Vous n'avez pas besoin de linuxconf ou d'apache pour cette opération.

[Note]N.B.

Vous pouvez aussi démarrer en mode utilisateur unique (single user) : à l'invite de lilo, saisissez : linux single, mais il vous faudra configurer manuellement votre réseau et lancer sshd ou tous les démons nécessaires au redémarrage de votre système. Chaque système a sa méthode spécifique.

Vous devriez vous identifier sur une console en tant que super utilisateur (root) (désolé, pas de session X, pas d'utilisateurs). À présent, vous devriez pouvoir utiliser le réseau, par exemple pour monter la sauvegarde de votre système via nfs.

Si vous avez effectué la sauvegarde en deux étapes que j'ai suggérées pour Arkeia, vous pouvez maintenant restaurer les exécutables et la base de données d'Arkeia. Vous devriez pouvoir lancer

/etc/rc.d/init.d/arkeia start

et démarrer le serveur. Si vous avez une interface graphique installée sur un autre ordinateur, vous devriez pouvoir vous connecter à Arkeia sur votre serveur de bandes et préparer la restauration.

[Note]N.B.

Pendant la restauration, lisez attentivement la documentation de restauration de vos programmes. Par exemple, d'habitude, tar ne restaure pas certaines caractéristiques de fichiers, telles que le bit suid. Les droits sur les fichiers sont fixées par l'utilisateur avec la commande umask. Pour restaurer vos fichiers exactement comme vous les avez sauvegardés, utilisez l'option tar avec l'option p. De la même manière, vérifiez que votre logiciel de restauration restaure les données de façon identique à la sauvegarde.

Pour restaurer l'ordinateur de test, saisissez :

bash# restore.all

Si vous avez sauvegardé et restauré avec tar, et avez utilisé l'option -k (conserver les anciens fichiers, ne pas écraser), vous constaterez un nombre important de :

tar: usr/sbin/rpcinfo: Could not create file: File exists
tar: usr/sbin/zdump: Could not create file: File exists
tar: usr/sbin/zic: Could not create file: File exists
tar: usr/sbin/ab: Could not create file: File exists

Ceci est normal, tar refusant d'écraser les fichiers que vous avez restaurés pendant la première étape.

Puis redémarrez. À la fermeture, vous verrez un nombre important de messages d'erreurs, tels que « no such pid ». Ils font partie du processus. Le programme de fermeture utilise les fichiers pid des démons qui tournaient au moment de la sauvegarde pour fermer les démons qui n'avaient pas été lancés au dernier démarrage. Et évidemment, il n'ont pas de PID.

Votre système devrait s'initialiser normalement avec beaucoup moins d'erreurs que précédemment et idéalement sans erreurs. Le test décisif du bon fonctionnement de votre restauration sur un système basé sur des RPM est de vérifier tous les paquets :

bash# rpm -Va

Si vous constatez des messages d'erreurs de dépendances, vous pouvez lancer la commande /etc/cron.daily/prelink pour les enlever.

Certains fichiers, tels que les fichiers de configuration et les journaux, auront naturellement changé ; vous devriez pouvoir mentalement les exclure du rapport. Vous pouvez rediriger la sortie dans un fichier, et le comparer grâce à diff avec celui effectué lors de la sauvegarde (/etc/rpmVa.txt), ce qui accélérera considérablement cette étape. Les utilisateurs d'Emacs devraient se renseigner sur ses aptitudes à comparer des fichiers.

À présent, votre système devrait être lancé et fonctionner. C'est le moment de tester vos applications, particulièrement celles lancées en tant que démons. Plus les applications seront sophistiquées, plus il vous faudra effectuer des tests. S'il y a des utilisateurs distants, interdisez leur l'accès du système, ou passez le en « lecture seule » le temps des tests. Ceci vaut particulièrement pour les bases de données, afin empêcher une corruption ou une perte de données pire que ce qu'il pourrait déjà y avoir.

Si d'habitude vous redémarrez directement sous X et que vous l'avez désactivé plus haut, testez X avant de le réactiver. Réactivez-le en rétablissant cette unique ligne dans le fichier /etc/inittab :

id:5:initdefault:

Vous pourrez alors aller faire la fête, prendre un peu d'aspirine et aller au dodo.