sauvegarde les bases d'OpenStack et teste leur restauration chaque semaine
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
parent
7b0a8583eb
commit
b054888f5a
6 changed files with 136 additions and 5 deletions
|
|
@ -686,3 +686,33 @@ Dans une visio, l'image et le son ne sont que la partie visible : la sécurité
|
|||
**Comprendre**
|
||||
|
||||
Un accès « sudo sans mot de passe » est pratique pour automatiser, mais il transforme toute clé SSH du compte en clé root. Ici, c'est précisément la clé de Claude Code. Le garder pendant le bloc A est un compromis assumé, pas un oubli : il est écrit dans la dette avec sa date de fin et la commande de retrait.
|
||||
|
||||
## 2026-10-12 — Bloc A : sauvegarde des bases d'OpenStack
|
||||
|
||||
Adam lance la suite du bloc A **sans montée de version d'OpenStack** : la 2025.2 est stable et reste en place.
|
||||
|
||||
**Fait**
|
||||
|
||||
- La sauvegarde quotidienne exporte maintenant toutes les bases de Kolla (Keystone, Nova, Neutron, Glance, Heat, Placement, Grafana) avec `mariadb-dump --single-transaction` : ≈ 30 Mo, sans verrou ni redémarrage. Le mot de passe root de Kolla est lu dans `passwords.yml` et passé à `mariadb` par l'entrée standard (`--defaults-extra-file=/dev/stdin`) : jamais en argument, donc invisible dans `ps`.
|
||||
- Le test de restauration hebdomadaire restaure aussi `openstack.sql` dans un conteneur jetable `mariadb:11.4` (même version que Kolla) et compare : bases, nombre de tables, lignes des tables stables.
|
||||
- Procédure de sinistre OpenStack écrite dans `docs/runbooks/sauvegardes.md` (non jouée : il faudrait un second serveur).
|
||||
- Ligne retirée de `docs/dette.md`.
|
||||
|
||||
**Pourquoi pas `mariabackup`, l'outil de Kolla** : il faut activer `enable_mariabackup` puis relancer `reconfigure` sur MariaDB, qui porte tout OpenStack, pour obtenir une copie physique de 2,5 Go. Un export logique de 30 Mo entre dans l'archive chiffrée existante et se restaure dans n'importe quel MariaDB 11.4. Le prix : la restauration est plus lente qu'une copie physique, ce qui ne compte pas à cette taille.
|
||||
|
||||
**Critère vérifié**
|
||||
|
||||
```
|
||||
glance 16/16 grafana 113/113 heat 16/16 keystone 49/49 neutron 135/135
|
||||
nova 111/111 nova_api 32/32 nova_cell0 111/111 placement 13/13
|
||||
keystone.project : copie 7, production 7
|
||||
keystone.user : copie 8, production 8
|
||||
glance.images : copie 1, production 1
|
||||
nova_api.flavors : copie 1, production 1
|
||||
projet paillasse dans la copie : 1
|
||||
== RESTAURATION RÉUSSIE (quotidienne-20261012.tar.zst.age)
|
||||
```
|
||||
|
||||
**Comprendre**
|
||||
|
||||
Avant, perdre le serveur voulait dire recréer à la main projet, compte de service, gabarit, quotas et image. Les fichiers de configuration (`/etc/kolla`, mots de passe compris) étaient déjà dans l'archive ; il manquait l'état, qui vit dans la base. Les fichiers des images Glance restent hors sauvegarde : ils se reconstruisent par script, et les VM d'élèves sont jetables par nature.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue