Bisher wurde nur EINMAL gesichert: direkt vor einer Umstellung der
Datenbank. Faellt die Platte aus, ist alles weg -- die komplette
Betreuung, jede Aufgabe, jedes Protokoll. Das war das einzige Risiko im
System, das auf einen Schlag ALLES kostet.
Beim Nachsehen auf dem Server kam ein zweiter, schwerwiegenderer Befund
dazu:
workspace.db 4.096 B
workspace.db-wal 2.101.232 B
Im WAL-Betrieb landen Schreibvorgaenge zuerst im -wal und wandern erst
beim Checkpoint in die Hauptdatei. Der lief seit dem ersten Tag nicht.
Wer also workspace.db kopiert haette -- der naheliegendste Sicherungsweg
ueberhaupt -- haette eine LEERE Datenbank gesichert und es nicht gemerkt.
Der Test stellt genau das nach: aus der reinen Dateikopie waren 0 von 200
Aufgaben lesbar.
Deshalb:
- Nie eine Dateikopie. Immer VACUUM INTO -- SQLite schreibt selbst, liest
das WAL mit, Ergebnis ist in sich stimmig auch waehrend Schreibzugriffen.
- Vor jeder Sicherung ein erzwungener Checkpoint (TRUNCATE). Haelt die
Hauptdatei aktuell und das WAL klein.
- Jede frische Sicherung wird SOFORT wieder geoeffnet und geprueft: auf
Unversehrtheit UND darauf, dass Personen darin stehen -- gegen genau den
Fall einer technisch einwandfreien, aber leeren Datei. Faellt sie durch,
wird sie geloescht statt behalten.
- Erst unter Zwischennamen schreiben, dann pruefen, dann umbenennen. Sonst
stuende nach einem Abbruch eine halbe Datei unter dem richtigen Namen.
- Aufbewahrung 7 taeglich / 4 woechentlich / 6 monatlich, je Art getrennt
aufgeraeumt, damit taegliche nie die monatlichen verdraengen.
Laeuft IM Prozess, nicht als Systemdienst: keine Aenderung an Systemdateien
noetig, die Datenbank ist ohnehin offen, und es kommt mit jedem git pull
mit. Statt setTimeout auf 24 h wird viertelstuendlich geprueft, ob fuer
HEUTE schon eine liegt -- das ueberlebt Neustarts und Ausfaelle.
Dazu eine Zustandsansicht auf der Automationen-Seite: wann zuletzt, wie
gross, wie viele Personen darin, wie viel wartet noch im WAL, wie viel
Platz ist frei. Plus "Jetzt sichern" von Hand. Nur Leitung, 404 statt 403
fuer alle anderen.
Geprueft (server/pruef-sicherung.mjs, 27 Pruefungen) einschliesslich des
Ernstfalls: Sicherung schreiben, Datenbank zerstoeren, zurueckspielen,
Vollstaendigkeit und Schreibbarkeit nachweisen. Eine ungetestete Sicherung
ist eine Vermutung.
Co-Authored-By: Claude Opus 5 <[email protected]>
95 lines
3.6 KiB
HTML
95 lines
3.6 KiB
HTML
<!doctype html>
|
|
<html lang="de">
|
|
<head>
|
|
<meta charset="utf-8" />
|
|
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />
|
|
<title>Reports & Review · Creator Workspace</title>
|
|
<meta name="robots" content="noindex, nofollow" />
|
|
<meta name="theme-color" content="#05070d" />
|
|
<link rel="icon" href="assets/img/favicon.png" />
|
|
<link rel="stylesheet" href="assets/css/gate.css?v=202608311820" />
|
|
<link rel="stylesheet" href="assets/css/start.css?v=202608311820" />
|
|
<link rel="stylesheet" href="assets/css/aufgaben.css?v=202608311820" />
|
|
<link rel="stylesheet" href="assets/css/report.css?v=202608311820" />
|
|
</head>
|
|
|
|
<body class="start">
|
|
|
|
<header class="kopfleiste">
|
|
<button type="button" class="zurueck-knopf" id="zurueck" hidden>
|
|
<svg class="zurueck-knopf__pfeil" viewBox="0 0 24 24" aria-hidden="true">
|
|
<path d="M14.5 5.5 8 12l6.5 6.5" />
|
|
</svg>
|
|
<span class="zurueck-knopf__text">Zurück</span>
|
|
</button>
|
|
<p class="marke"><a class="zurueck" href="start.html">Creator Workspace</a> · Review</p>
|
|
<div class="kopfleiste__rechts">
|
|
<span class="wer" id="wer">…</span>
|
|
<button type="button" class="abmelden" id="abmelden">Abmelden</button>
|
|
</div>
|
|
</header>
|
|
|
|
<main class="inhalt inhalt--breit">
|
|
|
|
<section class="kopf-zeile">
|
|
<div>
|
|
<p class="marke">Reports</p>
|
|
<h1 class="titel">Review & nächste Schritte</h1>
|
|
<p class="unterzeile" id="unterzeile">Fortschritt wird nicht gefühlt, sondern nachvollziehbar gemacht.</p>
|
|
</div>
|
|
<div class="steuerung">
|
|
<div id="creator-block" hidden>
|
|
<label class="feld-schild" for="f-creator">Creator</label>
|
|
<select id="f-creator"></select>
|
|
</div>
|
|
<div>
|
|
<label class="feld-schild" for="f-tage">Zeitraum</label>
|
|
<select id="f-tage">
|
|
<option value="7">7 Tage</option>
|
|
<option value="30" selected>30 Tage</option>
|
|
<option value="90">90 Tage</option>
|
|
</select>
|
|
</div>
|
|
</div>
|
|
</section>
|
|
|
|
<p class="fehler" id="fehler" role="alert" aria-live="polite"></p>
|
|
|
|
<div id="bericht" aria-busy="true"><p class="leise">Report wird erstellt …</p></div>
|
|
|
|
<!-- Der Kern aus dem Konzept: Ein Review endet mit einer Entscheidung. -->
|
|
<section class="entscheidung" id="entscheidung-block" hidden>
|
|
<p class="marke">Abschluss</p>
|
|
<h2 class="entscheidung__titel">Was ist die Entscheidung?</h2>
|
|
<p class="entscheidung__text">
|
|
Ein Review endet nicht mit einer Zusammenfassung, sondern mit einem nächsten Schritt.
|
|
Was hier steht, wird sofort als Aufgabe mit hoher Priorität angelegt.
|
|
</p>
|
|
<form id="entscheidung">
|
|
<div class="entscheidung__raster">
|
|
<div>
|
|
<label class="feld-schild" for="e-titel">Nächster Schritt</label>
|
|
<input id="e-titel" maxlength="160" placeholder="z. B. Mikro-Problem bis Freitag lösen" required />
|
|
</div>
|
|
<div>
|
|
<label class="feld-schild" for="e-frist">Bis wann <span class="leise">(optional)</span></label>
|
|
<input id="e-frist" type="date" />
|
|
</div>
|
|
</div>
|
|
<p class="fehler" id="e-fehler" role="alert" aria-live="polite"></p>
|
|
<div class="neu__knoepfe">
|
|
<button type="submit" class="knopf knopf--klein" id="e-speichern">Als Aufgabe festhalten</button>
|
|
<span class="leise" id="e-stand"></span>
|
|
</div>
|
|
</form>
|
|
</section>
|
|
|
|
</main>
|
|
|
|
<script src="assets/js/ki.js?v=202608311820" defer></script>
|
|
<script src="assets/js/wahl.js?v=202608311820" defer></script>
|
|
<script src="assets/js/kopf.js?v=202608311820" defer></script>
|
|
<script src="assets/js/report.js?v=202608311820" defer></script>
|
|
</body>
|
|
</html>
|