Jerrit Fritzsche
610719c316
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>
45 lines
2.1 KiB
SQL
45 lines
2.1 KiB
SQL
-- Baseline-Migration der Syncova-Control-Plane-Datenbank.
|
|
--
|
|
-- Sie legt ausschließlich die Grundlagen, auf denen alle weiteren Migrationen
|
|
-- aufbauen. Fachliche Tabellen (Benutzer, Jobs, Repositories) folgen in den
|
|
-- Phasen 1 ff. des Implementierungsplans.
|
|
--
|
|
-- Regeln laut SYNCOVA_DATABASE.md §1:
|
|
-- - Öffentliche Bezeichner sind UUIDs.
|
|
-- - Alle Zeitstempel sind TIMESTAMPTZ in UTC.
|
|
-- - Backup-Nutzdaten werden niemals in PostgreSQL gespeichert.
|
|
|
|
-- pgcrypto liefert gen_random_uuid() für die Vergabe öffentlicher Bezeichner.
|
|
CREATE EXTENSION IF NOT EXISTS pgcrypto;
|
|
|
|
-- system_settings hält die Laufzeitkonfiguration der Control Plane.
|
|
--
|
|
-- Secrets gehören ausdrücklich nicht hierher: sie werden ausschließlich als
|
|
-- Referenz auf einen Secret Store abgelegt (PROMPT.md §12).
|
|
CREATE TABLE system_settings (
|
|
-- key ist der eindeutige Name der Einstellung, z. B. "retention.default_days".
|
|
key TEXT PRIMARY KEY,
|
|
-- value_json ist der Wert der Einstellung als JSON-Dokument.
|
|
value_json JSONB NOT NULL,
|
|
-- updated_at ist der Zeitpunkt der letzten Änderung in UTC.
|
|
updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
|
|
-- updated_by (Referenz auf users) ergänzt Phase 1 gemeinsam mit der Benutzertabelle.
|
|
);
|
|
|
|
COMMENT ON TABLE system_settings IS 'Laufzeitkonfiguration der Control Plane. Enthält niemals Secrets im Klartext.';
|
|
|
|
-- schema_baseline dokumentiert, mit welcher Programmversion ein Schema angelegt wurde.
|
|
--
|
|
-- Bei einem Disaster Recovery lässt sich damit feststellen, ob Datenbank und
|
|
-- Binary zusammenpassen (SYNCOVA_IMPLEMENTATION_PLAN.md Phase 18, Szenario B).
|
|
CREATE TABLE schema_baseline (
|
|
-- id ist der Primärschlüssel des Eintrags.
|
|
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
|
|
-- application_version ist die Programmversion, die diese Migration ausgeführt hat.
|
|
application_version TEXT NOT NULL,
|
|
-- applied_at ist der Zeitpunkt der Ausführung in UTC.
|
|
applied_at TIMESTAMPTZ NOT NULL DEFAULT now()
|
|
);
|
|
|
|
COMMENT ON TABLE schema_baseline IS 'Dokumentiert, mit welcher Programmversion das Schema initialisiert wurde.';
|