« Help me, j’ai crashé ma DB »

En informatique, le manque de rigueur se paye cash. Malheureusement, j’ai pu encore le constater hier soir .Un point de montage mal monté par un de mes scripts,pas de contrôle, une partition racine désormais occupée à 100%, en réaction des services qui plantent,des erreurs d’écriture,et patatra au final une mariadb qui ne veut plus rien savoir…
Bref ce jour là , les problèmes s’enchainent les uns après les autres…Je passe sur les causes exactes de la  perte de toutes mes bases de données mais sachez qu’au final , je n’avais plus accès à mon Nextcloud ni à mon Egroupware. Ces deux services, avec le temps, me sont devenus vitaux tant sur le plan perso que pro. Donc objectif faire preuve de sang froid et de réactivité pour remettre tout ça d’aplomb.
Allez hop on se retrousse les manches!

Prérequis

Heureusement, en bon administrateur que vous êtes , vous disposez à minima de sauvegardes. Mais c’est dans ce genre de situation critique et brutale que vous allez pouvoir attester de leur pertinence ou bien tester la qualité de la boite de mouchoirs la plus proche.
Je pars du principe comme moi vous avez automatisé des dumps sql quotidiens en direction de votre NAS ou autre serveur.Je pars aussi du principe que le répertoire qui contient les fichiers de l’appli est indemne. Seules les bases de données ont été effacées.
La suite du billet est une méthodologie simple et rapide pour pouvoir remettre en place des applicatifs web qui tournent sous MariaDB ou mysql.

1/ Retrouver les informations de connexion aux bases de données

Quelque soit l’applicatif web , en général les informations de connexion à la base de données se trouvent en clair dans un « bête » fichier de configuration:

Voici quelques exemples:

• sous wordpress => wp-config.php
• sous Nextcloud => config/config.php
• sous Egroupware => header.inc.php
• etc…

Au passage , j’ouvre une parenthèse ,vous conviendrez que ce genre de fichier très sensible doit être sécurisé un maximum pour éviter de donner les clés du royaume à un potentiel attaquant.
Si vous n’êtes pas convaincu, faites une petite recherche avec les bons mots clés dans votre moteur de recherche préféré et vous serez surpris du nombre de fichiers de config accessible en lecture avec tous les identifiants nceséssaires en clair sur le grand Internet. Alors ok dedans on trouve beaucoup de base de données de tests , de dev mais pas que …
Pour worpress , je vous conseille cet excellent billet qui vous donne quelques pistes sérieuses pour mettre à l’abri votre fichier de config.

Voici un extrait de mon fichier de config nextcloud:

'dbname' => 'nextcloud',
'dbhost' => 'localhost',
'dbport' => '',
'dbtableprefix' => 'oc_',
'dbuser' => 'toto',
'dbpassword' => 'mdpDeToto',

les informations importantes sont en gras.

2/ Recréer la coquille

Connexion à mariaDB:

mysql -u root -p

Création de la base de données nextcloud:

CREATE DATABASE nextcloud;

Création de l’utilisateur « toto » habilité à créer, modifier , supprimer la base de données « nextcloud »

CREATE USER 'toto'@'localhost' IDENTIFIED BY 'mdpDeToto';

GRANT ALL PRIVILEGES ON nextcloud.* TO 'toto'@'localhost';

flush privileges;

exit;

Maintenant que nous avons recréé la coquille nous allons la remplir avec la sauvegarde la plus fraîche possible. Pour ma part ce sera celle de la veille, c’est déjà un moindre mal.

3/ Restaurer la sauvegarde sql

Sélection de la base de données pour laquelle on souhaite restaurer:

use nextcloud;

Import du fichier de sauvagarde sql . Cette opération peut être plus ou moins longue en fonction de l’importance des tables et du contenu à réimporter. Il existe plusieurs manières de faire en voici deux:

source sauvegarde_nextcloud.sql
ou
mysql --user=toto --password=mdpDeToto nomBDD < /Chemin/Vers/fichier_dump.SQL

Si tout se passe bien, vous verrez un certains nombre de « query » à ok. Pour vérifier que les tables ont bien été créées:

show tables;

Et pour finir, on teste la connexion à son appli web dans son navigateur: https://monnextcloud.com

Moralité

Même si les applis sont persos et hébergées à domicile il ne faut pas négliger la qualité des sauvegardes.Il faut bien s’assurer que l’on dispose de toutes les données pour rétablir l’application au plus vite.ne pas hésiter à tester les sauvagardes de temps en temps.
La morale de cette histoire:  Procrastination et sauvegarde ne font pas bon ménage!

Ce que j’ai décidé d’améliorer suite à cette petite mésaventure:

• sauvegarder la vue « mysql » qui contient toutes les informations et identifiants de connexion aux bases de données (ce qui permettra de s’affranchir de l’étape 2 « recréer la coquille »)
• réduire la rétention des fichiers sql mais augmenter la fréquence des sauvegardes sql afin d’avoir les données les plus fraîches possibles
• mettre en place une alerte sur l’espace disque occupé avec la mise en place de quota et un seuil d’alerte minimal à 80%