technique:incidents:incident-18-11-2020

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

technique:incidents:incident-18-11-2020 [2020/11/18 04:34] – créée qduchemitechnique:incidents:incident-18-11-2020 [2020/11/18 04:36] (Version actuelle) – qduchemi
Ligne 1: Ligne 1:
 +# 2020/11/18 : suppression des données de production
  
 +## Problème 
 +
 +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](https://github.com/moby/moby/issues/41686).
 +
 +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
 +```
 +
 +## Résolution
 +
 +Pas le choix, il faut essayer de retrouver les données.
 +
 +### Etherpad
 +
 +Pour Etherpad, on a des backups. La [commande de restauration de backup](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/blob/0ecd62ec903f50cae8546119a31d3ab2b6bec7b4/pica-db-backup/postgres-run.sh#L14) 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` :
 +
 +```bash
 +$ cd /DATA/docker/dockerfiles/pica-etherpad/week
 +$ docker-compose up -d
 +```
 +
 +On arrête le conteneur applicatif :
 +
 +```bash
 +$ docker-compose stop app
 +```
 +
 +On va ensuite restaurer le backup avec une commande qui marche :
 +
 +```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 :
 +
 +```bash
 +$ docker-compose start app
 +```
 +
 +Le backup est restauré.
 +
 +### Sites
 +
 +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é.
 +
 +### Mumble
 +
 +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).
 +
 +{{:technique:incidents:backup_proxmox_zst.png|}}
 +
 +Or le script de synchronisation des backups entre Alice et Bob [supprime tous les fichiers](https://gitlab.utc.fr/picasoft/projets/tx/rotation-vm/-/blob/eb2a56861d384ded8297cfd7065b614898532b46/hook_script.py#L69) qui ne terminent pas par `.vma.gz` ou `.log`. C'est réglé à l'arrache : [1](https://gitlab.utc.fr/picasoft/projets/tx/rotation-vm/-/commit/f1e4bfd2b19ec3004f14cb4c3a50462d431abcc5), [2](https://gitlab.utc.fr/picasoft/projets/tx/rotation-vm/-/commit/848449fa76238fd7d4471b98a5422aee5b9a2e90).
 +
 +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](https://wiki.picasoft.net/doku.php?id=technique:infrastructure:machines_virtuelles:backup#avec_un_script_tiers) 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](https://wiki.picasoft.net/doku.php?id=technique:infrastructure:machines_virtuelles:backup#en_restaurant_sur_une_nouvelle_machine_virtuelle). 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 :
 +
 +```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 :
 +
 +```bash
 +$ cd /DATA/docker/dockerfiles/pica-murmur
 +$ docker-compose up -d
 +```
 +
 +### Caretech
 +
 +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](https://itsfoss.com/recover-deleted-files-linux/).
 +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 :
 +
 +```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 :
 +
 +```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 :
 +
 +```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.
 +
 +## Conclusion
 +
 +Ç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)