syncova-backup/CHANGELOG.md
Jerrit Fritzsche 610719c316
Some checks failed
CI / Backend (Go) (push) Failing after 3m7s
CI / Frontend (React/TypeScript) (push) Successful in 37s
CI / Sicherheitsprüfungen (push) Successful in 44s
Syncova Backups V1
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>
2026-08-17 09:10:54 +02:00

3.7 KiB

Änderungen

V1 — 14. August 2026

Die erste Fassung. Sie sichert Dateisysteme unter Linux und Windows sowie Gäste eines Proxmox-VE-Verbunds, prüft die Wiederherstellbarkeit und weist sie nach.

Was sie kann

Sichern und Wiederherstellen. Inhaltsabhängige Blockfindung, Deduplizierung auch über verschlüsselte Bestände hinweg, zstd, AES-256-GCM, Streaming-Pipeline mit Gegendruck. Zusatzsicherungen tragen ein vollständiges Manifest — ein Restore liest genau eine Datei, es gibt keine Kette aufzulösen. Wiederherstellung mit Vorabprüfung, Prüfpunkt und Fortsetzung nach Abbruch.

Ein Repository, das ohne die Anlage auskommt. Inhaltsadressierte Blöcke, atomares Commit-Protokoll, Katalogaufbau allein aus den Manifesten. Fällt der Control-Server samt Datenbank aus, lässt sich beides aus dem Repository zurückholen.

Vertrauen wird nachgewiesen, nicht behauptet. Fünf Prüfarten bis zum tatsächlichen Wiederherstellungstest, eine Einstufung, die nur mit durchgeführtem Test auf recoverable steigt, und eine Bewertung, in die Unbekanntes niemals als gut eingeht.

Löschschutz mit gemessener Durchsetzungsstufe. Was das Betriebssystem nachweislich verhindert, wird gemeldet — nicht, was die Einstellung verspricht. Dazu Legal Hold, Fristverlängerung ohne Verkürzungsmöglichkeit und Aufbewahrungsregeln.

Oberfläche, Kennzahlen, Meldungen, Berichte, Security Center und eine Ransomware-Heuristik, die meldet und niemals selbst handelt.

Was sie ausdrücklich nicht kann

  • Kapazitätsprognose. Die Kennzahl erscheint mit Begründung statt mit einer Null.
  • Kopie an einen zweiten Ort (Backup Copy). Nicht umgesetzt; das Security Center führt den Bereich als ungeprüft und rechnet ihn nicht ein.
  • Changed Block Tracking bei Proxmox. Proxmox gibt geänderte Blöcke nicht über die REST-API heraus. Eine Zusatzsicherung eines Gasts spart deshalb Platz, aber keine Lesezeit.
  • Erweiterte Attribute, POSIX-ACLs und SELinux-Kontexte. Gehen bei einer Sicherung verloren.
  • Harte Verknüpfungen werden aufgelöst: Der Inhalt kommt vollständig zurück, die Verknüpfung nicht.
  • VMware, Hyper-V, Kubernetes, M365, Object Storage, Synthetic Full. Nicht Teil dieser Fassung.

Was gebaut, aber nicht auf echter Hardware gefahren wurde

Diese Punkte sind vollständig umgesetzt und gegen Nachbauten geprüft. Was fehlt, ist die Ausführung auf der jeweiligen Plattform — und bis dahin gelten sie nicht als freigegeben:

  • Der Windows-Dienst. Er übersetzt für Windows und ist vet-sauber, wurde aber nie geladen. Der Kommandozeilenweg und die gesamte Auftragsausführung sind plattformunabhängig nachgewiesen.
  • Die systemd-Einheit. Inhaltlich korrigiert, nie auf einem Linux-System geladen.
  • Proxmox. Entdecken, Sichern, Prüfen und bitgenaues Zurückschreiben laufen durch — gegen einen Nachbau der API. Ob eine wiederhergestellte Maschine startet, ist ungeprüft.
  • Der SSH-Zugriffsweg auf Proxmox-Knoten. Die Fingerabdruckprüfung ist getestet, eine echte Verbindung gab es nie.

Eingefrorene Verträge

Ab dieser Fassung sind API (102 Endpunkte), Migrationen, Backup-Format und Repository-Protokoll festgeschrieben. Jede Abweichung schlägt in einer Prüfung an; Einzelheiten in docs/release-candidate.md.

Bekannte Grenzen

  • Das Manifest liegt vollständig im Speicher — rund 200 Byte je Blockverweis, also etwa 1,5 GiB bei 10 TB Quelldaten.
  • Bei vielen kleinen Dateien begrenzt fsync den Durchsatz auf rund 100 Dateien je Sekunde. Das ist der Preis des Commit-Protokolls und kein Fehler.
  • Weitergeleitete IP-Header werden ignoriert; hinter einem Reverse Proxy steht im Auditprotokoll dessen Adresse.