Connexion
Récuperer les bases de données de feu mon cluster k3s, sans backup
Oui, comme la maxime qui parle d’un cordonnier, je n’avais pas encore mis en place les backups MariaDB quand mon dernier raspberry Pi, plus précisément sa carte SD, a rendu l’âme. Donc pour la restauration sur la nouvelle installation, c’est compliqué. Mais pas impossible non plus 
Pour ceux qui n’ont pas forcément suivi toute l’histoire de ce cluster, petit rappel: deux Raspberry Pi, du k3s sur Raspberry Pi OS, un master, un worker. J’avais retiré le worker pour bosser sur une refonte, à savoir une installation de Talos sur SSD, mais le master qui s’est retrouvé tout seul a commencé à montrer des signes de fatigue. J’avais juste mis ça sur la charge de porter tous les pods, mais il s’avère que les écritures plus nombreuses ont accéléré la mort de la carte SD.
Oui car dans une installation Kubernetes, et même si les principaux volumes de mes applications sont provisionnés/montés par le driver CSI NFS, les logs, et toute l’activité liée aux pods, sont écrits sur le volume local de la machine, et donc ici une carte SD. même en ayant pris un modèle plus adapté à ce cas d’usage, au bout de plus de 5 ans, ça commençait à faire trop, et elle m’a lâché sans prévenir pendant mes vacances.
Faites des sauvegardes bordel !
Ou alors « Faites ce que je dis, pas ce que je fais ». Après la réinstallation de Mariadb via le mariadb-operator (qu’on avait d’ailleurs fait en live, abonne-toi toussa :D), j’avais laissé de côté les sauvegardes pour me concentrer sur la migration des bases et la reconfiguration des applications. J’ai ensuite porté mon attention ailleurs et je ne suis jamais revenu dessus. La seule forme de sauvegarde que j’ai, c’est que le datadir de l’instance MariaDB n’est pas sur les nœuds mais sur mon NAS, et j’ai un job de sauvegarde quotidien vers une Storage Box Hetzner. Même sans cette externalisation, le fait que le datadir est toujours disponible est déjà une certaine sécurité.
Sauf que… qui dit mariadb-operator dit gestion par l’opérateur du compte root de l’instance, donc quand il s’agit de restaurer, je ne peux pas juste resynchroniser le datadir dans le nouveau volume, parce que je n’ai plus les manifestes qui vont avec, en clair, je n’ai plus le compte root. J’ai donc un joli datadir, mais pas directement exploitable pour la restauration. Sans parler que je profite de la nouvelle installation pour passer sur une version plus récente de MariaDB. bref, ça me complique la vie. Mais ne c’est pas perdu pour autant.
La tactique de la lessive
(si vous l’avez celle-là…) J’avais déjà eu à gérer ça sur le serveur d’un client un jour, je me souviens plus la cause de départ, mais on avait besoin de réinitialiser le compte root de son instance MySQL, en gros, on s’était enfermé dehors. L’astuce, c’est de démarrer une instance MySQL en spécifiant le datadir, et en utilisant l’option --skip-grant-tables pour démarrer sans authentification. À proscrire absolument dans le monde réel, mais dans le besoin…
Dans mon cas, j’ai bossé sur mon installation WSL2 sur Ubuntu 22.04. J’ai commencé par vérifier la version de MariaDB que j’avais utilisé pour le déploiement de l’instance: 10.11.4. J’ai suivi ensuite la doc officielle pour ajouter le dépot mariadb pour ma branche:
curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-10.11"
Comme souvent dans le cas de cette méthode horrible du curl | bash, j’ai vérifié le script avant, vérification que je vous recommande de faire systématiquement, ici tout va bien. Une fois donc le script exécuté, qui aura ajouté la clé GPG et le dépot. On peut donc passer à l’installation:
$ sudo apt install mariadb-server Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: htop libnl-3-200 libnl-genl-3-200 libsass1 libva-wayland2 linux-headers-5.15.0-139 linux-headers-5.15.0-139-generic Use 'sudo apt autoremove' to remove them. The following additional packages will be installed: galera-4 libcgi-fast-perl libcgi-pm-perl libconfig-inifiles-perl libdbd-mysql-perl libdbi-perl libfcgi-bin libfcgi-perl libfcgi0ldbl libhtml-template-perl libmariadb3 libmysqlclient21 libterm-readkey-perl liburing2 libwrap0 mariadb-client mariadb-client-core mariadb-common mariadb-server-core mysql-common pv socat Suggested packages: libmldbm-perl libnet-daemon-perl libsql-statement-perl libipc-sharedcache-perl mailx mariadb-test doc-base The following NEW packages will be installed: galera-4 libcgi-fast-perl libcgi-pm-perl libconfig-inifiles-perl libdbd-mysql-perl libdbi-perl libfcgi-bin libfcgi-perl libfcgi0ldbl libhtml-template-perl libmariadb3 libmysqlclient21 libterm-readkey-perl liburing2 libwrap0 mariadb-client mariadb-client-core mariadb-common mariadb-server mariadb-server-core mysql-common pv socat 0 upgraded, 23 newly installed, 0 to remove and 3 not upgraded. Need to get 28.2 MB of archives. After this operation, 159 MB of additional disk space will be used. Do you want to continue? [Y/n]
Première chose que je fais, c’est de désactiver le service, car il est de coutume dans les environnement « Debian-like » que l’installation d’un paquet avec un service inclue l’activation et le démarrage par défaut dudit service. J’ai donc déjà un serveur MariaDB démarré à la fin de l’installation:
sudo systemctl disable --now mariadb.service
Ensuite, je récupère une copie via rsync de mon datadir dormant:
rsync -a 192.168.1.201:/volume1/Kube/pvc-3dbb41c0-41ea-4f09-90cc-4aa186124266/ ./datadir/
Très important, ne jamais travailler sur la version d’origine, qui doit rester en l’état si tout ne se passe pas comme prévu. Ensuite, on en vient à la partie la plus importante. J’ai du retâter un peu du --help, et prendre deux/trois messages d’erreur dans la gueule, puis, enfin, le Graal :
$ mysqld --skip-grant-tables --datadir=./datadir --socket ./mysqld.sock --pid-file=./mysqld.pid 2025-05-19 21:16:17 0 [Note] Starting MariaDB 10.11.11-MariaDB-ubu2204 source revision e69f8cae1a15e15b9e4f5e0f8497e1f17bdc81a4 server_uid KCkK/FgNE+mocr6SqlkAw7a5WoI= as process 52647 2025-05-19 21:16:17 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2025-05-19 21:16:17 0 [Note] InnoDB: Number of transaction pools: 1 2025-05-19 21:16:17 0 [Note] InnoDB: Using AVX512 instructions 2025-05-19 21:16:17 0 [Note] InnoDB: Using liburing 2025-05-19 21:16:17 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB 2025-05-19 21:16:17 0 [Note] InnoDB: Completed initialization of buffer pool 2025-05-19 21:16:17 0 [Note] InnoDB: File system buffers for log disabled (block size=4096 bytes) 2025-05-19 21:16:17 0 [Note] InnoDB: End of log at LSN=3957967525 2025-05-19 21:16:17 0 [Note] InnoDB: 128 rollback segments are active. 2025-05-19 21:16:17 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1" 2025-05-19 21:16:17 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ... 2025-05-19 21:16:17 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB. 2025-05-19 21:16:17 0 [Note] InnoDB: log sequence number 3957967525; transaction id 2439228 2025-05-19 21:16:17 0 [Note] InnoDB: Loading buffer pool(s) from /home/seboss666/git/git.seboss666.ovh/k3s_platform/kubernetes/databases/datadir/ib_buffer_pool 2025-05-19 21:16:17 0 [Note] Plugin 'FEEDBACK' is disabled. 2025-05-19 21:16:17 0 [Warning] You need to use --log-bin to make --expire-logs-days or --binlog-expire-logs-seconds work. 2025-05-19 21:16:17 0 [Note] Server socket created on IP: '127.0.0.1'. 2025-05-19 21:16:17 0 [Note] InnoDB: Buffer pool(s) load completed at 250519 21:16:17 2025-05-19 21:16:17 0 [Note] mysqld: ready for connections. Version: '10.11.11-MariaDB-ubu2204' socket: './mysqld.sock' port: 3306 mariadb.org binary distribution
Wouhou, désormais, on peut brancher un client sur le socket qu’on a indiqué et vérifier la présence des bases :
$ mysql -S ./datadir/mysqld.sock Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 3 Server version: 10.11.11-MariaDB-ubu2204 mariadb.org binary distribution Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> show databases; +--------------------+ | Database | +--------------------+ | freshrss | | gitea | | information_schema | | mariadb | | mysql | | performance_schema | | sys | +--------------------+ 7 rows in set (0.045 sec)
TADA !!!
On peut dès lors dumper les bases pour préparer l’importation dans la nouvelle instance, en spécifiant aussi le socket :
mysqldump -S ./datadir/mysqld.sock -Q -B --opt gitea > gitea.sql
Quelques dizaines de minutes plus tard passées sur Talos, les applis sont de nouveau disponible \o/
Prochaine étape: mettre en place des dumps et des sauvegardes « Kube »
J’ai déjà cette histoire de datadir, mais on l’a vu, en cas de restauration c’est assez contraignant et ça aurait pu être encore plus long si je n’avais pas déjà su comment procéder. Pire, on ne peut pas restaurer « en l’état » parce que les infos de l’instance déployée par l’opérateur sont perdues dans la bataille, ce qui oblige à tout réinstaller.
Il faut donc que je mette en place des dumps, l’opérateur va m’y aider, mais aussi la sauvegarde des manifestes Kubernetes et là on reparlera de Velero je pense. Les dumps, c’est une sécurité et la facilité de migration des bases, les manifestes permettent de rétablir l’instance dans l’état le plus proche de l’original, ce qui m’aurait évité les heures passées à tout refaire de zéro.
Donc oui, plus que jamais, faites des sauvegardes (et testez-les aussi, de temps en temps, c’est mieux)
