2020/11/18 : suppression des données de production

Sur pica01, la commande docker volume prune supprime la moitié des volumes en usage dans les conteneurs. C’est un bug, car cette commande n’est censé supprimer que les volumes qui ne sont pas montés dans des conteneurs allumés.

Il semblerait que ce bug concerne les démons Docker configurés avec l’option Live Restore ainsi que les conteneurs avec la politique de redémarrage unless-stopped, après le redémarrage du démon Docker sans que ces conteneurs n’aient été redémarrés. Le problème est signalé sur le dépôt Docker.

Les volumes supprimés sont :

etherpad-db-pg
plume_data
umap-caretech
umap-caretech-static
umap-db-caretech
doc
plume_db
school
umap-redis-caretech
deleted-pads-standard
plume_index
plume_first_launch
wiki-caretech-db
murmur-data
stiegler
weekpad-db
wiki-caretech
wiki-caretech-data

Pas le choix, il faut essayer de retrouver les données.

Pour Etherpad, on a des backups. La commande de restauration de backup ne fonctionne pas.

On trouve donc le dernier backup dans /DATA/BACKUP/etherpad. On relance Etherpad, ce qui va avoir pour effet de créer une base de donnée vide avec l’utilisateur configuré dans les secrets weekpad :

snippet.bash

$ cd /DATA/docker/dockerfiles/pica-etherpad/week
$ docker-compose up -d

On arrête le conteneur applicatif :

snippet.bash

$ docker-compose stop app

On va ensuite restaurer le backup avec une commande qui marche :

snippet.bash

$ docker cp /DATA/BACKUP/etherpad/2020.11.17.180001.dump etherpad_week_db:/tmp/
$ docker exec -it etherpad_week_db bash
# pg_restore -U weekpad -d weekpad -C -v /tmp/2020.11.17.180001.dump

Cette commande fonctionne si l’utilisateur et la base de données existent, ce qui est le cas si la base a été initialisée par Etherpad. On redémarre Etherpad :

snippet.bash

$ docker-compose start app

Le backup est restauré.

On régénère le contenu sur Scenari, on relance les conteneurs (ce qui a pour effet de re-créer les volumes), et on copie le contenu généré.

On a pas de backups logiques pour les données de Mumble (canaux, etc). On se rabat donc sur les backups des machines virtuelles. Problème : depuis le passage à Proxmox 6, les backups sont compressés au format ZSTD (et plus GZIP).

Or le script de synchronisation des backups entre Alice et Bob supprime tous les fichiers qui ne terminent pas par .vma.gz ou .log. C’est réglé à l’arrache : 1, 2.

On a qu’un backup datant du 12 octobre. Vu que les salons Mumble n’ont pas trop bougé depuis, on tente quand même de les récupérer.

La méthode utilisée jusqu'alors pour extraire un backup ne fonctionne pas. On restaure donc le backup sur une machine virtuelle (sur le stockage HDD) et on monte le disque virtuel QCOW2 dans un dossier. Une fois le disque monté, on trouve <MOUNT_POINT>/var/lib/docker/volumes/mumble_data et on copie les données dans /root sur l’hôte, par exemple.

Une fois qu’on a récupéré le volume, on se débrouille pour le transférer en SSH sur pica01. Ensuite, on recrée le volume à la main et on restaure les données :

snippet.bash

$ docker volume create mumble_data
$ sudo mv <TRANSFERT>/mumble_data/_data/* /var/lib/docker/volumes/mumble_data/_data/

On relance ensuite Mumble, et c’est bon :

snippet.bash

$ cd /DATA/docker/dockerfiles/pica-murmur
$ docker-compose up -d

On applique la même technique que pour Mumble. Problème, des modifications importantes ont été apportées depuis le 12 octobre.

On essaye donc de récupérer les fichiers supprimés avec testdisk. C’est un échec : normal, on aurait du commencer par là avant de faire le mariole à écrire des nouveaux trucs sur le disque.

La carte, c’est pas grave, mais le wiki, il faut essayer de retrouver les données.

Le conteneur tourne toujours, puisque le volume a été supprimé alors que le conteneur tournait. On se dit qu’il y a peut être un cache, ça vaut le coup de regarder :

snippet.bash

$ docker exec -it wiki-caretech bash
bash-5.0$ ls data/
cache    content  uploads

Le volume manquant était monté sur content. On voit un dossier cache. Il contient dans un format mis binaire mis ASCII le cache des pages. On le récupère depuis la VM :

snippet.bash

$ docker cp wiki-caretech:/wiki/data/cache ~

Et on redémarre le Wiki avec l’ancien contenu du 12 octobre restauré avec la même procédure que pour Mumble :

snippet.bash

$ cd /DATA/docker/caretech/wiki
$ docker-compose up -d

On peut ensuite faire les modifications à la main pour restaurer l’ancien contenu à partir des fichiers de cache.

Ça aurait pu être bien pire, typiquement sur pica02, où on aurait perdu beaucoup de données. L’erreur étant due à un bug, il faut tirer les conclusions suivantes :

• L’erreur peut venir de partout, humaine ou technique
• Le système de backups est foireux et on ne le monitore pas
• Les backups ne sont pas assez réguliers, et en cas de panne générale, on perd tout
• Les backups des VM sont difficiles à manipuler, nécessitant de décompresser et de restaurer ~200G de données

Il est donc urgent de :

• Externaliser les backups
• Fiabiliser les scripts ad-hoc pour éviter de perdre un mois de backups sans s’en rendre compte
• Faire automatiquement des backups des volumes Docker, indépendamment des backups des VM

Pour ce faire, on pourra :

• Demander à un membre s’il peut fournir temporairement un espace de stockage pour envoyer les backups (préférablement chiffrés)
• Voir ce qu’on peut faire avec Proxmox Backup Server (peut être sur le même espace) pour des backups incrémentaux
• Réfléchir à comment sauvegarder /var/lib/docker/volumes (un rsync ne paraît pas adapter et risque de ne pas être consistant)