Restore drill forgejo doctor fails post-ADR-0031: [storage] app.ini written to hardcoded rootful path #222

Nytt ärende

Stängd

öppnade 2026-07-26 21:21:43 +00:00 av supernaut · 0 kommentarer

supernaut kommenterad

2026-07-26 21:21:43 +00:00

Ägare

Symptom

BackupDrillFailed still firing after #220. The restore drill now clears the restic restore (the #219/#220 lock fix works — restic check + restore both succeed), but fails at forgejo doctor with exit 1:

[restore] detected rootless (ADR 0031) volume layout
[restore] restored repo root -> /data/data/forgejo-repositories (APP_DATA_PATH /data/data)
/root/restore-on-scratch.sh: line 239: .../drill-forgejo-data/_data/gitea/conf/app.ini: No such file or directory
[drill] restore/forgejo-doctor FAILED on the drill VM (exit 1)

Root cause

restore-on-scratch.sh writes the drill's minimal app.ini to ${WORK_MP}/conf/app.ini (layout-aware: WORK_MP=${VOL_MP} rootless, ${VOL_MP}/gitea rootful — line 206-207). But the [storage] section (added for #188) is appended to a hardcoded rootful path ${VOL_MP}/gitea/conf/app.ini (line 239).

Since the ADR 0031 rootless cutover (#91), prod backups are the rootless layout (no gitea/ subdir — the volume root is the work dir) and [storage] is present (#188). Both conditions now hold, so the append targets a nonexistent file → the write fails → the doctor container can't start → exit 1.

A gap left by the ADR 0031 cutover: the drill's layout detection was added, but this one write path wasn't converted from the rootful ${VOL_MP}/gitea/conf to the layout-aware ${WORK_MP}/conf.

Fix

Line 239: append [storage] to ${WORK_MP}/conf/app.ini (the same file the main app.ini is written to on line 207), not the hardcoded ${VOL_MP}/gitea/conf/app.ini. One-liner.

Verified: the restic restore + restic check succeed (10.341 GiB restored in 8:29), DB restore is fine — the drill is otherwise healthy; this is purely the doctor's app.ini path.

Refs #91 (ADR 0031), #188.

## Symptom `BackupDrillFailed` still firing after #220. The restore drill now clears the restic restore (the #219/#220 lock fix works — `restic check` + restore both succeed), but fails at `forgejo doctor` with **exit 1**: ``` [restore] detected rootless (ADR 0031) volume layout [restore] restored repo root -> /data/data/forgejo-repositories (APP_DATA_PATH /data/data) /root/restore-on-scratch.sh: line 239: .../drill-forgejo-data/_data/gitea/conf/app.ini: No such file or directory [drill] restore/forgejo-doctor FAILED on the drill VM (exit 1) ``` ## Root cause `restore-on-scratch.sh` writes the drill's minimal app.ini to `${WORK_MP}/conf/app.ini` (layout-aware: `WORK_MP=${VOL_MP}` rootless, `${VOL_MP}/gitea` rootful — line 206-207). But the `[storage]` section (added for #188) is appended to a **hardcoded rootful path** `${VOL_MP}/gitea/conf/app.ini` (**line 239**). Since the ADR 0031 rootless cutover (#91), prod backups are the rootless layout (**no `gitea/` subdir** — the volume root is the work dir) **and** `[storage]` is present (#188). Both conditions now hold, so the append targets a nonexistent file → the write fails → the doctor container can't start → exit 1. A gap left by the ADR 0031 cutover: the drill's layout *detection* was added, but this one write path wasn't converted from the rootful `${VOL_MP}/gitea/conf` to the layout-aware `${WORK_MP}/conf`. ## Fix Line 239: append `[storage]` to `${WORK_MP}/conf/app.ini` (the same file the main app.ini is written to on line 207), not the hardcoded `${VOL_MP}/gitea/conf/app.ini`. One-liner. Verified: the restic restore + `restic check` succeed (10.341 GiB restored in 8:29), DB restore is fine — the drill is otherwise healthy; this is purely the doctor's app.ini path. Refs #91 (ADR 0031), #188.

supernaut lade till etiketterna

area/backups

area/infra

ready-for-implementation

type

bug

2026-07-26 21:22:24 +00:00

supernaut refererade till detta ärende från en incheckning

2026-07-26 21:22:50 +00:00

fix(backup-drill): write the drill [storage] app.ini to the layout-aware path (#222)

supernaut hänvisade till detta ärende från en ändringsförfrågan som kommer att stänga det

2026-07-26 21:22:52 +00:00