jf/syncova-backup

Fork 0

Jerrit Fritzsche 610719c316

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:

PROTECT
SECURE
VERIFY
RECOVER
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 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:

Linux Server
virtuelle Maschine
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.

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:

Implementiert
Unit Tests vorhanden
Integration Tests vorhanden, sofern relevant
Fehlerbehandlung vorhanden
Logging vorhanden
Security geprüft
UI vorhanden, falls User-facing
API vorhanden, falls relevant
Dokumentation vorhanden
Migration vorhanden, falls DB betroffen
Monitoring vorhanden, falls relevant
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:

Architektur verstehen
Abhängigkeiten identifizieren
Datenmodelle definieren
APIs definieren
Sicherheitsrisiken analysieren
Implementierungsplan erstellen
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:

Risiko erkennen
Benutzer warnen
Bestätigung verlangen
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:

Einfachere Bedienung
Moderne Weboberfläche
Hervorragende Proxmox-Unterstützung
Sehr gute Windows/Linux-Unterstützung
Immutable Backups
starke Security
transparente Statistiken
hervorragende Recovery-Funktionen
automatische Backup Verification
Recovery Assurance
hervorragendes Monitoring
verständliche Fehlermeldungen
zuverlässige Architektur
vollständige API
sehr gute Performance
keine unnötige Komplexität

Der wichtigste Leitsatz lautet:

BACKUP IS NOT SUCCESSFUL UNTIL RECOVERY IS PROVEN.

Entwickle Syncova entsprechend diesem Prinzip.

53 KiB Raw Blame History Unescape Escape

MASTER DEVELOPMENT PROMPT

SYNCOVA BACKUPS V1.0

0. ROLLE UND AUFGABE

SYNCOVA BACKUPS

Primäres Ziel von V1

1. PRODUKTPHILOSOPHIE

2. KERNPRINZIPIEN

2.1 Security First

2.2 Recovery First

2.3 Keine Single Points of Failure

2.4 Backup-Daten müssen unabhängig bleiben

2.5 Einfachheit

2.6 Automatisierung

3. PRODUKTARCHITEKTUR

4. TECHNOLOGIE

Backend

Frontend

Datenbank

Kommunikation

Deployment

5. KOMPONENTEN

5.1 Syncova Control Server

5.2 Syncova Agent

5.3 Proxmox Provider

5.4 Backup Engine

5.5 Recovery Engine

6. BACKUP-FUNKTIONEN V1

Physische Systeme

Dateien

System Backup

Proxmox VE

7. BACKUP-TYPEN

Full Backup

Incremental Backup

Synthetic Full

Forever Forward Incremental

8. CHANGED BLOCK TRACKING

9. CHUNKING

10. DEDUPLICATION

11. COMPRESSION

12. ENCRYPTION

13. BACKUP-DATEIFORMAT

14. INTEGRITY

15. IMMUTABILITY

Syncova Hardened Repository

16. RETENTION

17. BACKUP COPY

18. 3-2-1-1-0

19. RECOVERY

File Restore

Full Restore

Disk Restore

VM Restore

Bare Metal Recovery

20. RECOVERY VERIFICATION

21. RECOVERY ASSURANCE

Recovery Assurance

22. RANSOMWARE DETECTION

23. JOB SYSTEM

24. JOB STATES

25. SCHEDULER

26. RPO UND RTO

27. WEBINTERFACE

28. NAVIGATION

29. DASHBOARD

30. STATISTIKEN UND GRAPHEN

Backup Statistics

Storage Statistics

31. PERFORMANCE DASHBOARD

32. PROTECTED SYSTEM DASHBOARD

33. DETAILANSICHT SYSTEM

34. LIVE MONITORING

35. REPOSITORY DASHBOARD

36. CAPACITY FORECAST

37. ALERT CENTER

38. ALERT RULES

39. NOTIFICATIONS

40. AUDIT LOG

41. AUTHENTICATION

53 KiB

Raw Blame History