stephbul

Lors de la panne d’un disque dur, il me semble que personne n’a pu éviter de penser que ce n’était vraiment pas le moment. Quand il s’agit d’un serveur sur lequel est hébergé des services (ce blog notamment), il faut réagir vite pour ne pas frustrer les innombrables lecteurs que vous êtes. La panne d’un disque a des effets différents et par chance, par moment, elle s’annonce par quelques symptômes avant-coureur, des petits bruits, des problèmes de système de fichier. Hier, ce ne sont pas des bruits qui m’ont alerté puisque ma machine se trouve à environ 250 km de mon domicile, mais l’impossibilité d’effectuer certaines commandes unix, celles qui nécessitaient notamment l’écriture dans ma partition / de mon file system.

La commande dmesg du serveur sous une distribution linux ubuntu server me renseignait alors très bien:

[1815129.630045] hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
[1815129.630055] hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=61642, high=0, low=61642, sector=61639
[1815129.630069] ide: failed opcode was: unknown
[1815129.630076] end_request: I/O error, dev hda, sector 61639
[1815129.630136] journal_bmap: journal block not found at offset 7180 on hda1
[1815129.630167] Aborting journal on device hda1.
[1815129.631994] journal commit I/O error
[1815129.632192] ext3_abort called.
[1815129.632211] EXT3-fs error (device hda1): ext3_journal_start_sb: Detected aborted journal
[1815129.632237] Remounting filesystem read-only

L’impossibilité d’accéder à certains secteurs avait obligé ext3 à placer la partition / en read-only. La partition /home n’est pas passée en lecture seule, enfin pas encore et il est préférable d’agir immédiatement, en prenant le temps d’aller vite et garder son calme.

La principale contrainte: faire du back-up rapide en évitant les écritures sur le disque.

Sauvegarder ce blog utilisant le moteur de blog wordpress:
Impossible de faire un dump de la base sql, puisque mysqldump a besoin d’écrire dans /tmp. Il va donc falloir faire une copie de l’arborescence. Ce n’est pas une solution à recommander, mais c’est la seule que j’ai. Je vais devoir récupérer /var/lib/mysql

Backuper /home:
La dernière version de son backup est évidemment trop ancienne.

Backup les confs:
La mauvaise gestion de mes arborescences de configuration est flagrante, elles sont toutes dans /etc, ce qui m’oblige aussi à le sauvegarder. Je ne m’y referai plus prendre, elles seront toutes, c’est décidé, dans /home/user/etc afin que la sauvegarde soit plus simple.

Bien, comment faire un backup de tout cela qui soit rapide?
-scp? Non, trop lent, pas besoin de chiffrer, d’autant que je passe déjà par un vpn, l’overhead de chiffrement de ssh ne me satisfait pas.
-L’élégant tar, tar cvf - /source-dir | ssh user@backup-server.home “cat > /backup/source-dir.tar n’est pas plus souhaitable, pour la même raison.
-Puis, toujours dans l’idée d’aller lentement pour aller vite, je parle à iMil de mes soucis. Il me glisse l’idée de passer par netcat pour effectuer un back-up rapide. Je ne connais pas et l’idée de prendre le temps d’apprendre, là maintenant, dans la panade ne me me plait pas d’emblée. Je dois prendre le temps, mais tout de même. Le principe est d’écouter sur un port d’un côté et de mettre dans stdout ce qu’on y reçoit, et d’envoyer stdin de l’autre machine sur ce port. L’intérêt est alors de l’associer à tar. L’idée fait son chemin. Quelques minutes plus tard:

$ man netcat

me donne nc - TCP/IP swiss army knife. J’aime bien l’idée.

Après quelques essais, j’obtiens sur la machine où je veux backuper:

$ netcat -l 3869 | tar xfp -

Cette commande met en écoute netcat sur le port 3869 et envoie le résultat vers le stdin (-) de tar pour l’extraire.

Sur la machine que je veux backuper:

$ tar cvfp - source-dir | netcat host 3869

où source-dir est le répertoire à sauvegarder sur la machine host.
Comme je ne sais pas si tar -z a besoin des droits d’accès en écriture, j’évite de l’utiliser. Si d’ailleurs quelqu’un a la réponse, il peut me laisser un petit comment.

La phase la plus difficile est de prioriser le backup sans rien oublier. Je pense la phrase “Tu n’as rien oublié?” complètement inutile et parfaitement stupide. Le risque d’oubli n’est pas nul, et comme je ne peux pas envisager faire un backup total de la machine qui serait beaucoup trop long et inutile, il faut se concentrer, faire le tour de l’arborescence, puis refaire un tour… et se lancer.

Se lancer, cela veut dire, ouvrir un ticket chez le hoster de mon serveur dédié. Je dois reconnaître qu’OVH, mon hoster a été très rapide pour intervenir. Deux heures plus tard, mon disque était changé, l’install d’une debian 5.0 terminée. J’abandonnai ubuntu pour debian.

Il me reste à cet instant l’install, la config de tous les services, aussi proprement que possible pour faciliter les backups.

Je vous fais une liste des opérations que j’ai effectuées pour avoir mon service up and running:

-Changement du mot de passe root
-Modification du /etc/apt/sources.list pour le faire pointer sur une debian testing ou stable, au choix. stable est plus conseillé sur une machine de prod, bien entendu.

/etc/apt/sources.list:

deb http://ftp.fr.debian.org/debian/ stable main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ stable main contrib non-free
deb http://security.debian.org/ stable/updates main contrib non-free
deb-src http://security.debian.org/ stable/updates main contrib non-free

-Je ne veux pas utiliser lilo, et préfère grub.

apt-get remove lilo
apt-get install grub
update-grub
grub-install "(hd0,0)"
grub
>root (hd0,0)
>setup (hd0)
>quit

Il faut alors installer le kernel pour ne pas utiliser le kernel monolythique proposé par le hoster.

apt-get update
apt-cache search kernel-image et choisir le bon.
apt-get install kernel-image-2.6.26-2.i686
apt-get dist-upgrade

Rebooter.
Tout s’est bien passé dans mon cas. Je peux continuer:

-Modification du hostname
-Création de mon user principal useradd -m user
-Modification du /etc/ssh/sshd_config pour interdire l’accès en ssh à root et l’accès par mot de passe:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no

-Récupération du répertoire .ssh des utilisateurs qui se connectent par ssh dans lequel on a les clés autorisées.
Attention, à partir de cet instant, il ne faut plus fermer son terminal avant d’avoir tester la connexion par clé, sous peine de devoir rebooter en mode rescue avec un mot de passe root fourni par OVH, monter ses partitions à la main et changer la config de ssh. Le mode rescue d’OVH est excellent, mais il est préférable d’en éviter la lourdeur inévitable.

etc/init.d/ssh restart

Essayer de se connecter avec un autre terminal, si c’est ok, on continue.

-Installation de openvpn en tant que serveur.
Pour respecter mon engagement, je place tous mes fichiers de conf dans /home/user/etc/openvpn et rien dans /etc/openvpn et je n’utilise pas le script /etc/init.d/openvpn start pour le démarrer, mais je préfère screener l’application

cd /home/user/openvpn/
screen -S openvpn
openvpn --config server.conf

Ctrl a-d # pour détacher le screen sans le terminer
A cet instant, si vous êtes encore plus novice que moi et que nous ne connaissez pas screen, un “man screen” est obligatoire.

server.conf est mon fichier de conf server.conf, récupéré de mon backup. J’ai bien entendu modifié les chemins d’accès vers /home/user dans celui-ci.

Passons au service apache pour relancer blog et wiki.

sudo apt-get install apache2 php5 mysql-server php5-mysql libapache2-mod-gnutls

L’utilisateur www-data est créé automatiquement par l’installaton d’apache2, mais je lui crée son répertoire et mot de passe. Je déplace toutes les conf apache dans /home/www-data/ et fais un dans /etc fait un ln -s /home/www-data/etc/apache2 apache2 en modifiant /home/www-data/etc/apache2/apache2.conf

Je laisse mysql configuré comme par défaut dans /etc/mysql, celui-ci ne nécessite pas de modification dans mon cas et la sauvegarde doit se faire par mysqldump.

Je copie la base sql de mon blog dans /var/lib/mysql/bulblog, je modifie les propriétés avec chown.
J’utilise wordpress comme moteur de blog. Le nom du user utilisant la base mysql se trouve dans wp-config.php avec son mot de passe. Je crée l’utilisateur avec des droits d’accès depuis localhost seulement.

mysql -u root -p

mysql> CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'wpuserpass';
mysql>  GRANT ALL ON *.* TO 'wpuser'@'localhost';
mysql> quit

Attention, il est important de ne laisser l’accès que depuis localhost, car l’utilisateur a tous les droits.

Dans apache, il faut maintenant recopier tous les contenus des pages backupées dans les bons répertoires des config de site définis dans /home/www-data/etc/apache2/sites-available
Un test préalable du serveur apache lui-même est conseillé avec la page par défaut “it works”.
Ensuite, il faut activer les sites avec la commande:

a2ensite filename

où filename est le nom du fichier de conf du site dans /etc/apache2/sites-available qui est un lien vers /home/www-data/etc/apache2/sites-available .

On termine avec un /etc/init.d/apache2 restart

Utilisant dokuwiki pour mon wiki, la gestion par fichier plat des données simplifie grandement le backup, la simple copie avec les bons droits et bons propriétaires suffit pour remettre l’ensemble en service.

Puisque vous pouvez lire ces lignes, c’est que mon aventure s’est bien terminée et que j’ai pu reprendre le cours normal de mes opérations. Si j’étais un habitué des bonnes résolutions, je me promettrais de travailler plus proprement sur les backups.

En tout cas merci à iMil pour ses conseils, innombrables et toujours judicieux.