Jerrit Fritzsche
8e98cc7510
**Sicherungsart.** Bisher entschied der Executor allein: Liegt ein Elternbackup
vor, wird inkrementell gesichert. Jetzt waehlbar je Auftrag —
- `incremental` (Standard, bisheriges Verhalten),
- `always_full`, oder
- inkrementell **mit einem festen Volltag** ("immer freitags").
Migration 000014 mit drei CHECKs. Der dritte lehnt "immer voll" zusammen mit
einem Wochentag ab: Dann ist ohnehin jeder Lauf voll, und die Regel gehoert in
die Datenbank, weil im Code jede Stelle sie einhalten muesste — eine vergisst
es. Real geprueft: der Widerspruch wird abgewiesen.
Der Wochentag wird in der **Zeitzone des Zeitplans** bestimmt. Rechnete der
Server in UTC, bekaeme ein Betreiber in Berlin seine Vollsicherung am
Donnerstagabend und wunderte sich, warum sie freitags fehlt. Vier Tests, der
entscheidende durch Mutation als fangend bestaetigt.
Zur Einordnung, weil es leicht verwechselt wird: Der Platzbedarf steigt bei
"immer voll" **nicht** nennenswert — unveraenderte Bloecke werden dedupliziert
und liegen weiterhin nur einmal im Repository. Was steigt, ist die Laufzeit.
Steht so in der Maske.
**Aufnahme-Token zeigte "undefined".** Das Feld heisst `token`, nicht
`enrollment_token` — Letzteres ist der Name im *Anfrage*koerper der
Registrierung. Der dritte Formfehler dieser Art; alle konsumierten Endpunkte
sind jetzt gegen den laufenden Dienst abgeglichen.
**Der Aufnahmedialog** hat jetzt eine vollstaendige Anleitung fuer Linux und
Windows mit fertig ausgefuellten Befehlen — Serveradresse und Token eingesetzt,
je Schritt einzeln kopierbar. Eine Anleitung mit Platzhaltern fuehrt
zuverlaessig dazu, dass jemand `<token>` woertlich einsetzt und dann eine
Fehlermeldung sucht, die nichts mit seinem Problem zu tun hat. Dazu die beiden
Stolperstellen: `--state` will eine Datei, und der Agent braucht Schreibzugriff
aufs Repository. Beim Windows-Weg steht dabei, dass der Dienst nie auf echter
Hardware lief.
**update.sh ruestet die Wiederherstellungsflaeche nach** — anlegen und in
ReadWritePaths eintragen. Ein Schritt, den man von Hand ausfuehren muss, wird
uebersehen und faellt erst im Ernstfall auf.
84 Tests im Frontend, alle Go-Tests gruen, shellcheck sauber.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
49 lines
2.4 KiB
SQL
49 lines
2.4 KiB
SQL
-- Sicherungsart je Auftrag.
|
|
--
|
|
-- Bisher entschied der Executor allein: Liegt ein Elternbackup vor, wird
|
|
-- inkrementell gesichert. Das ist der richtige Standard — der Gewinn ist
|
|
-- Lesezeit, und die ist nach dem ersten Lauf der begrenzende Faktor.
|
|
--
|
|
-- Es gibt aber zwei Gruende, davon abzuweichen, und beide sind betrieblich:
|
|
--
|
|
-- 1. **Immer voll.** Wer sein Backup ausser Haus gibt oder auf einen
|
|
-- Datentraeger schreibt, der einzeln weggetragen wird, will nicht, dass
|
|
-- ein Wiederherstellungspunkt an einem frueheren haengt.
|
|
-- 2. **Wöchentlich voll.** Der uebliche Kompromiss: unter der Woche schnell,
|
|
-- am Wochenende einmal vollstaendig.
|
|
--
|
|
-- Hinweis zur Einordnung: Syncova-Manifeste sind **vollstaendig** (Phase 6).
|
|
-- Eine Zusatzsicherung traegt die Blockverweise des Elternbackups mit, ein
|
|
-- Restore liest genau ein Manifest, und das Loeschen eines alten Backups kann
|
|
-- ein neueres nicht beschaedigen. Der Unterschied liegt also in der Laufzeit,
|
|
-- nicht in der Wiederherstellbarkeit.
|
|
|
|
ALTER TABLE backup_jobs
|
|
-- 'incremental' = nach dem ersten Lauf inkrementell (Standard, bisheriges
|
|
-- Verhalten). 'always_full' = jeder Lauf liest die Quelle vollstaendig.
|
|
ADD COLUMN backup_mode TEXT NOT NULL DEFAULT 'incremental',
|
|
|
|
-- Wochentag, an dem zusaetzlich eine Vollsicherung erzwungen wird.
|
|
-- 0 = Sonntag … 6 = Samstag, NULL = keiner. Gerechnet in der Zeitzone des
|
|
-- Zeitplans; ohne Angabe in UTC — sonst liefe derselbe Auftrag auf zwei
|
|
-- Servern an verschiedenen Tagen voll.
|
|
ADD COLUMN full_backup_weekday SMALLINT;
|
|
|
|
ALTER TABLE backup_jobs
|
|
ADD CONSTRAINT backup_jobs_backup_mode_valid
|
|
CHECK (backup_mode IN ('incremental', 'always_full')),
|
|
|
|
ADD CONSTRAINT backup_jobs_full_backup_weekday_valid
|
|
CHECK (full_backup_weekday IS NULL OR full_backup_weekday BETWEEN 0 AND 6),
|
|
|
|
-- Ein Wochentag bei 'always_full' ist widersprüchlich: Dann ist ohnehin
|
|
-- jeder Lauf voll. Die Regel steht in der Datenbank, weil im Code jede
|
|
-- Stelle sie einhalten muesste — und eine vergisst es.
|
|
ADD CONSTRAINT backup_jobs_full_weekday_only_incremental
|
|
CHECK (backup_mode = 'incremental' OR full_backup_weekday IS NULL);
|
|
|
|
COMMENT ON COLUMN backup_jobs.backup_mode IS
|
|
'incremental = nach dem ersten Lauf inkrementell; always_full = jeder Lauf vollstaendig';
|
|
COMMENT ON COLUMN backup_jobs.full_backup_weekday IS
|
|
'Wochentag einer erzwungenen Vollsicherung (0=Sonntag), NULL = keiner';
|