fix(backup): dump-explosie voorkomen, detecteren en minder lang bewaren #132

Merged

janpeter merged 1 commit from fix/backup-dump-size-and-retention into main 2026-08-02 13:39:02 +02:00

Conversation 1 Commits 1 Files changed 1 +39 -3

janpeter commented 2026-08-02 13:26:27 +02:00

Owner

Copy link

De aanleiding

Tussen 2026-07-24 en 07-31 sprong de dagelijkse forgejo-dump van 0,2 naar 8,3 GB — acht dagen, ~64 GB. Oorzaak: zes container-images (video-editor-*) in Forgejo's package-registry, gepusht 07-23 12:29 t/m 07-25 02:06. 271 blobs, waarvan 24 lagen groter dan 100 MB (samen 7,34 GB). forgejo dump archiveert data/packages mee, dus elke dagelijkse dump sleepte ze opnieuw mee.

Ze zijn tussen de dumps van 07-31 en 08-01 verwijderd; de registry is nu leeg. Niemand merkte het, en het kwam twaalf dagen later bij toeval boven bij een backup-coverage-vraag.

Vier wijzigingen

#	wat	effect
1	--skip-package-data --skip-index --skip-repo-archives	voorkomt herhaling
2	groottewaarschuwing bij >2x de mediaan	detecteert de volgende
3	lokale dump-retentie 14 -> 3 dagen	~55 GB vrij, kleinere snapshots
4	restic keep-monthly 12 -> 3	pint een uitschieter niet een jaar vast

1 — voorkomen

De registry bevat build-artefacten die CI opnieuw maakt, geen autoritatieve staat. Index en repo-archives zijn regenereerbaar. Getest met de echte vlaggen:

exit 0, geldige zip, 242 MB
  121.6 MB  forgejo-db.sql
   82.6 MB  repos/janpeter
   27.9 MB  data/actions_log
(geen data/packages, geen data/repo-archive)

2 — detecteren

Retrospectief getoetst tegen de echte dumps:

24-07 (de sprong): 3.23 GB vs mediaan ervoor 0.23 GB  -> zou de EERSTE dag al hebben gewaarschuwd
28-07:             8.33 GB vs mediaan 0.55 GB          -> waarschuwing
vandaag:           0.23 GB vs mediaan 3.23 GB          -> geen waarschuwing

Bewust een waarschuwing en geen fout: de backup weigeren omdat de dump groot is offert de backup zelf op.

Beperking, expliciet: deze regel is alleen zichtbaar in het backup-log. PHASE_EXTRA bereikt het statusbestand niet omdat run_phase fasen in een subshell draait (( ... ) 2>&1 | tee) — bestaande bug, hier bewust niet meegefixt omdat die het status-contract en de hardcoded fase-lijst van het dashboard raakt.

3 — lokale retentie

Elke restic-snapshot bevat de dumps die op dat moment lokaal staan. De snapshot van 08-02 droeg nog acht 8GB-zips mee. Bij 3 dagen zakt de map van 64,2 naar 9,0 GB (en daarna naar ~0,7 GB zodra de zip van 31-07 verloopt).

4 — restic-retentie

--keep-daily 7 --keep-weekly 4 blijven staan: met lokaal op 3 dagen zijn de dagelijkse snapshots de primaire staart, en elke snapshot draagt 3 dagen dumps — dus elke dump van de afgelopen ~9 dagen is bereikbaar.

Alleen NAS. B2 heeft Object Lock (governance, 30 dagen) en de server-key heeft geen deleteFiles; prune draait daar maandelijks vanaf de laptop. Zonder dezelfde aanpassing daar lopen de policies uit elkaar.

Wat er vannacht gebeurt

De eerstvolgende run (03:36) maakt een dump zonder packages, snoeit lokaal naar 3 dagen (~55 GB vrij) en draait forget --prune met de nieuwe monthly. Die prune gaat over CIFS — reken op een tragere run dan normaal.

## De aanleiding Tussen **2026-07-24 en 07-31** sprong de dagelijkse forgejo-dump van 0,2 naar 8,3 GB — acht dagen, ~64 GB. Oorzaak: zes container-images (`video-editor-*`) in Forgejo's package-registry, gepusht 07-23 12:29 t/m 07-25 02:06. 271 blobs, waarvan 24 lagen groter dan 100 MB (samen 7,34 GB). `forgejo dump` archiveert `data/packages` mee, dus elke dagelijkse dump sleepte ze opnieuw mee. Ze zijn tussen de dumps van 07-31 en 08-01 verwijderd; de registry is nu leeg. **Niemand merkte het**, en het kwam twaalf dagen later bij toeval boven bij een backup-coverage-vraag. ## Vier wijzigingen | # | wat | effect | |---|---|---| | 1 | `--skip-package-data --skip-index --skip-repo-archives` | voorkomt herhaling | | 2 | groottewaarschuwing bij >2x de mediaan | detecteert de volgende | | 3 | lokale dump-retentie 14 -> 3 dagen | ~55 GB vrij, kleinere snapshots | | 4 | restic `keep-monthly` 12 -> 3 | pint een uitschieter niet een jaar vast | ### 1 — voorkomen De registry bevat build-artefacten die CI opnieuw maakt, geen autoritatieve staat. Index en repo-archives zijn regenereerbaar. Getest met de echte vlaggen: ``` exit 0, geldige zip, 242 MB 121.6 MB forgejo-db.sql 82.6 MB repos/janpeter 27.9 MB data/actions_log (geen data/packages, geen data/repo-archive) ``` ### 2 — detecteren Retrospectief getoetst tegen de echte dumps: ``` 24-07 (de sprong): 3.23 GB vs mediaan ervoor 0.23 GB -> zou de EERSTE dag al hebben gewaarschuwd 28-07: 8.33 GB vs mediaan 0.55 GB -> waarschuwing vandaag: 0.23 GB vs mediaan 3.23 GB -> geen waarschuwing ``` Bewust een waarschuwing en geen fout: de backup weigeren omdat de dump groot is offert de backup zelf op. **Beperking, expliciet:** deze regel is alleen zichtbaar in het backup-log. `PHASE_EXTRA` bereikt het statusbestand niet omdat `run_phase` fasen in een subshell draait (`( ... ) 2>&1 | tee`) — bestaande bug, hier bewust niet meegefixt omdat die het status-contract en de hardcoded fase-lijst van het dashboard raakt. ### 3 — lokale retentie Elke restic-snapshot bevat de dumps die op dat moment lokaal staan. De snapshot van 08-02 droeg nog **acht** 8GB-zips mee. Bij 3 dagen zakt de map van 64,2 naar 9,0 GB (en daarna naar ~0,7 GB zodra de zip van 31-07 verloopt). ### 4 — restic-retentie `--keep-daily 7 --keep-weekly 4` blijven staan: met lokaal op 3 dagen zijn de dagelijkse snapshots de primaire staart, en elke snapshot draagt 3 dagen dumps — dus elke dump van de afgelopen ~9 dagen is bereikbaar. **Alleen NAS.** B2 heeft Object Lock (governance, 30 dagen) en de server-key heeft geen `deleteFiles`; prune draait daar maandelijks vanaf de laptop. Zonder dezelfde aanpassing daar lopen de policies uit elkaar. ## Wat er vannacht gebeurt De eerstvolgende run (03:36) maakt een dump zonder packages, snoeit lokaal naar 3 dagen (~55 GB vrij) en draait `forget --prune` met de nieuwe monthly. Die prune gaat over CIFS — reken op een tragere run dan normaal.

janpeter added 1 commit 2026-08-02 13:26:27 +02:00

fix(backup): dump-explosie voorkomen, detecteren en minder lang bewaren ... c05e417f05

Tussen 2026-07-24 en 07-31 sprong de dagelijkse forgejo-dump van 0,2 naar 8,3 GB —
acht dagen, ~64 GB. Oorzaak: zes container-images (video-editor-*) in Forgejo's
package-registry, gepusht 07-23 12:29 t/m 07-25 02:06, 271 blobs waarvan 24 lagen
groter dan 100 MB. `forgejo dump` archiveert data/packages mee, dus elke dagelijkse
dump sleepte ze opnieuw mee. Ze zijn tussen 07-31 en 08-01 verwijderd; de registry is
nu leeg. Niemand merkte het, en het kwam twaalf dagen later bij toeval boven.

Vier wijzigingen, in volgorde van hoe fundamenteel ze zijn.

1. VOORKOMEN — `forgejo dump` krijgt --skip-package-data, --skip-index en
   --skip-repo-archives. De registry bevat build-artefacten die CI opnieuw maakt,
   geen autoritatieve staat; index en archives zijn regenereerbaar. Getest: exit 0,
   geldige zip, 242 MB, met repos + DB + actions_log en zonder packages.
   Overrulebaar via FORGEJO_DUMP_SKIP_FLAGS.

2. DETECTEREN — waarschuwing als een dump meer dan DUMP_SIZE_WARN_FACTOR (2) keer de
   mediaan van de aanwezige dumps is. Retrospectief getoetst: had op 24-07 al gevuurd
   (3,23 GB vs mediaan 0,23), en vuurt niet op de dump van vandaag (0,23 vs 3,23).
   Bewust een waarschuwing en geen fout: een backup weigeren omdat de dump groot is
   offert de backup zelf op, en dat is erger.

3. LOKALE RETENTIE 14 -> 3 dagen. Elke restic-snapshot bevat de dumps die op dat
   moment lokaal staan; de snapshot van 08-02 droeg nog acht 8GB-zips mee. Dit maakt
   ~55 GB vrij bij de eerstvolgende run en krimpt elke toekomstige snapshot. De
   dagelijkse snapshots (keep-daily 7) houden oudere dumps bereikbaar.

4. RESTIC keep-monthly 12 -> 3. Een pg_dump van negen maanden oud, tegen een schema
   dat sindsdien tientallen migraties verder is, is geen herstelbron. En het is de
   regel die zo'n uitschieter een jaar lang vastpint.

LET OP: dit raakt alleen de NAS-retentie. B2 heeft Object Lock en de server-key kan
niet verwijderen; prune draait daar maandelijks vanaf de laptop. Zonder dezelfde
aanpassing daar lopen de twee policies uit elkaar.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

s4m-codex-reviewer approved these changes 2026-08-02 13:31:03 +02:00

s4m-codex-reviewer left a comment

Copy link

APPROVED

Geen gekoppeld plan gevonden — beoordeeld op codekwaliteit + product-standaarden.

Findings

• Geen blokkerende of error-severity findings gevonden.

Review

De wijziging in deploy/server-backup/server-backup.sh is beperkt en operationeel coherent: lokale Forgejo-dumps worden korter bewaard, regenerabele Forgejo-data wordt standaard uit de dump gehouden met een duidelijke override, afwijkende dumpgroottes worden alleen gelogd als waarschuwing, en restic-retentie wordt minder zwaar gemaakt. Ik heb geen productdoc gevonden die hiermee conflicteert.

Let op als niet-blokkerend rest-risico: DUMP_SIZE_WARN_FACTOR wordt in bash-arithmetic gebruikt en verwacht dus een integerwaarde; dat past bij de bestaande env-configstijl, maar een ongeldige override kan de warning-check laten falen na het schrijven van de dump.

# APPROVED Geen gekoppeld plan gevonden — beoordeeld op codekwaliteit + product-standaarden. ## Findings - Geen blokkerende of error-severity findings gevonden. ## Review De wijziging in `deploy/server-backup/server-backup.sh` is beperkt en operationeel coherent: lokale Forgejo-dumps worden korter bewaard, regenerabele Forgejo-data wordt standaard uit de dump gehouden met een duidelijke override, afwijkende dumpgroottes worden alleen gelogd als waarschuwing, en restic-retentie wordt minder zwaar gemaakt. Ik heb geen productdoc gevonden die hiermee conflicteert. Let op als niet-blokkerend rest-risico: `DUMP_SIZE_WARN_FACTOR` wordt in bash-arithmetic gebruikt en verwacht dus een integerwaarde; dat past bij de bestaande env-configstijl, maar een ongeldige override kan de warning-check laten falen na het schrijven van de dump.

janpeter merged commit 89f44ed585 into main 2026-08-02 13:39:02 +02:00

janpeter referenced this pull request from a commit 2026-08-02 13:39:04 +02:00

Merge pull request 'fix(backup): dump-explosie voorkomen, detecteren en minder lang bewaren' (#132) from fix/backup-dump-size-and-retention into main

janpeter referenced this pull request from a commit 2026-08-04 07:47:22 +02:00

docs(audit): NAS-retentie in droogtest matcht keep-monthly 3 (PR #132)

Sign in to join this conversation.

Reviewers

No reviewers

s4m-codex-reviewer

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

janpeter/Ops-dashboard!132

No description provided.