Différences
Ci-dessous, les différences entre deux révisions de la page.
technique:incidents:incident-18-11-2020 [2020/11/18 04:34] – créée qduchemi | technique: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' | ||
+ | |||
+ | 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:// | ||
+ | |||
+ | On trouve donc le dernier backup dans `/ | ||
+ | On relance Etherpad, ce qui va avoir pour effet de créer une base de donnée vide avec l' | ||
+ | |||
+ | ```bash | ||
+ | $ cd / | ||
+ | $ 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 / | ||
+ | $ docker exec -it etherpad_week_db bash | ||
+ | # pg_restore -U weekpad -d weekpad -C -v / | ||
+ | ``` | ||
+ | |||
+ | Cette commande fonctionne si l' | ||
+ | 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). | ||
+ | |||
+ | {{: | ||
+ | |||
+ | Or le script de synchronisation des backups entre Alice et Bob [supprime tous les fichiers](https:// | ||
+ | |||
+ | 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' | ||
+ | |||
+ | 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 < | ||
+ | ``` | ||
+ | |||
+ | On relance ensuite Mumble, et c'est bon : | ||
+ | |||
+ | ```bash | ||
+ | $ cd / | ||
+ | $ 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:// | ||
+ | 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 | ||
+ | ``` | ||
+ | |||
+ | 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:/ | ||
+ | ``` | ||
+ | |||
+ | Et on redémarre le Wiki avec l' | ||
+ | |||
+ | ```bash | ||
+ | $ cd / | ||
+ | $ docker-compose up -d | ||
+ | ``` | ||
+ | |||
+ | On peut ensuite faire les modifications à la main pour restaurer l' | ||
+ | |||
+ | ## Conclusion | ||
+ | |||
+ | Ça aurait pu être bien pire, typiquement sur `pica02`, où on aurait perdu beaucoup de données. | ||
+ | L' | ||
+ | |||
+ | * L' | ||
+ | * 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 `/ |