Was seit rc1 dazukam und was daran eine Korrektur ist, nicht nur eine Ergaenzung
— PostgreSQL 15 statt 17 und die nicht existierende Umgebungsvariable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Drei Betriebsskripte fuer Linux, im Auslieferungspaket neben den Programmen.
setup.sh richtet eine Anlage vollstaendig ein: PostgreSQL auf Wunsch mit
(apt/dnf/yum/zypper/pacman), Dienstkonto, Verschluesselungsschluessel, Schema,
erster Administrator, gehaertetes Repository, gehaertete systemd-Einheit. Jeder
Schritt vermerkt, was er angelegt hat; bricht der Lauf ab, wird genau das
zurueckgebaut und nichts sonst. Eine bestehende Installation wird nicht
ueberschrieben — dafuer gibt es update.sh, und der Unterschied ist, dass ein
Update vorher sichert.
update.sh haelt die Reihenfolge ein, um die es geht: sichern, anhalten,
tauschen, migrieren, starten, pruefen. Kommt der Dienst danach nicht hoch, holt
es die vorige Fassung zurueck. Ohne pg_dump wird gar nicht erst begonnen — ohne
Sicherung gibt es nach einer misslungenen Migration keinen Weg zurueck.
Repository und Verschluesselungsschluessel bleiben unberuehrt.
uninstall.sh entfernt standardmaessig NUR Dienst und Programme. Datenbank,
Repository und Konfiguration bleiben liegen; jede dieser Loeschungen verlangt
ein woertlich getipptes Bestaetigungswort an einem Terminal. Ein
Deinstallationsskript, das nebenbei die Backups mitnimmt, vernichtet genau das,
wofuer jemand jahrelang Speicher bezahlt hat.
Gegen Debian 12 im Container gefahren — Installation, Anmeldung, Repository
eingetragen, Loeschschutz gemessen (advisory auf overlayfs, richtig), echter
Sicherungslauf, Update mit unveraendertem Bestand, beide Abbauarten.
Drei Fehler dabei gefunden und behoben, alle derselben Art:
- "tr </dev/urandom | head -c 32" und "psql | grep -q": Der frueh geschlossene
Pipe schickt dem Schreiber SIGPIPE, und mit "set -o pipefail" bricht das
Skript mitten in der Einrichtung ab, ohne erkennbaren Grund.
- update.sh las die laufende Fassung mit "grep -o" aus der Antwort von
/health/ready. Die enthaelt gar kein Versionsfeld; grep endet mit 1, und das
Skript nahm ein GELUNGENES Update wieder zurueck — wegen einer Zeile, die nur
der Ausgabe dient.
Dazu: SYNCOVA_ADMIN_PASSWORD stand in der Doku und existiert nicht — das
Passwort kommt ueber die Standardeingabe. Und "syncova-repo break-lock" fehlte
zwar nicht mehr, aber der Test auf die Uebereinstimmung der drei Skripte ist
neu: Drei Skripte, die sich ueber den Installationsort uneinig sind, ergeben
eine Anlage, die sich nicht mehr entfernen laesst.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Enterprise-Backup-, Recovery-, Verification-, Security- und
Monitoring-Plattform fuer Proxmox VE, Windows, Linux und Dateisysteme.
Der Leitsatz, der fast jede Entscheidung erklaert: Ein Backup gilt erst als
vertrauenswuerdig, wenn Integritaet geprueft und Wiederherstellbarkeit
nachgewiesen wurde. Deshalb steigt ein Wiederherstellungspunkt erst nach einem
tatsaechlich durchgefuehrten Restore-Test auf "recoverable", und Unbekanntes
geht in keine Bewertung als "gut" ein.
Umfang (Phasen 0-23):
- Repository Engine: inhaltsadressierte Bloecke, atomares Commit-Protokoll,
Katalogaufbau allein aus den Manifesten — ohne Datenbank
- Backup Engine: inhaltsabhaengiges Chunking, Deduplizierung trotz
Verschluesselung, zstd, AES-256-GCM, Streaming mit Gegendruck
- Agenten fuer Windows und Linux mit Auftragsabholung (Pull-Modell)
- Proxmox-Provider mit beiden Zugriffswegen auf die Sicherungsarchive
- Scheduler, Recovery Engine mit Pruefpunkt, Verification, Unveraenderlichkeit
- Weboberflaeche, Kennzahlen, Meldungen, Berichte, Security Center,
Ransomware-Heuristik (meldet, handelt nie)
- Disaster Recovery, Haertung, Leistungsmessung, Chaos Testing
- Eingefrorene Vertraege fuer API, Migrationen, Backup-Format und Repository
- Auslieferungspaket fuer linux/amd64, linux/arm64 und windows/amd64
Nicht enthalten und als solches gekennzeichnet: Kapazitaetsprognose, Backup
Copy, Changed Block Tracking bei Proxmox, erweiterte Attribute und ACLs.
Gebaut, aber nie auf echter Hardware gefahren: der Windows-Dienst, die
systemd-Einheit und der verpflichtende Proxmox-Meilenstein — ob eine
wiederhergestellte VM startet, ist ungeprueft. Einzelheiten in CHANGELOG.md
und docs/release-candidate.md.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
