Řeší tři provozní situace: (1) sjednocení více bkup_data root větví do jedné po incidentu s různými HOST_DB_BKUP_ROOT hodnotami, (2) standardní konfigurace remote S3-compatible objektového úložiště (Contabo) pro restic, (3) formální rozhodnutí o odložení shardingu až do vzniku jasných provozních signálů.
V provozu vznikly tři nezávislé situace vyžadující rozhodnutí:
1. Multi-root incident
Backup běžel střídavě nad různými HOST_DB_BKUP_ROOT cestami na stejném hostu. To vedlo k:
více machine_name_uniq větvím v bkup_data — nejasné které jsou aktivní
složitá diagnostika: historické I/O chyby na starých cestách
nejasné chování restic post-hook a local prune (který root je aktivní?)
2. Remote objektové úložiště
Lokální restic repozitář na VM disku nemá off-site ochranu. Potřebujeme standardizovaný způsob napojení na S3-compatible storage (Contabo Object Storage) pro terciární zálohu.
3. Sharding
Při škálování na velký počet DB nebo VM může daily run trvat příliš dlouho. Otázka: kdy a jak zavést sharding zálohovacích úloh?
Rozhodnutí
✓ Chosen: Tři separátní rozhodnutí: merge tool pro multi-root, S3 env konfigurace, sharding odložen
1. Multi-root merge
Standardní cesta pro sjednocení rootů:
scripts/merge-db-bkup-roots.sh --apply --force
Sjednotí data pod cílový machine_name_uniq
Stará větev se archivuje mimo aktivní bkup_data (ne smazána)
Po mergi: pouze jeden aktivní HOST_DB_BKUP_ROOT — vynuceno konfigurací
2. Remote Object Storage (Contabo S3)
Konfigurace přes backup.env:
RESTIC_REPOSITORY=s3:https://<endpoint>/<bucket>/<prefix>
AWS_ACCESS_KEY_ID=<key>
AWS_SECRET_ACCESS_KEY=<secret>
AWS_DEFAULT_REGION=<region>
RESTIC_PASSWORD_FILE=/run/secrets/restic-password # beze změny
Provozní runbook:
1. Aktualizovat backup.env, restart kontejneru
2. Smoke test: restic snapshots, spustit restic-posthook, ověřit nový snapshot
3. Rollback: vrátit RESTIC_REPOSITORY=/data/restic-repo, odstranit AWS_*, restart
Nástroj scripts/restic-contabo.sh poskytuje wrapper pro init, backup, copy, forget, check operace.
3. Sharding — vědomě odloženo
Sharding se nyní nezavádí. Je to vědomé rozhodnutí (placeholder) — zavést až při vzniku jasných provozních signálů:
délka full daily běhu překročí akceptovatelný limit
počet dump souborů per machine subtree způsobuje výkonnostní problémy
opakované I/O chyby po cleanupu a sjednocení rootu
Důsledky
Pozitivní:
Jasný recovery postup po multi-root incidentu — bez ručního mazání nebo přesunování souborů
Konzistentní způsob napojení na Contabo/S3 backend bez změny core pipeline
Menší riziko dalšího rozdělování dat — jeden aktivní root je pravidlem
Sharding odložen vědomě: systém je jednodušší dokud není potřeba
Negativní:
Historické záznamy mohou dočasně obsahovat chyby odkazující na archivované/neexistující cesty
S3 backend přidává závislost na síti a správné správě přístupových klíčů
Bez shardingu může daily run při velkém počtu DB trvat déle — sledovat provozní metriky
Follow-up (TBD):
Definovat konkrétní provozní thresholdy pro sharding rozhodnutí (délka běhu, počet souborů, I/O error rate)
Připravit návrh shard strategie: per source (brew_pg_local, docker_*) nebo per DB skupina
Centralizovaná agregace reportu přes shard index — pro případ kdy jeden VM má více shardů
Changelog
Version
Date
Author
Note
1.0.0
2026-04-09
david.sorf + claude-sonnet-4-6
Migrace z doc/ADR/ADR-0010-multi-root-merge-object-storage-and-sharding-placeholder.md do DAK JSON formátu. Rozšířeno o kontext tří separátních situací, kompletní S3 konfiguraci a runbook, sharding thresholdy jako follow-up.