Stratégie de backup dédiée à Dolibarr (compta + documents = rétention légale 10 ans), indépendante du backup plateforme générique.
Le trou que ça ferme 🔴→🟢
Un audit du backup externe Longhorn a révélé que le volume documents erp n'avait JAMAIS été sauvegardé hors cluster (lastBackupAt=never) : son volume Longhorn est enrôlé dans le groupe default, mais le seul job (thrice-a-month-backup) a groups=[] → ne sert aucun groupe. /var/www/documents (PDF de factures, pièces fournisseurs, contrats, ECM) n'avait aucune copie offsite — seulement les réplicas in-cluster.
tar -czf de /var/www/documents (RWX, monté read-only)
erp/<env>/docs/<ts>.tar.gz
→ s3://arcodange-backup/erp/<env>/ (GCS S3-compat), puis rétention en escalier : quotidien 30j / mensuel 12m / annuel ~10 ans.
Sécurité (modèle sandbox-lifecycle.sh) : prod en lecture seule (dump+tar lisent ; les seules écritures vont au bucket) ; DB lue avec les creds dynamiques propres à l'env ; secret GCS copié transitoirement (base64, supprimé en sortie), jamais affiché ; script entier shippé en base64. Fix du bug aws-cli v2.23+ vs GCS (AWS_*_CHECKSUM_*=when_required).
Prouvé en live
Sandbox de bout en bout (dump+tar+upload+prune, objets vérifiés dans GCS, artefacts nettoyés).
Premier vrai backup de prod pris : erp/prod/db 1,2 Mo + erp/prod/docs12,5 Mo → le trou est fermé maintenant.
Suite (documentée)
Le CronJob récurrent (chart, ArgoCD) réutilisant backup-job.sh + une policy Vault erp dédiée pour ses propres creds S3 (au lieu d'emprunter le secret Longhorn) = PR2. En attendant, l'orchestrateur tourne à la demande dès aujourd'hui. Le trou Longhorn générique (groupe default orphelin) reste à corriger côté plateforme.
Stratégie de backup **dédiée à Dolibarr** (compta + documents = rétention légale 10 ans), indépendante du backup plateforme générique.
## Le trou que ça ferme 🔴→🟢
Un audit du backup externe Longhorn a révélé que **le volume documents erp n'avait JAMAIS été sauvegardé hors cluster** (`lastBackupAt=never`) : son volume Longhorn est enrôlé dans le groupe `default`, mais le seul job (`thrice-a-month-backup`) a `groups=[]` → ne sert aucun groupe. `/var/www/documents` (PDF de factures, pièces fournisseurs, contrats, ECM) n'avait aucune copie offsite — seulement les réplicas in-cluster.
## Ce que ça fait
`ops/backup/dolibarr-backup.sh` (orchestrateur) + `ops/backup/backup-job.sh` (logique conteneur, pilotée par env, source unique) :
| moitié | comment | clé |
|---|---|---|
| DB Postgres | `pg_dump -Fc` (restaurable) | `erp/<env>/db/<ts>.dump` |
| PVC documents | `tar -czf` de `/var/www/documents` (RWX, monté **read-only**) | `erp/<env>/docs/<ts>.tar.gz` |
→ `s3://arcodange-backup/erp/<env>/` (GCS S3-compat), puis **rétention en escalier** : quotidien 30j / mensuel 12m / annuel ~10 ans.
**Sécurité** (modèle `sandbox-lifecycle.sh`) : prod en **lecture seule** (dump+tar lisent ; les seules écritures vont au bucket) ; DB lue avec les creds dynamiques propres à l'env ; secret GCS copié **transitoirement** (base64, supprimé en sortie), jamais affiché ; script entier shippé en base64. Fix du bug aws-cli v2.23+ vs GCS (`AWS_*_CHECKSUM_*=when_required`).
## Prouvé en live
- Sandbox de bout en bout (dump+tar+upload+prune, objets vérifiés dans GCS, artefacts nettoyés).
- Rétention unit-testée (1100 quotidiens → 46 gardés).
- **Premier vrai backup de prod pris** : `erp/prod/db` 1,2 Mo + `erp/prod/docs` **12,5 Mo** → le trou est fermé **maintenant**.
## Suite (documentée)
Le CronJob récurrent (chart, ArgoCD) réutilisant `backup-job.sh` + une **policy Vault erp dédiée** pour ses propres creds S3 (au lieu d'emprunter le secret Longhorn) = PR2. En attendant, l'orchestrateur tourne à la demande dès aujourd'hui. Le trou Longhorn générique (groupe `default` orphelin) reste à corriger côté plateforme.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The accounting data + issued documents are legally retained 10 years and warrant a
backup dedicated to Dolibarr. An audit found the generic Longhorn external backup
NEVER covered the erp volume (its Longhorn volume sits in the orphaned `default`
recurring-job group; the only job has groups=[] → serves nothing; lastBackupAt=never).
So /var/www/documents (invoice PDFs, supplier pieces, contracts, ECM) had zero
offsite copy — only in-cluster replicas.
ops/backup/dolibarr-backup.sh (orchestrator) + ops/backup/backup-job.sh (in-container
logic, env-driven, single source of truth):
- pg_dump -Fc of the DB + tar of the documents PVC (RWX, read-only mount) ->
s3://arcodange-backup/erp/<env>/{db,docs}/<ts>, then tiered prune (daily 30d /
monthly 12m / yearly 10y).
- prod is READ-only (dump+tar read; writes go only to the backup bucket); the DB is
read with the env's own dynamic creds; the GCS HMAC secret is copied transiently
(base64, deleted on exit) and never printed; the whole script ships base64.
- fixes the aws-cli v2.23+ default-checksum incompatibility with GCS/S3-compat
(SignatureDoesNotMatch) via AWS_*_CHECKSUM_*=when_required.
Proven live: sandbox end-to-end (dump+tar+upload+prune, verified in GCS, cleaned up)
and retention logic unit-tested (1100 daily -> 46 kept). The FIRST real prod backup
was taken (erp/prod/db 1.2 MB + erp/prod/docs 12.5 MB) — closing the gap now.
Automation (recurring CronJob in the chart + a dedicated erp Vault policy for its
own S3 creds) is the documented next step; the orchestrator works today on demand.
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Stratégie de backup dédiée à Dolibarr (compta + documents = rétention légale 10 ans), indépendante du backup plateforme générique.
Le trou que ça ferme 🔴→🟢
Un audit du backup externe Longhorn a révélé que le volume documents erp n'avait JAMAIS été sauvegardé hors cluster (
lastBackupAt=never) : son volume Longhorn est enrôlé dans le groupedefault, mais le seul job (thrice-a-month-backup) agroups=[]→ ne sert aucun groupe./var/www/documents(PDF de factures, pièces fournisseurs, contrats, ECM) n'avait aucune copie offsite — seulement les réplicas in-cluster.Ce que ça fait
ops/backup/dolibarr-backup.sh(orchestrateur) +ops/backup/backup-job.sh(logique conteneur, pilotée par env, source unique) :pg_dump -Fc(restaurable)erp/<env>/db/<ts>.dumptar -czfde/var/www/documents(RWX, monté read-only)erp/<env>/docs/<ts>.tar.gz→
s3://arcodange-backup/erp/<env>/(GCS S3-compat), puis rétention en escalier : quotidien 30j / mensuel 12m / annuel ~10 ans.Sécurité (modèle
sandbox-lifecycle.sh) : prod en lecture seule (dump+tar lisent ; les seules écritures vont au bucket) ; DB lue avec les creds dynamiques propres à l'env ; secret GCS copié transitoirement (base64, supprimé en sortie), jamais affiché ; script entier shippé en base64. Fix du bug aws-cli v2.23+ vs GCS (AWS_*_CHECKSUM_*=when_required).Prouvé en live
erp/prod/db1,2 Mo +erp/prod/docs12,5 Mo → le trou est fermé maintenant.Suite (documentée)
Le CronJob récurrent (chart, ArgoCD) réutilisant
backup-job.sh+ une policy Vault erp dédiée pour ses propres creds S3 (au lieu d'emprunter le secret Longhorn) = PR2. En attendant, l'orchestrateur tourne à la demande dès aujourd'hui. Le trou Longhorn générique (groupedefaultorphelin) reste à corriger côté plateforme.🤖 Generated with Claude Code
The accounting data + issued documents are legally retained 10 years and warrant a backup dedicated to Dolibarr. An audit found the generic Longhorn external backup NEVER covered the erp volume (its Longhorn volume sits in the orphaned `default` recurring-job group; the only job has groups=[] → serves nothing; lastBackupAt=never). So /var/www/documents (invoice PDFs, supplier pieces, contracts, ECM) had zero offsite copy — only in-cluster replicas. ops/backup/dolibarr-backup.sh (orchestrator) + ops/backup/backup-job.sh (in-container logic, env-driven, single source of truth): - pg_dump -Fc of the DB + tar of the documents PVC (RWX, read-only mount) -> s3://arcodange-backup/erp/<env>/{db,docs}/<ts>, then tiered prune (daily 30d / monthly 12m / yearly 10y). - prod is READ-only (dump+tar read; writes go only to the backup bucket); the DB is read with the env's own dynamic creds; the GCS HMAC secret is copied transiently (base64, deleted on exit) and never printed; the whole script ships base64. - fixes the aws-cli v2.23+ default-checksum incompatibility with GCS/S3-compat (SignatureDoesNotMatch) via AWS_*_CHECKSUM_*=when_required. Proven live: sandbox end-to-end (dump+tar+upload+prune, verified in GCS, cleaned up) and retention logic unit-tested (1100 daily -> 46 kept). The FIRST real prod backup was taken (erp/prod/db 1.2 MB + erp/prod/docs 12.5 MB) — closing the gap now. Automation (recurring CronJob in the chart + a dedicated erp Vault policy for its own S3 creds) is the documented next step; the orchestrator works today on demand. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>