C’est moche mais ça peut arriver, le serveur de prod crash et vous n’avez pas de sauvegardes…

Si le disque est encore accessible, tout n’est pas perdu !

J’ai eu le cas tout juste hier sur une VM de production d’une machine Ubuntu où, suite à une mise à jour, la récupération du système n’était pas possible et la restauration de la VM n’était pas possible (problème interne au logiciel de backup)

J’ai remonté une nouvelle VM avec un OS tout neuf, et ai récupéré l’ancien disque VHDX (HyperV 2012 R2) pour le mapper sur  mon PC local. Joie et bonne humeur de se souvenir au dernier moment que les fichiers VHDX ne peuvent être ouverts par un Windows > 8.1, donc exit Windows 7. Il faut faire une conversion VHDX -> VHD pour que Windows 7 puisse travailler avec.

Point critique suivant, le disque est monté en LVM, non reconnu par les logiciels principaux, Windows 7 voit donc ce disque comme RAW et me propose de le formatter…

Dernière tentative, associer le disque sur une VM locale Linux, j’ai une Debian8 qui traine dans mon Workstation, j’ajoute le VHD (pas besoin de le convertir au format VMWare), je boot et … bah il est là mais impossible de le monter.

Il faut passer par

apt-get install lvm2
pvscan          # Permet de vérifier que les partition LVM sont bien détectées
vgscan          # Scanne tous les volumes LVM trouvés
vgchange -ay    # Active tous les volumes LVM trouvés
lvscan          # Scanne toutes les partitions actives sur volume LVM

Pensez à lancer toutes les commandes !

Une fois l’outil installé le disque est monté et les données accessibles (youpi). Attention le root du nouveau système ne peut accéder aux données du root de l’ancien système, il faut faire un chown pour remettre les droits.

Récupérer les données s’avère être un poil plus compliqué, vu qu’il n’y a pas de fichier *.sql, mais les données brutes dans /var/lib/mysql/database_name/

On trouve ici les fichiers *.frm (structure de la table) et *.idb (données)

Il faut récupérer ces données pour les mettre sur le nouveau serveur dans un dossier /var/tmp par exemple (surtout pas dans /var/lib/mysql !!)

Sur votre nouveau serveur de production, installez MariaDB (ou MySQL) puis installez MySQL Utilities

apt-get -y install mysql-utilities

On va utiliser le module mysqlfrm pour sauver notre tête

La commande s’utilise de cette forme

mysqlfrm --port=4321 --server=root@localhost --user=root file.frm > file.sql

Vous pouvez être dans le dossier où se trouvent les fichiers *.frm ou sinon donner le chemin complet du fichier à la commande. L’opération est à faire pour chaque fichier, ou, si vous êtes fainéants, la commande plus brutale :

mysqlfrm --port=4321 --server=root@localhost --user=root *.frm > file.sql

Utilisez MySQL ou Adminer pour pousser ce fichier sql dans votre base, vous avez ainsi recréé la structure des bases, les tables sont cependant vides.

Pour les remplir, il faut dire au serveur de désolidariser la table du fichier disque. La commande pour cette action est

ALTER TABLE table_name DISCARD TABLESPACE;

Remplacez table_name par le nom de la table, et oui, à faire pour chaque table.

Faites ensuite un copier de l’ancien fichier au bon emplacement puis on redonne les droits mysql au fichier

cp /var/tmp/mysql/table_name.idb /var/lib/mysql/database_name
chown mysql:mysql /var/lib/mysql/database_name/table_name.idb

On réintègre le fichier disque dans la base

ALTER TABLE table_name IMPORT TABLESPACE;

Et le tour est joué.

Juste après ça, je vous conseille un mysqldump, juste au cas où…