alpinux.cedrica5l/alpinux-owni

Fork 0

Sauvegardes : une base sur six, une seule copie, et rien hors de la machine #1

New issue

Closed

opened 2026-09-27 09:00:01 +02:00 by Cédric A5L · 3 comments

Cédric A5L commented

2026-09-27 09:00:01 +02:00

Owner

Relevé sur owni le 27/09/2026. Il existe une sauvegarde — je m'attendais
à n'en trouver aucune — mais elle couvre une base sur six, n'en garde qu'une
copie, et ne quitte pas la machine.

Ce qui est sauvegardé

Base	Sauvegarde	Copies
`c1_messagerie_db`	daily	1
`c1dolibarr`	none	—
`c1gitea`	none	—
`c1alpid`	none	—
`c1_installparty`	none	—
`c1_evenements`	none	—

Dernier dump : /var/backup/web21/db_c1_messagerie_db_2026-09-27_00-33.sql.gz,
89 ko. Il fonctionne.

Côté fichiers, les 14 sites sont à backup_interval = none — admin, alpid,
alpinux.org, autoconfig, cloud, dolibarr, feedback, gitea, installparty,
messagerie, owni, portail, static, wiki.

Ce que contient /var/backup/ispconfig/ est récent (26/09) mais ne concerne
que la configuration d'ISPConfig lui-même, pas les sites ni les bases.

Les trois problèmes, par ordre de gravité

1. Dolibarr et Gitea ne sont pas sauvegardés. c1dolibarr tient le
fichier des adhérents de l'association — la source des imports de la
messagerie. c1gitea tient les dépôts de tous les projets. Ni l'un ni l'autre
n'a de copie.

2. Une seule copie conservée (backup_copies = 1), y compris pour la
messagerie. Une corruption remarquée deux jours plus tard n'est pas
récupérable : la sauvegarde saine a déjà été écrasée par la suivante. Le coût
d'en garder sept est de quelques centaines de kilo-octets.

3. Les sauvegardes restent sur la machine sauvegardée. /var/backup est
sur owni. Un disque perdu, une erreur d'hébergeur, et les données partent avec
leurs copies. C'est le cas qu'une sauvegarde est censée couvrir.

À décider

Activer la sauvegarde quotidienne sur toutes les bases, au minimum
Dolibarr et Gitea, depuis ISPConfig (Sites → Base de données → Sauvegarde).
Porter backup_copies à 7, voire 30 : ce sont des dumps compressés de
quelques dizaines de kilo-octets à quelques mégaoctets.
Décider d'une copie hors machine : un rsync nocturne vers un autre
hébergement, ou un poste allumé. Sans cela, les deux points précédents ne
protègent que des erreurs humaines, pas d'une panne.
Et, quelle que soit la solution : tester une restauration. Une sauvegarde
qu'on n'a jamais restaurée est une hypothèse, pas une garantie.

Pourquoi ce ticket ici

La question dépasse la messagerie : elle porte sur la machine et sur tous les
services qu'elle héberge. Elle est apparue en déployant la messagerie, où j'ai
pris une sauvegarde manuelle avant de migrer la base — geste qui n'aurait pas
dû être manuel.

Relevé sur owni le 27/09/2026. Il **existe** une sauvegarde — je m'attendais à n'en trouver aucune — mais elle couvre une base sur six, n'en garde qu'une copie, et ne quitte pas la machine. ## Ce qui est sauvegardé | Base | Sauvegarde | Copies | |---|---|---| | `c1_messagerie_db` | **daily** | **1** | | `c1dolibarr` | none | — | | `c1gitea` | none | — | | `c1alpid` | none | — | | `c1_installparty` | none | — | | `c1_evenements` | none | — | Dernier dump : `/var/backup/web21/db_c1_messagerie_db_2026-09-27_00-33.sql.gz`, 89 ko. Il fonctionne. Côté fichiers, **les 14 sites sont à `backup_interval = none`** — admin, alpid, alpinux.org, autoconfig, cloud, dolibarr, feedback, gitea, installparty, messagerie, owni, portail, static, wiki. Ce que contient `/var/backup/ispconfig/` est récent (26/09) mais ne concerne que la configuration d'ISPConfig lui-même, pas les sites ni les bases. ## Les trois problèmes, par ordre de gravité **1. Dolibarr et Gitea ne sont pas sauvegardés.** `c1dolibarr` tient le fichier des adhérents de l'association — la source des imports de la messagerie. `c1gitea` tient les dépôts de tous les projets. Ni l'un ni l'autre n'a de copie. **2. Une seule copie conservée** (`backup_copies = 1`), y compris pour la messagerie. Une corruption remarquée deux jours plus tard n'est pas récupérable : la sauvegarde saine a déjà été écrasée par la suivante. Le coût d'en garder sept est de quelques centaines de kilo-octets. **3. Les sauvegardes restent sur la machine sauvegardée.** `/var/backup` est sur owni. Un disque perdu, une erreur d'hébergeur, et les données partent avec leurs copies. C'est le cas qu'une sauvegarde est censée couvrir. ## À décider - Activer la sauvegarde quotidienne sur **toutes** les bases, au minimum Dolibarr et Gitea, depuis ISPConfig (*Sites → Base de données → Sauvegarde*). - Porter `backup_copies` à 7, voire 30 : ce sont des dumps compressés de quelques dizaines de kilo-octets à quelques mégaoctets. - Décider d'une **copie hors machine** : un `rsync` nocturne vers un autre hébergement, ou un poste allumé. Sans cela, les deux points précédents ne protègent que des erreurs humaines, pas d'une panne. - Et, quelle que soit la solution : **tester une restauration**. Une sauvegarde qu'on n'a jamais restaurée est une hypothèse, pas une garantie. ## Pourquoi ce ticket ici La question dépasse la messagerie : elle porte sur la machine et sur tous les services qu'elle héberge. Elle est apparue en déployant la messagerie, où j'ai pris une sauvegarde manuelle avant de migrer la base — geste qui n'aurait pas dû être manuel.

Cédric A5L commented

2026-09-27 09:01:34 +02:00

Author

Owner

admin.alpinux.org devrait avoir un aperçu de l'état de santé des sauvegardes. voir le projet alpinux.admin

Cédric A5L referenced this issue

2026-09-27 09:10:30 +02:00

Compléter le README : messagerie, relais SMTP sortant, bases, sauvegardes #2

Cédric A5L commented

2026-09-27 09:16:22 +02:00

Author

Owner

Les sept bases sont sauvegardées, et la restauration est documentée

Livré dans alpinux-infra (f815c4d) : scripts/sauvegarder-owni.sh et
docs/sauvegardes.md.

Le script est tiré depuis le poste, pas poussé depuis owni : une machine
compromise ne doit pas pouvoir atteindre les sauvegardes de ce qu'elle
héberge. Et il fait ses propres dumps plutôt que de reprendre /var/backup —
ISPConfig n'en produisait qu'un sur six.

Première exécution réelle, ce jour :

  c1_messagerie_db     ok    88K
  c1dolibarr           ok   280K
  c1gitea              ok   656K
  c1alpid              ok   184K
  c1_installparty      ok    68K
  c1_evenements        ok    16K
  dbispconfig          ok   236K

7 base(s) sauvegardée(s) sur 7, rétention 30 jours.

1,5 Mo pour tout. Dolibarr et Gitea, qui n'avaient aucune copie, en ont
une. Trente jours conservés au lieu d'une seule copie.

La restauration a été essayée, pas seulement écrite

La sauvegarde de c1_messagerie_db a été rechargée pour de vrai dans une
base séparée : 21 tables, 258 abonnés dont 238 actifs, 48 campagnes, 255
envois. Ce sont les chiffres de la production — le dump remonte.

docs/sauvegardes.md couvre les pièges qui coûtent cher :

le worker tourne chaque minute. Restaurer sans couper le cron, c'est lui
rendre une file d'envois déjà partis et réexpédier une campagne à 250
personnes ;
restaurer d'abord dans une base séparée, comparer les comptes, basculer
ensuite ;
arrêter Gitea et Keycloak avant de recharger leur base ;
/etc/cron.d/ : un nom contenant un point est ignoré en silence, d'où le
déplacement vers /root/ plutôt qu'un renommage.

Ce qui reste, et pourquoi le ticket reste ouvert

Mettre le cron en place sur le poste — une ligne, dans
docs/sauvegardes.md. Je ne l'ai pas installée moi-même : c'est votre
machine, et un cron qu'on n'a pas écrit soi-même s'oublie.
Le poste doit être allumé à 3 h 30. Sinon la nuit est sautée. Le
journal le dira, encore faut-il le regarder.
Données personnelles sur un poste de travail : 258 adresses et le
fichier des adhérents. Dossier en 700, fichiers en 600 — à compléter
par un chiffrement du disque si le portable sort.
La restauration sur owni même n'a pas été essayée : c'est la partie où
l'on peut casser quelque chose, et elle mérite un essai un jour de calme.
Reste à décider si l'on active malgré tout les sauvegardes ISPConfig des
cinq autres bases, pour avoir une copie locale en plus de celle du poste.

Les points 1 à 3 vous reviennent ; je peux traiter le 5 si vous le voulez.

## Les sept bases sont sauvegardées, et la restauration est documentée Livré dans **alpinux-infra** (`f815c4d`) : `scripts/sauvegarder-owni.sh` et `docs/sauvegardes.md`. Le script est **tiré depuis le poste**, pas poussé depuis owni : une machine compromise ne doit pas pouvoir atteindre les sauvegardes de ce qu'elle héberge. Et il fait ses propres dumps plutôt que de reprendre `/var/backup` — ISPConfig n'en produisait qu'un sur six. Première exécution réelle, ce jour : ``` c1_messagerie_db ok 88K c1dolibarr ok 280K c1gitea ok 656K c1alpid ok 184K c1_installparty ok 68K c1_evenements ok 16K dbispconfig ok 236K 7 base(s) sauvegardée(s) sur 7, rétention 30 jours. ``` **1,5 Mo pour tout.** Dolibarr et Gitea, qui n'avaient aucune copie, en ont une. Trente jours conservés au lieu d'une seule copie. ## La restauration a été essayée, pas seulement écrite La sauvegarde de `c1_messagerie_db` a été **rechargée pour de vrai** dans une base séparée : 21 tables, 258 abonnés dont 238 actifs, 48 campagnes, 255 envois. Ce sont les chiffres de la production — le dump remonte. `docs/sauvegardes.md` couvre les pièges qui coûtent cher : - **le worker tourne chaque minute.** Restaurer sans couper le cron, c'est lui rendre une file d'envois déjà partis et **réexpédier une campagne à 250 personnes** ; - restaurer d'abord dans une base séparée, comparer les comptes, basculer ensuite ; - arrêter Gitea et Keycloak avant de recharger leur base ; - `/etc/cron.d/` : un nom contenant un point est ignoré en silence, d'où le déplacement vers `/root/` plutôt qu'un renommage. ## Ce qui reste, et pourquoi le ticket reste ouvert 1. **Mettre le cron en place** sur le poste — une ligne, dans `docs/sauvegardes.md`. Je ne l'ai pas installée moi-même : c'est votre machine, et un cron qu'on n'a pas écrit soi-même s'oublie. 2. **Le poste doit être allumé à 3 h 30.** Sinon la nuit est sautée. Le journal le dira, encore faut-il le regarder. 3. **Données personnelles sur un poste de travail** : 258 adresses et le fichier des adhérents. Dossier en `700`, fichiers en `600` — à compléter par un chiffrement du disque si le portable sort. 4. **La restauration sur owni même** n'a pas été essayée : c'est la partie où l'on peut casser quelque chose, et elle mérite un essai un jour de calme. 5. Reste à décider si l'on active malgré tout les sauvegardes ISPConfig des cinq autres bases, pour avoir une copie locale en plus de celle du poste. Les points 1 à 3 vous reviennent ; je peux traiter le 5 si vous le voulez.

Cédric A5L commented

2026-09-27 09:43:15 +02:00

Author

Owner

Fermé : outillé, documenté, versionné

Le script et la procédure sont dans alpinux-infra (f815c4d) —
scripts/sauvegarder-owni.sh et docs/sauvegardes.md. Les sept bases se
sauvegardent, la restauration est écrite pas à pas, et elle a été essayée pour
de vrai sur la messagerie : 21 tables, 258 abonnés, 48 campagnes.

Ce qui reste est entre les mains de celui qui tient la machine, et c'est
assumé comme tel :

installer la ligne de cron sur le poste (elle est dans la doc) ;
allumer le poste à l'heure dite, ou lancer le script après une absence ;
protéger les fichiers : 258 adresses et le fichier des adhérents sur un
poste de travail, dossier en 700, à compléter par un disque chiffré si le
portable sort.

Deux essais restent à faire un jour de calme, et ils sont écrits dans la doc
plutôt que perdus ici : la restauration sur owni même, et le comportement
du cron dans la durée.

Reste ouverte, si l'envie vient, la question d'activer en plus les sauvegardes
ISPConfig des cinq autres bases — pour avoir une copie locale en plus de celle
du poste. Cela se fait en trois clics par base dans Sites → Base de données →
Sauvegarde, et n'a pas besoin de ce ticket pour vivre.

## Fermé : outillé, documenté, versionné Le script et la procédure sont dans **alpinux-infra** (`f815c4d`) — `scripts/sauvegarder-owni.sh` et `docs/sauvegardes.md`. Les sept bases se sauvegardent, la restauration est écrite pas à pas, et elle a été essayée pour de vrai sur la messagerie : 21 tables, 258 abonnés, 48 campagnes. Ce qui reste est entre les mains de celui qui tient la machine, et c'est assumé comme tel : - **installer la ligne de cron** sur le poste (elle est dans la doc) ; - **allumer le poste** à l'heure dite, ou lancer le script après une absence ; - **protéger les fichiers** : 258 adresses et le fichier des adhérents sur un poste de travail, dossier en `700`, à compléter par un disque chiffré si le portable sort. Deux essais restent à faire un jour de calme, et ils sont écrits dans la doc plutôt que perdus ici : la restauration **sur owni même**, et le comportement du cron dans la durée. Reste ouverte, si l'envie vient, la question d'activer en plus les sauvegardes ISPConfig des cinq autres bases — pour avoir une copie locale en plus de celle du poste. Cela se fait en trois clics par base dans *Sites → Base de données → Sauvegarde*, et n'a pas besoin de ce ticket pour vivre.

Cédric A5L closed this issue

2026-09-27 09:43:15 +02:00

Cédric A5L referenced this issue

2026-09-27 09:47:25 +02:00

/mnt/sauvegarde : 12 Go d'une copie de novembre 2025, sur le disque système #3