# 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 `/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 /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)