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>
42 lines
3.1 KiB
Plaintext
42 lines
3.1 KiB
Plaintext
# Eingefrorene Migrationen (Phase 22)
|
|
#
|
|
# SHA-256 je Datei. Eine bereits ausgelieferte Migration darf sich **nie wieder
|
|
# aendern**: Datenbanken, die sie angewandt haben, fuehren sie nicht erneut aus
|
|
# — golang-migrate merkt sich nur die Versionsnummer. Eine nachtraegliche
|
|
# Aenderung wirkt deshalb ausschliesslich auf neue Installationen, und das
|
|
# Ergebnis sind zwei Schemata mit derselben Versionsnummer.
|
|
#
|
|
# Wer etwas aendern will, schreibt eine neue Migration. Immer.
|
|
#
|
|
# Eine neue Migration gehoert hier eingetragen — ohne Eintrag ist sie ab morgen
|
|
# ungeschuetzt.
|
|
|
|
063c5580c95a9d3ed39d948eb20db282ae5962f4fd8f2a7d3b6931fb7db4793a 000010_ransomware_signals.down.sql
|
|
0c8614133b8cb96ce6c697a172f7005f36eef9d125d70da2efafb294df1be42b 000004_jobs.up.sql
|
|
0ff4909cb82fa15aa8f93fa26968b3f69f250c4a8c65b15f1478989272b7f0fb 000002_identity.down.sql
|
|
1191dea2c0c44bca55df61fa70796b83b500bea441ae509536f64b0613517335 000007_immutability.up.sql
|
|
3471e0b7d9b6f99535f953618a22bff0ddff09f872c0836c828fa288b3dbf190 000012_proxmox.up.sql
|
|
35b8a95ea767940e8c3432db078690c1625818151dd6139ca11f99a0917346e4 000013_repository_registration.up.sql
|
|
3b0ac41761dbe05a95f480133947fb3e9dcf9e0dc6be55853512224cf4e26b3b 000004_jobs.down.sql
|
|
4837e63360814a0efaaa79ada3010d11e2eee071e7e8f15b0c706ff245470529 000007_immutability.down.sql
|
|
5c6764cd534bc9adec748661867f3caff7dd6c5217636156a41f0e258ac28d7a 000013_repository_registration.down.sql
|
|
6338d09c9927bff2466ee232b231d8684280a404d52ae3ac14f4f1c28d7a4a44 000011_agent_tasks.up.sql
|
|
70cd755a9d2a665b13ce5c2a2c39c172cdf1f5eb6cd5576b7f262ef00e536356 000001_baseline.up.sql
|
|
83b96ec0b23f4426bcb07106744eb60388df9bd5c8aa4f51c5a555ec7d9071bc 000010_ransomware_signals.up.sql
|
|
8745ef733df98b15fa6448857cd04810143b0297c5e3352070a44800d86d201e 000005_restores.down.sql
|
|
9280818b8bff5ba817b8e197ed25fbbd24e7b703546618e9ab7870d7b64b814e 000008_metrics.up.sql
|
|
95d9658dff3cc6c39fe69e78b5d9087d1584c873892ad2813fbd79847eefe2cc 000006_verification.down.sql
|
|
961b678efd622e0b2a3f648fbe39b82005f3b97cc2c726be5248a06e24584160 000011_agent_tasks.down.sql
|
|
a4a4b4dbb9845bf8c65251696b3657fe1274032369bb4388102e2294f4cc9b85 000008_metrics.down.sql
|
|
a60bf47af8ddf822dedde8d85e1c9c36e2f877dfc2fc9a7b15c5968aa0676794 000003_agents.down.sql
|
|
bde06082ed39775f56ecd329f3a2dd7c24c2da344346160f5888781c9ca76578 000001_baseline.down.sql
|
|
c1c1ccf7800ade0bdd559b421019b69e456b0fea24862acf3d9206b6552e0f02 000012_proxmox.down.sql
|
|
ce1d702bc5e30cfeefc1a70ace1cec6c133af21592b635113aea3acda8db4a08 000009_alerts.down.sql
|
|
d5f1331274b86d0f2eeaef10ceef586b0d076cdfba449b9dcf1cab7d40eef2b9 000006_verification.up.sql
|
|
e559f3d4443b9057a3f40a685141d92f3e05817da725857d2f0cba231aef3035 000005_restores.up.sql
|
|
e6568d4614f3ebf5a66b75f2b8b3b0ee80786c04c6165216964395c7c1834db8 000009_alerts.up.sql
|
|
f38b3d5cd5a1d0143ce633feef4ad75334c702067a1c200f99f4cb791595ca40 000002_identity.up.sql
|
|
ffbd9245f8031c902f30a81cbaffcf9e61e515cc77ccaf9e885186e737cca3d0 000003_agents.up.sql
|
|
f25274d148996038f5716f315470c4f9371629ad734a03f0ee49ee760ea4c2d5 000014_backup_mode.up.sql
|
|
9a48a9de411d6af07461c236967525469c73d820a4d282fab8a61ed6eb56f9f3 000014_backup_mode.down.sql
|