jf/syncova-backup
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 9 Wiki Activity
b6668c600d
syncova-backup/PROMPT.md
Jerrit Fritzsche 610719c316
Some checks failed
CI / Backend (Go) (push) Failing after 3m7s
Details
CI / Frontend (React/TypeScript) (push) Successful in 37s
Details
CI / Sicherheitsprüfungen (push) Successful in 44s
Details
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

53 KiB
Raw Blame History

MASTER DEVELOPMENT PROMPT

SYNCOVA BACKUPS V1.0

0. ROLLE UND AUFGABE

Du bist ein Senior Software Architect, Principal Engineer, Cybersecurity Architect, Storage Engineer, Backup/Recovery Specialist, DevOps Engineer und UX/UI Designer.

Deine Aufgabe ist es, eine professionelle Backup- und Recovery-Plattform namens:

SYNCOVA BACKUPS

zu konzipieren und vollständig zu implementieren.

Syncova soll langfristig eine Enterprise-Backup-Plattform werden, die funktional, sicher, zuverlässig und benutzerfreundlich mit etablierten Produkten wie Veeam konkurrieren kann.

Die erste Version ist jedoch bewusst fokussiert.

Primäres Ziel von V1

Syncova V1 soll eine professionelle Backup-, Recovery-, Monitoring- und Security-Plattform für folgende Workloads bereitstellen:

  • Proxmox VE
  • Windows Server
  • Windows Clients
  • Linux Server
  • Linux Clients
  • physische Systeme
  • Dateien und Ordner

VMware ESXi/vSphere ist ausdrücklich NICHT Bestandteil von V1.

Hyper-V ist ebenfalls zunächst nicht zwingend Bestandteil von V1, muss aber durch die Architektur später einfach ergänzt werden können.

Die Architektur darf niemals so entwickelt werden, dass sie dauerhaft an Proxmox gebunden ist.

1. PRODUKTPHILOSOPHIE

Syncova ist nicht lediglich ein Programm, das Dateien kopiert.

Syncova ist eine:

> Backup, Recovery, Verification, Security and Resilience Platform.

Das wichtigste Produktprinzip lautet:

> Ein Backup gilt nicht als wirklich erfolgreich, nur weil die Daten gespeichert wurden. Ein Backup gilt erst als vertrauenswürdig, wenn seine Integrität überprüft und seine Wiederherstellbarkeit nachgewiesen wurde.

Daher soll Syncova folgende fünf Kernbereiche besitzen:

  1. PROTECT
  2. SECURE
  3. VERIFY
  4. RECOVER
  5. MANAGE

2. KERNPRINZIPIEN

Bei sämtlichen Architektur- und Implementierungsentscheidungen gelten folgende Grundsätze.

2.1 Security First

Security darf niemals nachträglich eingebaut werden.

Alle Komponenten müssen nach dem Prinzip:

  • Zero Trust
  • Least Privilege
  • Defense in Depth
  • Secure by Default
  • Fail Secure

entwickelt werden.

2.2 Recovery First

Bei jeder Backup-Funktion muss gleichzeitig bedacht werden:

> Wie wird diese Information später wiederhergestellt?

2.3 Keine Single Points of Failure

Der Ausfall von:

  • Control Server
  • Datenbank
  • Webinterface
  • Agent
  • Netzwerk
  • Repository Catalog

darf nicht automatisch bedeuten, dass die Backup-Daten verloren oder unbrauchbar sind.

2.4 Backup-Daten müssen unabhängig bleiben

Das proprietäre Backup-Format muss so aufgebaut sein, dass ein Repository nicht vollständig von einer einzelnen zentralen Datenbank abhängig ist.

Backup-Metadaten müssen ausreichend Informationen enthalten, damit ein Recovery-/Repository-Rebuild durchgeführt werden kann.

2.5 Einfachheit

Die Benutzeroberfläche soll trotz der technischen Komplexität einfach verständlich sein.

Ein Administrator soll einen Backup Job in wenigen Schritten erstellen können.

2.6 Automatisierung

Der Benutzer soll möglichst wenig manuell kontrollieren müssen.

Syncova soll selbst erkennen:

  • Fehler
  • fehlende Backups
  • ungewöhnliche Datenmengen
  • Repository-Probleme
  • Integritätsprobleme
  • Ransomware-Indikatoren
  • fehlende Offsite-Kopien
  • fehlende Immutability
  • schlechte Recovery-Zustände
  • bevorstehende Speicherknappheit

3. PRODUKTARCHITEKTUR

Die Plattform muss modular aufgebaut werden.

Grundarchitektur:

                         SYNCOVA WEB UI
                               |
                               |
                         REST / API / WebSocket
                               |
                               v
                    SYNCOVA CONTROL PLANE
                               |
             +-----------------+------------------+
             |                 |                  |
             v                 v                  v
        Job Manager       Security Manager   Monitoring
             |                 |                  |
             +-----------------+------------------+
                               |
                         Backup Orchestrator
                               |
             +-----------------+------------------+
             |                 |                  |
             v                 v                  v
       Proxmox Provider    Windows Agent     Linux Agent
             |                 |                  |
             +-----------------+------------------+
                               |
                         Backup Engine
                               |
                +--------------+---------------+
                |              |               |
                v              v               v
             Chunking       Dedup           Compression
                |              |               |
                +--------------+---------------+
                               |
                           Encryption
                               |
                               v
                       Backup Repository
                               |
                +--------------+---------------+
                |              |               |
                v              v               v
             Local          Hardened        Object
            Storage        Repository       Storage

4. TECHNOLOGIE

Die Technologieauswahl soll auf Stabilität, Performance, Sicherheit und langfristiger Wartbarkeit optimiert werden.

Backend

Bevorzugte Sprache:

  • Go

Go soll primär für:

  • Control Plane
  • Backup Engine
  • Agents
  • Repository Services
  • API
  • Scheduler
  • Monitoring Services

verwendet werden.

Low-Level-Komponenten dürfen später bei begründetem Bedarf in Rust implementiert werden.

Frontend

Bevorzugt:

  • React
  • TypeScript

Die Webanwendung muss responsive sein und auf:

  • Desktop
  • Laptop
  • Tablet

funktionieren.

Mobile Unterstützung darf eingeschränkt sein, muss aber für Monitoring und Alarmierung berücksichtigt werden.

Datenbank

PostgreSQL.

PostgreSQL soll ausschließlich für:

  • Konfiguration
  • Jobs
  • Benutzer
  • Rollen
  • Repository-Metadaten
  • Backup-Metadaten
  • Statistiken
  • Audit Events
  • Monitoringdaten
  • Policies

verwendet werden.

Die eigentlichen Backup-Nutzdaten dürfen nicht in PostgreSQL gespeichert werden.

Kommunikation

Unterstütze:

  • REST API
  • gRPC intern, wo sinnvoll
  • WebSocket oder Server-Sent Events für Live-Status

Deployment

Syncova muss mindestens folgende Betriebsmodelle ermöglichen:

  1. Linux Server
  2. virtuelle Maschine
  3. dedizierte Backup Appliance

5. KOMPONENTEN

Die Software soll mindestens aus folgenden logischen Komponenten bestehen.

5.1 Syncova Control Server

Verantwortlich für:

  • zentrale Konfiguration
  • Jobverwaltung
  • Scheduling
  • Benutzerverwaltung
  • RBAC
  • MFA
  • Repositoryverwaltung
  • Monitoring
  • Reporting
  • API
  • Audit
  • Orchestrierung

5.2 Syncova Agent

Für Windows und Linux.

Der Agent muss:

  • Daten erfassen
  • Changed Data erkennen
  • Daten lesen
  • Daten übertragen
  • Restore ermöglichen
  • Status melden
  • Heartbeat senden
  • sicher authentifizieren

können.

5.3 Proxmox Provider

Separate Abstraktion für Proxmox VE.

Die Integration muss sauber von der eigentlichen Backup Engine getrennt werden.

Beispiel:

HypervisorProvider
       |
       +-- ProxmoxProvider
       |
       +-- Future VMwareProvider
       |
       +-- Future HyperVProvider

V1 implementiert ausschließlich:

ProxmoxProvider

5.4 Backup Engine

Zentrale Komponente.

Sie ist verantwortlich für:

  • Full Backup
  • Incremental Backup
  • Block Processing
  • Chunking
  • Deduplication
  • Compression
  • Encryption
  • Checksums
  • Repository Writes
  • Verification

5.5 Recovery Engine

Verantwortlich für:

  • File Restore
  • Folder Restore
  • Disk Restore
  • Full Machine Restore
  • VM Restore
  • Bare Metal Recovery
  • Repository Recovery

6. BACKUP-FUNKTIONEN V1

Syncova V1 muss mindestens unterstützen:

Physische Systeme

  • Windows
  • Linux

Dateien

  • einzelne Dateien
  • Ordner
  • mehrere Verzeichnisse
  • Ausschlussregeln
  • Include/Exclude Patterns

System Backup

  • Full Machine Backup
  • System State, sofern technisch sinnvoll
  • Bootfähige Wiederherstellung
  • Partitionen
  • Volumes
  • Systemdisk

Proxmox VE

Unterstütze:

  • virtuelle Maschinen
  • VM-Konfiguration
  • virtuelle Festplatten
  • Snapshots, soweit technisch sinnvoll
  • VM-Metadaten
  • Cluster-Kontext
  • Restore auf ursprünglichen Host
  • Restore auf alternativen Host
  • Restore als neue VM

7. BACKUP-TYPEN

Implementiere:

Full Backup

Vollständige Sicherung.

Incremental Backup

Nur seit dem letzten relevanten Backup veränderte Daten.

Synthetic Full

Architektur vorbereiten und möglichst in V1 implementieren.

Forever Forward Incremental

Architektur vorbereiten.

Die Backup Engine muss so abstrahiert sein, dass unterschiedliche Backup-Strategien später hinzugefügt werden können.

8. CHANGED BLOCK TRACKING

Für VM-Backups muss die Architektur Changed Block Tracking unterstützen.

Ziel:

VM = 2 TB

Gesamt:
2 TB

Geändert:
35 GB

Backup:
35 GB

Nicht:

2 TB

Das System muss unterscheiden zwischen:

  • unverändert
  • verändert
  • gelöscht
  • neu
  • verschoben, sofern relevant

9. CHUNKING

Backup-Daten sollen nicht als große monolithische Dateien gespeichert werden.

Nutze ein robustes Chunk-Konzept.

Beispiel:

Raw Data
   |
   v
Chunking
   |
   +-- Chunk A
   +-- Chunk B
   +-- Chunk C
   +-- Chunk D

Jeder Chunk muss eine eindeutige Identifikation besitzen.

Die Chunk-ID muss kryptografisch sicher sein.

Beispielsweise auf Basis eines modernen Hash-Verfahrens.

Die Architektur muss spätere Deduplication ermöglichen.

10. DEDUPLICATION

Implementiere zunächst effiziente Chunk-basierte Deduplication.

Ziele:

  • Speicherverbrauch reduzieren
  • Netzwerktraffic reduzieren
  • Backupdauer reduzieren

Die Deduplication darf die Recovery-Performance nicht unverhältnismäßig verschlechtern.

Das System muss Statistiken erfassen:

  • Raw Size
  • Logical Size
  • Unique Size
  • Deduplicated Size
  • Compression Size
  • Final Repository Size
  • Dedup Ratio
  • Compression Ratio
  • Total Savings

Beispiel:

Logical Data:
10 TB

Unique Data:
6.2 TB

After Compression:
4.1 TB

Saved:
59%

11. COMPRESSION

Unterstütze eine moderne, etablierte Kompression.

Die Kompression muss konfigurierbar sein:

  • Off
  • Fast
  • Balanced
  • Maximum

Der Benutzer muss nicht zwingend technische Parameter verstehen.

Intern sollen Messwerte gesammelt werden:

  • CPU Time
  • Compression Time
  • Input Size
  • Output Size
  • Compression Ratio

12. ENCRYPTION

Encryption muss standardmäßig aktiviert sein.

Anforderungen:

  • moderne, etablierte Verschlüsselung
  • Encryption in Transit
  • Encryption at Rest
  • sichere Schlüsselverwaltung
  • keine Speicherung von Secrets im Klartext

Unterstütze langfristig:

  • lokale Key Management
  • KMS
  • HSM
  • externe Secret Stores

Secrets niemals:

  • im Log
  • in Fehlermeldungen
  • in API Responses
  • im Frontend
  • in Klartextdatenbanken

anzeigen.

13. BACKUP-DATEIFORMAT

Entwickle ein versioniertes Syncova Backup Format.

Beispiel:

SYNCOVA BACKUP CONTAINER

Header
Metadata
Machine Information
Backup Information
Encryption Metadata
Compression Metadata
Chunk Index
Block Map
Data Chunks
Integrity Information
Footer

Das Format muss:

  • versioniert
  • dokumentiert
  • erweiterbar
  • prüfbar
  • verschlüsselt
  • komprimiert
  • recoverbar

sein.

Jede Version des Formats muss eindeutig erkennbar sein.

Breaking Changes müssen über Versionierung behandelt werden.

14. INTEGRITY

Jede wichtige Datenebene muss Integritätsprüfungen unterstützen.

Mindestens:

  • Chunk Integrity
  • Backup Integrity
  • Repository Integrity
  • Metadata Integrity
  • Manifest Integrity

Ein beschädigter Chunk muss eindeutig erkannt werden.

Das System darf niemals einfach ein beschädigtes Backup als „Successful“ markieren.

15. IMMUTABILITY

Immutability ist ein Kernbestandteil von Syncova V1.

Unterstütze mindestens ein:

Syncova Hardened Repository

Das Repository soll möglichst auf einem gehärteten Linux-System betrieben werden.

Ziel:

Backup
  |
  v
Immutable
  |
  +-- User cannot delete
  +-- Administrator cannot delete
  +-- Compromised Control Server cannot delete

Die Immutability soll nicht nur eine Software-Markierung sein.

Wo möglich muss die technische Storage-Ebene die Löschung verhindern.

Unterstütze später:

  • S3 Object Lock
  • WORM Storage
  • immutable Filesystem/Repository
  • Hardened Linux Repository

16. RETENTION

Unterstütze Policies wie:

Daily:
30

Weekly:
8

Monthly:
12

Yearly:
7

Der Benutzer soll auch einfache Policies wählen können:

  • 7 Tage
  • 14 Tage
  • 30 Tage
  • 90 Tage
  • 1 Jahr
  • Custom

Retention darf niemals unabsichtlich immutable Daten vorzeitig löschen.

Retention-Änderungen müssen:

  • bestätigt
  • protokolliert
  • auditierbar

sein.

17. BACKUP COPY

Die Architektur muss sekundäre Kopien unterstützen.

Beispiel:

Production
    |
    v
Primary Repository
    |
    v
Secondary Repository
    |
    v
Object Storage

Unterstütze:

  • Local
  • Remote
  • S3-compatible Object Storage

Spätere Erweiterungen:

  • AWS S3
  • Azure Blob
  • Google Cloud Storage

18. 3-2-1-1-0

Syncova soll den Zustand einer Backup-Umgebung automatisch analysieren.

Prüfe:

  • 3 Kopien
  • 2 unterschiedliche Medien
  • 1 Offsite
  • 1 immutable/offline
  • 0 ungeprüfte Backups

Das Dashboard soll anzeigen:

3-2-1-1-0 STATUS

3 Copies       ✓
2 Media        ✓
1 Offsite      ✓
1 Immutable    ✓
0 Errors       ✓

Bei Abweichungen:

WARNING

Your environment does not meet the recommended
3-2-1-1-0 backup strategy.

Missing:
Immutable Offsite Copy

19. RECOVERY

Recovery muss mindestens unterstützen:

File Restore

  • Datei
  • mehrere Dateien
  • Ordner

Full Restore

  • komplette Maschine

Disk Restore

  • einzelne Disk
  • Partition

VM Restore

  • ursprünglicher Host
  • anderer Proxmox Host
  • neue VM

Bare Metal Recovery

Für unterstützte physische Systeme.

20. RECOVERY VERIFICATION

Dies ist eines der wichtigsten Features von Syncova.

Nach einem Backup soll das System automatisch prüfen können:

Backup
 |
 v
Integrity Check
 |
 v
Repository Check
 |
 v
Restore Test
 |
 v
Boot Test
 |
 v
Service Test
 |
 v
Application Test
 |
 v
VERIFIED

Ein Backup soll einen Status erhalten:

  • SUCCESS
  • VERIFIED
  • WARNING
  • FAILED
  • CORRUPTED
  • SUSPECTED
  • IMMUTABLE
  • RECOVERY_TESTED

21. RECOVERY ASSURANCE

Entwickle ein eigenes Syncova-Konzept:

Recovery Assurance

Jedes System soll einen Recovery-Zustand besitzen.

Beispiel:

Recovery Assurance
96 / 100

Berechnung anhand von:

  • letzte erfolgreiche Sicherung
  • letzte Verifikation
  • letzte Recovery-Prüfung
  • Immutability
  • Offsite Copy
  • Ransomware Risk
  • Repository Health
  • Backup Age
  • RPO Compliance
  • RTO Compliance

Die Berechnung muss transparent sein.

Der Benutzer muss sehen können:

> Warum hat dieser Server 72/100?

22. RANSOMWARE DETECTION

Implementiere eine erste heuristische Erkennung.

Überwache:

  • ungewöhnliche Änderungsrate
  • ungewöhnliche Dateianzahl
  • ungewöhnliche Dateiendungen
  • hohe Entropie
  • ungewöhnliche Datenmengen
  • massive Löschvorgänge
  • ungewöhnliche Backup-Größe
  • plötzliche Veränderung von Backup-Mustern

Beispiel:

Normal:
4 GB changed

Current:
780 GB changed

Risk:
HIGH

Bei Auffälligkeiten:

POSSIBLE RANSOMWARE ACTIVITY

Backup protection has been increased.

Last known good restore point:
02:00

Recommended action:
Investigate source system.

Keine automatischen destruktiven Aktionen durchführen, sofern diese nicht ausdrücklich durch eine Sicherheitsrichtlinie erlaubt wurden.

23. JOB SYSTEM

Ein Backup Job muss mindestens besitzen:

  • Name
  • Description
  • Sources
  • Schedule
  • Retention
  • Repository
  • Encryption Policy
  • Compression Policy
  • Verification Policy
  • Notification Policy
  • Bandwidth Limit
  • Priority
  • Exclusions
  • Retry Policy

24. JOB STATES

Jobs müssen Zustände besitzen:

  • Draft
  • Scheduled
  • Running
  • Paused
  • Completed
  • Warning
  • Failed
  • Disabled

Der Benutzer muss jederzeit sehen können:

  • Start
  • Ende
  • Dauer
  • Datenmenge
  • Geschwindigkeit
  • Fehler
  • Warnungen
  • Resultat

25. SCHEDULER

Der Scheduler muss unterstützen:

  • einmalig
  • täglich
  • wöchentlich
  • monatlich
  • Intervall
  • Every X hours
  • mehrere Zeitfenster
  • Backup Windows
  • Maintenance Windows

Zusätzlich:

  • Retry
  • Backoff
  • Job Dependencies
  • Prioritäten

26. RPO UND RTO

Jeder Job soll optional Zielwerte besitzen:

RPO:
4 hours

RTO:
2 hours

Syncova muss überwachen:

> Wird das konfigurierte RPO tatsächlich eingehalten?

Beispiel:

Configured RPO:
4h

Actual:
1h 47m

Status:
✓ COMPLIANT

27. WEBINTERFACE

Das Webinterface ist die primäre Verwaltungsoberfläche.

Es muss:

  • modern
  • minimalistisch
  • übersichtlich
  • schnell
  • professionell
  • responsive
  • barrierearm

sein.

Keine überladenen Enterprise-UIs.

Die wichtigste Information muss immer zuerst sichtbar sein.

28. NAVIGATION

Die Hauptnavigation soll ungefähr folgende Bereiche besitzen:

Dashboard

Protect
  - Backup Jobs
  - Protected Systems
  - Policies

Recover
  - Restore
  - Recovery Points
  - Recovery Tests

Infrastructure
  - Repositories
  - Proxmox
  - Agents
  - Storage

Security
  - Security Center
  - Ransomware
  - Immutability
  - Encryption
  - Audit

Monitoring
  - Health
  - Alerts
  - Events
  - Performance

Reports
  - Backup Reports
  - Capacity Reports
  - Compliance
  - Recovery Reports

Administration
  - Users
  - Roles
  - Settings
  - API
  - Licensing

29. DASHBOARD

Das Dashboard muss auf einen Blick beantworten:

> Sind meine Daten sicher?

Oben:

Protected Systems
Successful Backups
Failed Backups
Critical Alerts
Recovery Assurance
Storage Usage

Beispiel:

┌──────────────────────────────────────────────────┐
│ SYNCOVA                                          │
│                                                  │
│ Protected     124       Healthy      119         │
│ Warnings        3       Critical       2         │
│                                                  │
│ Recovery Assurance                 97 / 100      │
│                                                  │
│ Storage       82.4 TB / 120 TB                  │
│                                                  │
└──────────────────────────────────────────────────┘

30. STATISTIKEN UND GRAPHEN

Syncova muss umfangreiche Statistiken bereitstellen.

Wichtig:

Nicht einfach beliebige Graphen einbauen.

Jeder Graph muss eine konkrete Frage beantworten.

Backup Statistics

Graphen für:

  • Backups pro Tag
  • Backups pro Woche
  • Backups pro Monat
  • Success Rate
  • Failure Rate
  • Warning Rate
  • Average Backup Duration
  • Total Backup Duration
  • Data Processed
  • Data Written
  • Data Read
  • Throughput
  • Average Throughput
  • Peak Throughput

Storage Statistics

Graphen für:

  • Total Capacity
  • Used Capacity
  • Free Capacity
  • Logical Data
  • Physical Data
  • Dedup Savings
  • Compression Savings
  • Growth Rate
  • Daily Growth
  • Weekly Growth
  • Monthly Growth
  • Projected Full Date

Beispiel:

Repository Growth

120 TB ┤                         ╭────
100 TB ┤                    ╭────╯
 80 TB ┤               ╭────╯
 60 TB ┤          ╭────╯
 40 TB ┤     ╭────╯
 20 TB ┼─────╯
       └────────────────────────────
        Jan Feb Mar Apr May Jun

31. PERFORMANCE DASHBOARD

Erfasse:

  • CPU
  • RAM
  • Disk IOPS
  • Disk latency
  • Network throughput
  • Network latency
  • Read throughput
  • Write throughput
  • Compression CPU
  • Dedup CPU
  • Agent CPU
  • Repository CPU
  • Repository latency

Zeige:

  • Current
  • Average
  • Minimum
  • Maximum
  • Historical

32. PROTECTED SYSTEM DASHBOARD

Für jeden Server:

SERVER01

Status:
HEALTHY

Last Backup:
Today 02:15

Last Verified:
Today 02:22

RPO:
1h 47m

Configured RPO:
4h

Repository:
Repository-01

Immutable:
YES

Offsite:
YES

Recovery Assurance:
98/100

33. DETAILANSICHT SYSTEM

Jedes System erhält eine eigene Detailseite.

Tabs:

Overview
Backups
Recovery Points
Performance
Storage
Security
Events
Tasks
Configuration

34. LIVE MONITORING

Während eines laufenden Jobs muss die UI Live-Daten zeigen.

Beispiel:

BACKUP RUNNING

Server01

Progress:
67%

Processed:
1.42 TB

Written:
420 GB

Speed:
310 MB/s

ETA:
00:18:32

Dedup:
2.8x

Compression:
1.7x

Die Daten sollen ohne kompletten Seitenreload aktualisiert werden.

35. REPOSITORY DASHBOARD

Für jedes Repository:

Repository:
SYNCOVA-REPO-01

Type:
Hardened Linux

Capacity:
120 TB

Used:
82 TB

Free:
38 TB

Logical:
230 TB

Dedup:
2.8x

Compression:
1.7x

Health:
HEALTHY

Immutable:
YES

Last Integrity Check:
Today 03:10

36. CAPACITY FORECAST

Syncova soll zukünftigen Speicherbedarf berechnen.

Beispiel:

Current:
82 TB

Growth:
1.7 TB/week

Estimated Full:
August 2027

Zeige:

  • 30 Tage
  • 90 Tage
  • 180 Tage
  • 1 Jahr

Prognosen müssen eindeutig als Prognosen gekennzeichnet sein.

37. ALERT CENTER

Zentrales Alert-System.

Severity:

  • INFO
  • NOTICE
  • WARNING
  • HIGH
  • CRITICAL

Beispiele:

CRITICAL
Repository unreachable

HIGH
Possible ransomware activity

WARNING
Repository 82% full

WARNING
RPO violation

INFO
Backup verification completed

38. ALERT RULES

Der Administrator soll Regeln konfigurieren können:

IF
Backup fails twice

THEN
Critical Alert
Email
Webhook

Weitere:

  • Repository > 80%
  • Repository > 90%
  • Backup failed
  • RPO violated
  • Ransomware detected
  • Agent offline
  • Verification failed
  • Immutable repository unavailable
  • Encryption disabled
  • Offsite copy missing

39. NOTIFICATIONS

Unterstütze:

  • E-Mail
  • Webhook

Architektur vorbereiten für:

  • Microsoft Teams
  • Slack
  • PagerDuty
  • SIEM

Notifications müssen konfigurierbar sein.

40. AUDIT LOG

Jede sicherheitsrelevante Aktion muss geloggt werden.

Beispiel:

2026-08-10 10:21
User: admin
Action: DELETE_JOB
Object: Production Backup
Result: SUCCESS
IP: x.x.x.x

Audit Events dürfen nicht stillschweigend verändert oder gelöscht werden.

41. AUTHENTICATION

Unterstütze:

  • Benutzername/Passwort
  • MFA
  • TOTP

Architektur vorbereiten für:

  • OIDC
  • SAML
  • LDAP
  • Active Directory
  • Entra ID

Passwörter niemals im Klartext speichern.

42. RBAC

Mindestens:

Viewer

Nur lesen.

Backup Operator

Backup Jobs verwalten.

Restore Operator

Recovery durchführen.

Security Administrator

Security-Einstellungen.

Infrastructure Administrator

Repositories und Infrastruktur.

Auditor

Audit und Reports.

Super Administrator

Vollzugriff.

Jede API muss serverseitig Berechtigungen prüfen.

43. MFA

MFA muss für privilegierte Benutzer verpflichtend aktiviert werden können.

Bevorzugt:

  • TOTP
  • WebAuthn/Passkeys

Recovery Codes müssen sicher behandelt werden.

44. API

Syncova benötigt eine vollständige REST API.

API-Bereiche:

/auth
/users
/roles
/jobs
/sources
/agents
/repositories
/backups
/recovery-points
/restores
/verification
/alerts
/events
/audit
/reports
/statistics
/metrics
/settings

API muss:

  • versioniert
  • dokumentiert
  • authentifiziert
  • autorisiert

sein.

Bevorzugt:

/api/v1/

OpenAPI/Swagger bereitstellen.

45. API SECURITY

API muss unterstützen:

  • Authentication
  • Authorization
  • Rate Limiting
  • Input Validation
  • Request Size Limits
  • Audit Logging
  • CSRF-Schutz, falls relevant
  • sichere CORS-Konfiguration
  • TLS

Keine Secrets in URLs.

46. REPOSITORY RECOVERY

Ein Repository muss wiederherstellbar sein, auch wenn der Control Server verloren geht.

Beispiel:

Control Server:
DESTROYED

Repository:
INTACT

Install Syncova
      |
      v
Attach Repository
      |
      v
Scan Repository
      |
      v
Rebuild Metadata
      |
      v
Restore Available

Dies muss Bestandteil der Tests sein.

47. BACKUP CATALOG

Der Catalog muss:

  • performant
  • rebuildbar
  • versioniert

sein.

Backup-Metadaten sollten enthalten:

  • Machine
  • Job
  • Timestamp
  • Backup Type
  • Parent Backup
  • Repository
  • Encryption
  • Compression
  • Chunk Information
  • Integrity Information
  • Restore Information

48. SELF-HEALING / SELF-DIAGNOSTICS

Syncova soll eigene Probleme erkennen.

Beispiele:

Database unavailable
Repository unavailable
Agent unreachable
Storage nearly full
Certificate expired
Backup chain broken
Verification failed

Das System soll klare Handlungsempfehlungen anzeigen.

Nicht:

ERROR 0x18372

sondern:

Repository connection failed.

Syncova could not access:
Repository-01

Possible causes:
- Network unavailable
- Repository offline
- Credentials invalid

Recommended action:
Check repository connectivity.

49. LOGGING

Strukturiertes Logging.

Jeder Logeintrag sollte mindestens enthalten:

  • timestamp
  • level
  • service
  • component
  • operation
  • correlation ID
  • machine/job ID
  • error code

Levels:

  • DEBUG
  • INFO
  • WARN
  • ERROR
  • CRITICAL

Keine Secrets loggen.

50. CORRELATION IDS

Jede Operation soll eine eindeutige Correlation ID besitzen.

Beispiel:

Backup Job
  |
  +-- Job ID
  +-- Session ID
  +-- Task ID
  +-- Correlation ID

Damit muss ein Fehler Ende-zu-Ende nachvollziehbar sein.

51. ERROR HANDLING

Keine unkontrollierten Exceptions.

Jeder Fehler muss:

  • klassifiziert
  • geloggt
  • verständlich dargestellt
  • recoverbar sein

Retry-Mechanismen müssen:

  • begrenzt
  • exponentiell
  • konfigurierbar

sein.

52. UPDATE SYSTEM

Syncova muss später sicher aktualisiert werden können.

Anforderungen:

  • signierte Releases
  • Versionsprüfung
  • Rollback-Möglichkeit
  • Update Audit
  • Compatibility Checks

Ein fehlerhaftes Update darf nicht das Repository unbrauchbar machen.

53. LICENSING

Architektur vorbereiten für:

  • Free
  • Professional
  • Enterprise

Lizenzprüfung darf nicht verhindern, dass bereits vorhandene Backup-Daten wiederhergestellt werden können.

Recovery muss unabhängig von einer externen Lizenzplattform möglich bleiben, sofern rechtlich/produktseitig vorgesehen.

54. OFFLINE OPERATION

Syncova muss auch ohne Internet funktionieren können.

Mindestens:

  • lokale Backups
  • lokale Recovery
  • lokales Management

dürfen kein Internet benötigen.

55. PROXMOX INTEGRATION

Proxmox ist der primäre Hypervisor für V1.

Die Integration muss mindestens ermöglichen:

  • Proxmox Hosts hinzufügen
  • Proxmox Cluster erkennen
  • VMs erkennen
  • VM Status erkennen
  • VM Storage erkennen
  • VM Konfiguration lesen
  • Backup Job auf VMs anwenden
  • VM Recovery
  • Restore als neue VM
  • Restore auf anderen Host

Die Integration muss mit der offiziellen Proxmox API arbeiten, soweit sinnvoll.

Keine direkte Manipulation interner Proxmox-Datenbanken.

56. PROXMOX PROVIDER ABSTRAKTION

Definiere ein generisches Interface:

VirtualizationProvider

connect()
disconnect()

listHosts()
listClusters()
listVMs()

getVMInfo()
getVMDisks()
getVMMetaData()

createSnapshot()
removeSnapshot()

startVM()
stopVM()

restoreVM()

Proxmox implementiert dieses Interface.

Spätere Provider können dasselbe Interface implementieren.

57. WINDOWS AGENT

Der Windows Agent muss:

  • als Service laufen
  • automatisch starten
  • sicheren Heartbeat senden
  • Dateien lesen
  • Systeminformationen erfassen
  • Backup-Daten übertragen
  • Restore unterstützen

können.

Der Agent darf nur die minimal notwendigen Rechte besitzen.

58. LINUX AGENT

Der Linux Agent soll:

  • als systemd Service laufen
  • minimal privilegiert sein
  • sichere Kommunikation verwenden
  • Dateien sichern
  • Systeminformationen erfassen
  • Restore unterstützen

59. AGENT SECURITY

Agents müssen sich sicher am Control Server registrieren.

Unterstütze langfristig:

  • Certificate Authentication
  • Device Identity
  • Agent Tokens
  • Rotation
  • Revocation

Ein kompromittierter Agent darf nicht automatisch vollständigen Zugriff auf die Backup-Infrastruktur erhalten.

60. BANDWIDTH MANAGEMENT

Backup Jobs sollen Bandbreitenlimits besitzen.

Beispiel:

00:00–06:00
Unlimited

06:00–18:00
100 Mbps

18:00–00:00
500 Mbps

Statistiken:

  • Network Used
  • Network Saved
  • Compression
  • Dedup
  • Throughput

61. PRIORITY

Jobs müssen Prioritäten besitzen:

  • Critical
  • High
  • Normal
  • Low

Bei Ressourcenknappheit muss der Scheduler entsprechend priorisieren.

62. CONCURRENCY

Administratoren müssen konfigurieren können:

Max concurrent jobs:
4

Repository-seitige Limits:

Max concurrent writes:
8

Die Engine muss Ressourcen kontrolliert verwenden.

63. STORAGE HEALTH

Überwache:

  • Capacity
  • SMART, sofern verfügbar
  • Disk errors
  • filesystem errors
  • latency
  • IOPS
  • throughput
  • repository availability

Bei Hardwareproblemen:

CRITICAL

Storage health degraded.

Possible disk failure detected.

64. DATABASE HEALTH

Dashboard für:

  • PostgreSQL availability
  • connections
  • latency
  • storage
  • errors
  • backup status

Syncova muss seine eigene Konfiguration regelmäßig sichern können.

65. SYNCOVA CONFIGURATION BACKUP

Syncova selbst muss seine Konfiguration sichern können.

Backup von:

  • Jobs
  • Policies
  • Users metadata
  • Repository configuration
  • System configuration
  • Encryption metadata

Keine Secrets im Klartext.

66. DISASTER RECOVERY DES CONTROL SERVERS

Definiere ein vollständiges Verfahren:

New Server
   |
Install Syncova
   |
Restore Configuration
   |
Attach Repository
   |
Verify Repository
   |
Rebuild Catalog
   |
Recover

Dieses Szenario muss automatisiert getestet werden.

67. UI DESIGN PRINCIPLES

Die Oberfläche soll:

  • wenige Ebenen besitzen
  • klare Sprache verwenden
  • keine unnötigen Fachbegriffe anzeigen
  • progressive Details anbieten

Beispiel:

Standard:

Backup successful

Details auf Klick:

Duration: 00:18:22
Read: 840 GB
Written: 214 GB
Dedup: 3.1x
Compression: 1.8x
Verification: Passed

68. DARK MODE

Unterstütze:

  • Light Mode
  • Dark Mode
  • System Mode

69. GLOBAL SEARCH

Die Weboberfläche soll eine globale Suche besitzen.

Suche nach:

  • Server
  • VM
  • Job
  • Backup
  • Restore Point
  • Alert
  • Event
  • Repository

70. FILTER UND SORTIERUNG

Alle Listen sollen unterstützen:

  • Suche
  • Filter
  • Sortierung
  • Pagination
  • Export

71. EXPORT

Reports und Tabellen sollen exportierbar sein.

Architektur vorbereiten für:

  • CSV
  • JSON
  • PDF

72. REPORTS

Mindestens:

Daily Backup Report

Weekly Backup Report

Monthly Backup Report

Repository Capacity Report

Recovery Report

Security Report

Compliance Report

Failed Backup Report

RPO/RTO Report

73. COMPLIANCE DASHBOARD

Syncova soll keine Compliance-Zertifizierung vortäuschen.

Aber es soll technische Informationen liefern, die bei Audits hilfreich sind.

Beispielsweise:

Encryption:
100%

Immutable:
96%

MFA:
100%

Backup Verification:
98%

Audit Logging:
Enabled

Offsite:
Enabled

74. METRICS ENGINE

Implementiere eine zentrale Metrics Engine.

Metriken müssen nach Möglichkeit speichern:

  • Timestamp
  • Entity
  • Metric
  • Value
  • Unit

Beispiele:

backup.duration
backup.bytes_processed
backup.bytes_written
backup.throughput
repository.capacity
repository.used
repository.free
agent.cpu
agent.memory
network.throughput
recovery.duration
verification.duration

75. GRAPH SYSTEM

Das UI muss Graphen dynamisch aus den gespeicherten Metriken erzeugen können.

Zeiträume:

  • Last hour
  • Last 24 hours
  • Last 7 days
  • Last 30 days
  • Last 90 days
  • Last year
  • Custom

Graph-Typen:

  • Line
  • Bar
  • Pie, nur wenn sinnvoll
  • Area
  • Scatter, wenn sinnvoll

Nicht jeden Wert als Graph darstellen.

76. DASHBOARD CUSTOMIZATION

Der Benutzer soll später Dashboards anpassen können.

Widgets:

  • Backup Success Rate
  • Storage
  • Capacity Forecast
  • Ransomware Risk
  • Recovery Assurance
  • Failed Jobs
  • RPO Compliance
  • RTO Compliance
  • Throughput
  • Top Data Consumers
  • Repository Health

77. TOP DATA CONSUMERS

Zeige:

Server01     12.2 TB
Server02      8.4 TB
Server03      7.1 TB
Server04      5.8 TB

Optional:

  • growth
  • backup frequency
  • storage cost estimate

78. ANOMALY DETECTION

Das System soll normale Backup-Muster lernen können.

Beispiel:

Server01 normally:
20–40 GB/day

Today:
420 GB

Anomaly:
HIGH

Zunächst heuristisch.

Später kann Machine Learning integriert werden.

Keine KI als Voraussetzung für die Kernfunktionalität.

79. PERFORMANCE REQUIREMENTS

Das System soll auf moderne Hardware skalieren.

Die Architektur muss:

  • parallel
  • streamingfähig
  • async
  • ressourcenkontrolliert

sein.

Keine vollständige Datei/VM in RAM laden.

Daten müssen möglichst gestreamt verarbeitet werden:

Read
 ↓
Chunk
 ↓
Dedup
 ↓
Compress
 ↓
Encrypt
 ↓
Write

80. MEMORY MANAGEMENT

Backup-Daten dürfen nicht vollständig im RAM zwischengespeichert werden.

Verwende:

  • Streaming
  • Bounded Buffers
  • Backpressure
  • Worker Pools

81. RESUME

Unterbrochene Backups müssen möglichst fortgesetzt werden können.

Beispiel:

Backup:
70%

Network Failure

Resume:
70%

Nicht zwingend wieder bei 0 starten.

82. CHECKPOINTING

Backup Sessions müssen Checkpoints besitzen.

Bei Abbruch:

Last checkpoint:
Chunk 1838291

Recovery soll die Session fortsetzen können, sofern sicher.

83. REPOSITORY LOCKING

Verhindere:

  • konkurrierende Korruption
  • unkontrollierte Schreibzugriffe
  • Race Conditions

Repository Operationen müssen atomar oder transaktional aufgebaut werden, soweit möglich.

84. BACKUP CHAIN PROTECTION

Backup Chains müssen validiert werden.

Beispiel:

Full
 |
 +-- Inc 1
 |
 +-- Inc 2
 |
 +-- Inc 3

Wenn Inc 2 beschädigt ist, muss Syncova eindeutig anzeigen:

Backup Chain Broken

Affected Restore Points:
Inc 2
Inc 3

85. RESTORE POINT VALIDATION

Vor einer Wiederherstellung muss Syncova prüfen:

  • Backup existiert
  • Chain vollständig
  • Encryption verfügbar
  • Repository erreichbar
  • Chunks verfügbar
  • Integrity valid
  • benötigte Parent Backups vorhanden

86. SAFE RESTORE

Restore darf standardmäßig keine Produktionsdaten überschreiben, ohne deutliche Bestätigung.

Bei:

Restore to Original

muss eine zusätzliche Bestätigung erscheinen.

Bei kritischen Restore-Aktionen kann optional eine Four-Eyes-Freigabe erforderlich sein.

87. FOUR-EYES / APPROVAL SYSTEM

Architektur vorbereiten für:

User A:
Restore production server

User B:
Approve

Restore executes

Insbesondere für:

  • Löschen
  • Retention Änderungen
  • Security Policy Änderungen
  • Restore über bestehende Systeme
  • Repository Änderungen

88. ZERO TRUST

Kein interner Service soll automatisch als vertrauenswürdig betrachtet werden.

Services müssen sich authentifizieren.

Berechtigungen müssen explizit sein.

89. NETWORK SEGMENTATION

Dokumentiere empfohlene Netzwerkarchitektur:

Production Network
        |
        | outbound / controlled
        v
Backup Network
        |
        +---- Control Server
        |
        +---- Repository

Repository soll möglichst nicht unnötig direkt aus dem Produktionsnetz erreichbar sein.

90. SECURITY CENTER

Das Webinterface benötigt einen zentralen Security-Bereich.

Zeige:

Security Score
94 / 100

Prüfungen:

  • MFA
  • RBAC
  • Encryption
  • Immutable
  • Offsite
  • Audit
  • Agent Security
  • Repository Security
  • Ransomware Risk
  • Certificates
  • Updates

91. SECURITY SCORE

Score muss transparent sein.

Beispiel:

MFA                  +20
Immutable            +20
Encryption           +20
Offsite              +15
Verification         +15
Audit                +5
Up to date           +5

Total:
100

Dies ist nur ein Beispiel.

Die tatsächliche Gewichtung soll sauber dokumentiert und konfigurierbar sein.

92. CERTIFICATE MANAGEMENT

Verwalte:

  • TLS Certificates
  • Agent Certificates
  • Expiration
  • Renewal

Warnung:

Certificate expires in 14 days

93. HEALTH ENGINE

Jede Komponente besitzt einen Health Status:

  • Healthy
  • Degraded
  • Warning
  • Critical
  • Offline

Gesamtsystem:

Syncova Health:
HEALTHY

94. SELF TEST

Syncova soll einen:

System Health Check

bereitstellen.

Prüft:

  • Database
  • Repository
  • Storage
  • Agents
  • Network
  • Certificates
  • Backup Jobs
  • Encryption
  • Immutability
  • Verification

95. TESTING

Testing ist ein zentraler Bestandteil des Projekts.

Implementiere:

Unit Tests

Für alle wichtigen Komponenten.

Integration Tests

  • Agent
  • Control Server
  • Repository
  • PostgreSQL
  • Proxmox

End-to-End Tests

Beispiel:

Create VM
   |
Backup
   |
Verify
   |
Destroy VM
   |
Restore
   |
Boot
   |
Validate

Failure Tests

Simuliere:

  • Netzwerkverlust
  • Repository-Ausfall
  • Agent-Ausfall
  • Control Server-Ausfall
  • Datenbank-Ausfall
  • beschädigte Chunks
  • fehlenden Speicher
  • abgebrochene Backups
  • Stromausfall-Szenarien

96. CHAOS TESTING

Langfristig:

Kill Service
Disconnect Network
Fill Repository
Corrupt Chunk
Restart Server
Kill Database

Danach muss Syncova sich kontrolliert verhalten.

97. SECURITY TESTING

Automatisierte Tests für:

  • Authentication
  • Authorization
  • RBAC
  • API Security
  • Injection
  • Path Traversal
  • SSRF
  • CSRF
  • XSS
  • Command Injection
  • Privilege Escalation
  • Secrets Exposure

Dependency Scanning:

  • Go dependencies
  • NPM dependencies
  • OS packages

98. CODE QUALITY

Der Code muss:

  • modular
  • testbar
  • dokumentiert
  • wartbar

sein.

Keine unnötig komplexen Abhängigkeiten.

Keine riesigen Monolith-Dateien.

Keine versteckten globalen Zustände.

Keine Hardcoded Credentials.

Keine Hardcoded Production URLs.

Keine Magic Numbers ohne Erklärung.

99. OBSERVABILITY

Syncova muss selbst beobachtbar sein.

Bereitstellen:

  • Metrics
  • Logs
  • Traces, wo sinnvoll
  • Health endpoints
  • Readiness
  • Liveness

100. DOCUMENTATION

Das Projekt muss Dokumentation enthalten.

Mindestens:

/docs

architecture.md
security.md
backup-engine.md
repository.md
recovery.md
proxmox.md
api.md
database.md
deployment.md
troubleshooting.md
disaster-recovery.md

101. DATABASE DESIGN

Erstelle ein sauberes relationales Schema.

Mindestens Entities:

users
roles
permissions

agents
agent_certificates

proxmox_clusters
proxmox_hosts
virtual_machines

backup_jobs
backup_job_sources
backup_job_runs

backups
backup_chains
restore_points

repositories
repository_health
repository_metrics

chunks
chunk_references

restore_jobs
restore_sessions

verification_jobs
verification_results

alerts
alert_rules

audit_events

metrics
events

encryption_keys_metadata
certificates

system_settings

Keine unnötige Redundanz.

Foreign Keys und Constraints sauber definieren.

102. MIGRATIONS

Datenbankschema muss über Migrationen verwaltet werden.

Migrationen müssen:

  • versioniert
  • reproduzierbar
  • rollbackfähig, soweit möglich

sein.

103. API DOCUMENTATION

Automatisch OpenAPI generieren.

Für jede API:

  • Request
  • Response
  • Authentication
  • Authorization
  • Errors
  • Examples

104. FRONTEND ARCHITECTURE

Frontend modular.

Beispiel:

src/

components/
pages/
layouts/
features/
hooks/
services/
api/
types/
utils/
charts/
auth/

Keine gesamte Anwendung in einer Datei.

105. DESIGN SYSTEM

Definiere ein konsistentes Designsystem.

Komponenten:

  • Button
  • Card
  • Table
  • Modal
  • Dialog
  • Badge
  • Status Indicator
  • Alert
  • Chart
  • Progress
  • Tabs
  • Dropdown
  • Form
  • Date Picker
  • Time Picker

106. STATUS COLORS

Semantische Farben nur für Status verwenden:

  • Green = Healthy
  • Yellow = Warning
  • Orange = High
  • Red = Critical
  • Blue/Neutral = Information

Nicht alles bunt machen.

107. ACCESSIBILITY

Beachte:

  • Keyboard Navigation
  • Focus States
  • Labels
  • Kontrast
  • Screen Reader
  • verständliche Fehlermeldungen

108. INTERNATIONALIZATION

Architektur vorbereiten für:

  • Deutsch
  • Englisch

V1 darf zunächst Englisch oder Deutsch als primäre Sprache besitzen.

Alle UI-Strings dürfen nicht hart in Komponenten verstreut sein.

109. TIMEZONE

Alle Daten müssen intern eindeutig gespeichert werden.

Bevorzugt UTC.

Frontend zeigt lokale Zeitzone.

110. BACKUP TIMESTAMPS

Backup-Metadaten müssen enthalten:

  • started_at
  • completed_at
  • duration
  • timezone context
  • source timestamp
  • repository timestamp

111. DATA RETENTION FÜR METRIKEN

Metrics dürfen nicht unbegrenzt wachsen.

Beispiel:

High resolution:
7 days

Hourly:
90 days

Daily:
2 years

Die genaue Policy soll konfigurierbar sein.

112. PERFORMANCE DASHBOARD FÜR BACKUPS

Zeige pro Job:

Read:
1.8 TB

Transferred:
430 GB

Written:
310 GB

Dedup:
4.2x

Compression:
1.6x

Network:
210 GB

Duration:
00:32:41

Average Speed:
930 MB/s

113. BACKUP COST ANALYSIS

Architektur vorbereiten für Kostenberechnung.

Bei Object Storage:

Storage Cost
API Requests
Data Transfer
Estimated Monthly Cost

Nicht zwingend vollständig in V1, aber Datenmodell vorbereiten.

114. SEARCHABLE EVENTS

Events müssen durchsuchbar sein.

Filter:

  • Zeitraum
  • Severity
  • Server
  • Job
  • Repository
  • User
  • Component

115. INCIDENT VIEW

Bei kritischen Problemen soll Syncova eine Incident-Ansicht anbieten.

Beispiel:

INCIDENT #1042

Possible ransomware activity

Affected:
Server01

Started:
02:17

Detected:
02:22

Last known good backup:
02:00

Affected backup:
02:30

Recommended restore point:
02:00

116. RECOVERY WORKFLOW

Der Recovery-Assistent soll Schritt für Schritt führen:

1. Select System
2. Select Recovery Point
3. Validate
4. Select Target
5. Configure Restore
6. Review
7. Confirm
8. Restore
9. Validate
10. Complete

Keine gefährlichen Aktionen ohne Review.

117. BACKUP WIZARD

Backup-Erstellung:

1. Name
2. Source
3. Schedule
4. Repository
5. Retention
6. Security
7. Verification
8. Notifications
9. Review
10. Create

118. SIMPLE MODE UND ADVANCED MODE

Die Benutzeroberfläche soll zwei Ebenen anbieten.

Simple

Nur:

  • Source
  • Schedule
  • Repository
  • Retention

Advanced

Zusätzlich:

  • Compression
  • Dedup
  • Encryption
  • Bandwidth
  • Priority
  • Verification
  • RPO
  • RTO
  • Advanced retention

119. DEFAULTS

Sichere Standardwerte.

Beispielsweise:

  • Encryption ON
  • Verification ON
  • Compression Balanced
  • Retention 30 days
  • Notifications ON
  • Secure Transport ON

Der Benutzer soll nicht erst Security aktivieren müssen.

120. SAFE DEFAULTS

Nie standardmäßig:

  • Encryption OFF
  • MFA OFF für Admins, wenn die Umgebung dies unterstützt
  • Immutable OFF bei Hardened Repository
  • destructive restore
  • unbounded concurrency
  • unlimited retention

121. INSTALLATION

Installation soll möglichst einfach sein.

Ziel:

Install
   |
Open Web UI
   |
Create Admin
   |
Add Repository
   |
Add Source
   |
Create Backup

122. FIRST RUN WIZARD

Beim ersten Start:

Welcome to Syncova

1. Create administrator
2. Configure security
3. Add repository
4. Add protected system
5. Create first backup
6. Verify backup

123. FIRST BACKUP EXPERIENCE

Nach dem ersten Backup:

Backup completed

✓ Data protected
✓ Encryption enabled
✓ Repository healthy
✓ Integrity verified
✓ Recovery test passed

Recovery Assurance:
100 / 100

124. PRODUCT LANGUAGE

Keine unnötig technischen Fehlermeldungen.

Statt:

ENOENT

besser:

Syncova could not find the configured repository path.

Technische Details trotzdem über:

Show technical details

anzeigen.

125. SECURITY EVENTS

Security Events separat erfassen.

Beispiele:

  • Login failure
  • MFA failure
  • Permission denied
  • Credential change
  • Role change
  • Repository change
  • Retention change
  • Encryption change
  • Restore approval
  • Agent registration

126. ADMIN PROTECTION

Besonders kritische Aktionen können:

  • Passwortbestätigung
  • MFA
  • Four-Eyes Approval

erfordern.

127. NO TELEMETRY BY DEFAULT

Syncova darf ohne ausdrückliche Konfiguration keine sensiblen Daten an externe Server senden.

Telemetry muss:

  • opt-in
  • dokumentiert
  • anonymisiert

sein.

128. PRIVACY

Keine unnötige Sammlung personenbezogener Daten.

Logs müssen Datenschutz berücksichtigen.

129. DATA INTEGRITY OVER PERFORMANCE

Wenn zwischen:

Performance

und:

Data Integrity

gewählt werden muss, gewinnt Data Integrity.

Ein schnelleres Backup, das Daten beschädigt, ist kein Erfolg.

130. RECOVERY OVER BACKUP

Wenn zwischen:

Backup Performance

und:

Recovery Reliability

gewählt werden muss, gewinnt Recovery Reliability.

131. DEFINITION OF DONE

Eine Funktion gilt erst als fertig, wenn:

  1. Implementiert
  2. Unit Tests vorhanden
  3. Integration Tests vorhanden, sofern relevant
  4. Fehlerbehandlung vorhanden
  5. Logging vorhanden
  6. Security geprüft
  7. UI vorhanden, falls User-facing
  8. API vorhanden, falls relevant
  9. Dokumentation vorhanden
  10. Migration vorhanden, falls DB betroffen
  11. Monitoring vorhanden, falls relevant
  12. Recovery getestet, falls Backup/Recovery betroffen

132. V1 RELEASE CRITERIA

Syncova V1 darf erst als Release Candidate betrachtet werden, wenn:

Backup

  • Windows Backup funktioniert
  • Linux Backup funktioniert
  • Proxmox VM Backup funktioniert
  • Incremental funktioniert
  • Compression funktioniert
  • Deduplication funktioniert
  • Encryption funktioniert

Repository

  • Local Repository funktioniert
  • Hardened Repository funktioniert
  • Integrity Checks funktionieren
  • Immutability funktioniert

Recovery

  • File Restore funktioniert
  • Full Restore funktioniert
  • Proxmox VM Restore funktioniert
  • Recovery Validation funktioniert
  • Repository Rebuild funktioniert

Security

  • MFA funktioniert
  • RBAC funktioniert
  • Audit funktioniert
  • TLS funktioniert
  • Secrets sind geschützt

Management

  • Web UI funktioniert
  • Dashboard funktioniert
  • Graphen funktionieren
  • Alerts funktionieren
  • Reports funktionieren
  • API funktioniert

Reliability

  • Backup interruption recovery funktioniert
  • Repository restart funktioniert
  • Control Server restart funktioniert
  • Database recovery getestet
  • beschädigte Daten werden erkannt

133. PRIORITÄTEN

Bei der Entwicklung folgende Priorität einhalten:

P0 – absolut kritisch

  • Backup Engine
  • Repository
  • Encryption
  • Integrity
  • Recovery
  • Immutability
  • Security
  • Proxmox Backup
  • Windows/Linux Backup

P1 – sehr wichtig

  • Web UI
  • Dashboard
  • Monitoring
  • Alerts
  • Statistics
  • Verification
  • RBAC
  • MFA
  • API

P2

  • Advanced Reports
  • Capacity Forecast
  • Anomaly Detection
  • Object Storage
  • Backup Copy
  • Synthetic Full

P3

  • zusätzliche Hypervisoren
  • Cloud Workloads
  • Kubernetes
  • SaaS
  • Enterprise Integrations

134. NICHT V1

Nicht unnötig in V1 implementieren:

  • VMware
  • Hyper-V, sofern es den Zeitplan gefährdet
  • Kubernetes
  • Microsoft 365
  • Exchange
  • SharePoint
  • SAP
  • Oracle Enterprise Integration
  • Nutanix
  • komplexe Multi-Tenant-MSP-Funktionen
  • KI-Assistent
  • 20 Cloud Provider
  • komplexe DR-Orchestrierung

Die Architektur muss diese Erweiterungen ermöglichen, aber V1 darf dadurch nicht unnötig komplex werden.

135. ARCHITEKTURREGEL FÜR ZUKÜNFTIGE PROVIDER

Alle externen Plattformen müssen über Provider-Abstraktionen integriert werden.

Beispiel:

Backup Core

     |
     +----------------+
     | Provider API   |
     +----------------+
       |     |     |
       v     v     v
    Proxmox VMware Hyper-V

V1:

Proxmox only

Aber keine Proxmox-spezifische Logik im generischen Backup Core.

136. DEVELOPMENT METHODOLOGY

Arbeite iterativ.

Nicht versuchen, die komplette Plattform in einem Schritt zu generieren.

Arbeite in Phasen:

Phase 1

Architecture

Phase 2

Repository

Phase 3

Backup Engine

Phase 4

Windows/Linux Agent

Phase 5

Proxmox Provider

Phase 6

Recovery

Phase 7

Security

Phase 8

Web UI

Phase 9

Monitoring

Phase 10

Verification

Phase 11

Hardening

Phase 12

Testing

Phase 13

Release

137. ENTWICKLUNGSREGEL

Bevor Code geschrieben wird:

  1. Architektur verstehen
  2. Abhängigkeiten identifizieren
  3. Datenmodelle definieren
  4. APIs definieren
  5. Sicherheitsrisiken analysieren
  6. Implementierungsplan erstellen
  7. Erst danach implementieren

Keine großen ungeplanten Codeblöcke.

138. KEINE FAKE FEATURES

Wenn eine Funktion noch nicht implementiert ist:

Nicht:

Feature funktioniert

anzeigen.

Stattdessen:

Not implemented

oder Feature deaktivieren.

Keine Mock-Daten in Production.

Keine vorgetäuschten Backup-Erfolge.

Keine erfundenen Statistiken.

139. DEMO DATA

Demo-Daten dürfen ausschließlich in:

Development
Demo
Testing

verwendet werden.

Production muss ausschließlich reale Daten anzeigen.

140. NO SILENT FAILURES

Kein Fehler darf stillschweigend ignoriert werden.

Wenn ein Backup teilweise fehlschlägt:

PARTIAL FAILURE

und nicht:

SUCCESS

141. DATA LOSS PROTECTION

Besondere Vorsicht bei:

  • Retention
  • Repository Cleanup
  • Restore
  • Encryption Keys
  • Repository Migration

Vor potentiell destruktiven Aktionen:

  1. Risiko erkennen
  2. Benutzer warnen
  3. Bestätigung verlangen
  4. Aktion auditieren

142. ENCRYPTION KEY RECOVERY

Ein Backup darf nicht durch versehentliches Löschen eines Keys unwiederbringlich verloren gehen.

Implementiere ein sicheres Key-Recovery-Konzept.

Dabei müssen:

  • Backup Keys
  • Recovery Keys
  • Key Rotation

sauber getrennt werden.

143. KEY ROTATION

Architektur vorbereiten für:

  • Rotation
  • Revocation
  • Re-encryption

Ein alter Backup-Stand darf nach einer Key Rotation weiterhin wiederherstellbar bleiben.

144. BACKUP VERIFICATION AUTOMATION

Administrator soll einstellen können:

Verify every backup
Verify daily
Verify weekly
Verify critical systems only

145. APPLICATION-AWARE ARCHITECTURE

Application-aware Backup muss zunächst nicht vollständig implementiert werden.

Die Architektur soll aber vorbereitet sein für:

  • Microsoft SQL Server
  • PostgreSQL
  • MySQL
  • Active Directory
  • Exchange

Spätere Provider:

ApplicationProvider

146. PROXMOX APPLICATION AWARENESS

Bei Proxmox sollen Guest-Agent-Informationen berücksichtigt werden, sofern verfügbar.

Wenn ein Gast-Agent fehlt:

WARNING

Guest integration is not available.

Backup can continue, but application-aware
consistency may be reduced.

147. CONSISTENCY LEVELS

Backup soll unterscheiden können:

  • Crash Consistent
  • Application Consistent
  • Verified

Diese Information muss im Backup sichtbar sein.

148. RECOVERY TEST ENVIRONMENT

Architektur vorbereiten für isolierte Recovery-Netzwerke.

Beispiel:

Production
    X
    |
    | isolated
    v
Recovery Sandbox
    |
    v
Boot VM
    |
    v
Test

Keine Recovery-Test-VM darf versehentlich das Produktionsnetz stören.

149. RECOVERY TEST RESULTS

Ein Test soll Ergebnisse liefern:

VM Boot:
PASS

Disk:
PASS

Network:
PASS

Services:
PASS

Application:
PASS

Integrity:
PASS

Overall:
PASS

150. FINAL PRODUCT VISION

Syncova soll am Ende ein System sein, bei dem ein Administrator nicht ständig überlegen muss:

> „Habe ich wirklich ein Backup?“

Sondern:

> „Syncova hat mein System gesichert, die Daten geschützt, die Kopie immutable gespeichert, die Integrität geprüft, die Wiederherstellung getestet und mir den Zustand transparent dargestellt.“

Das zentrale Dashboard soll deshalb immer die folgende Frage beantworten:

„Kann ich mein System jetzt wiederherstellen?“

Die Antwort muss jederzeit nachvollziehbar sein.

151. ABSCHLUSSREGEL

Entwickle Syncova nicht als Sammlung einzelner Features.

Entwickle ein zusammenhängendes System.

Jede Komponente muss mit:

  • Backup
  • Security
  • Verification
  • Recovery
  • Monitoring

zusammenarbeiten.

Die Architektur muss langfristig skalieren können von:

1 Server

bis zu:

1000+ Servers

ohne dass die grundlegenden Konzepte neu entwickelt werden müssen.

152. DAS ZIEL

Die erste Version soll nicht versuchen, Veeam in der Anzahl der unterstützten Funktionen zu schlagen.

Syncova V1 soll stattdessen durch folgende Eigenschaften überzeugen:

  1. Einfachere Bedienung
  2. Moderne Weboberfläche
  3. Hervorragende Proxmox-Unterstützung
  4. Sehr gute Windows/Linux-Unterstützung
  5. Immutable Backups
  6. starke Security
  7. transparente Statistiken
  8. hervorragende Recovery-Funktionen
  9. automatische Backup Verification
  10. Recovery Assurance
  11. hervorragendes Monitoring
  12. verständliche Fehlermeldungen
  13. zuverlässige Architektur
  14. vollständige API
  15. sehr gute Performance
  16. keine unnötige Komplexität

Der wichtigste Leitsatz lautet:

BACKUP IS NOT SUCCESSFUL UNTIL RECOVERY IS PROVEN.

Entwickle Syncova entsprechend diesem Prinzip.