Jerrit Fritzsche
610719c316
Enterprise-Backup-, Recovery-, Verification-, Security- und Monitoring-Plattform fuer Proxmox VE, Windows, Linux und Dateisysteme. Der Leitsatz, der fast jede Entscheidung erklaert: Ein Backup gilt erst als vertrauenswuerdig, wenn Integritaet geprueft und Wiederherstellbarkeit nachgewiesen wurde. Deshalb steigt ein Wiederherstellungspunkt erst nach einem tatsaechlich durchgefuehrten Restore-Test auf "recoverable", und Unbekanntes geht in keine Bewertung als "gut" ein. Umfang (Phasen 0-23): - Repository Engine: inhaltsadressierte Bloecke, atomares Commit-Protokoll, Katalogaufbau allein aus den Manifesten — ohne Datenbank - Backup Engine: inhaltsabhaengiges Chunking, Deduplizierung trotz Verschluesselung, zstd, AES-256-GCM, Streaming mit Gegendruck - Agenten fuer Windows und Linux mit Auftragsabholung (Pull-Modell) - Proxmox-Provider mit beiden Zugriffswegen auf die Sicherungsarchive - Scheduler, Recovery Engine mit Pruefpunkt, Verification, Unveraenderlichkeit - Weboberflaeche, Kennzahlen, Meldungen, Berichte, Security Center, Ransomware-Heuristik (meldet, handelt nie) - Disaster Recovery, Haertung, Leistungsmessung, Chaos Testing - Eingefrorene Vertraege fuer API, Migrationen, Backup-Format und Repository - Auslieferungspaket fuer linux/amd64, linux/arm64 und windows/amd64 Nicht enthalten und als solches gekennzeichnet: Kapazitaetsprognose, Backup Copy, Changed Block Tracking bei Proxmox, erweiterte Attribute und ACLs. Gebaut, aber nie auf echter Hardware gefahren: der Windows-Dienst, die systemd-Einheit und der verpflichtende Proxmox-Meilenstein — ob eine wiederhergestellte VM startet, ist ungeprueft. Einzelheiten in CHANGELOG.md und docs/release-candidate.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3978 lines
53 KiB
Markdown
3978 lines
53 KiB
Markdown
# 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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
HypervisorProvider
|
||
|
|
||
+-- ProxmoxProvider
|
||
|
|
||
+-- Future VMwareProvider
|
||
|
|
||
+-- Future HyperVProvider
|
||
```
|
||
|
||
V1 implementiert ausschließlich:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
VM = 2 TB
|
||
|
||
Gesamt:
|
||
2 TB
|
||
|
||
Geändert:
|
||
35 GB
|
||
|
||
Backup:
|
||
35 GB
|
||
```
|
||
|
||
Nicht:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
3-2-1-1-0 STATUS
|
||
|
||
3 Copies ✓
|
||
2 Media ✓
|
||
1 Offsite ✓
|
||
1 Immutable ✓
|
||
0 Errors ✓
|
||
```
|
||
|
||
Bei Abweichungen:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
Normal:
|
||
4 GB changed
|
||
|
||
Current:
|
||
780 GB changed
|
||
|
||
Risk:
|
||
HIGH
|
||
```
|
||
|
||
Bei Auffälligkeiten:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
RPO:
|
||
4 hours
|
||
|
||
RTO:
|
||
2 hours
|
||
```
|
||
|
||
Syncova muss überwachen:
|
||
|
||
> Wird das konfigurierte RPO tatsächlich eingehalten?
|
||
|
||
Beispiel:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
Protected Systems
|
||
Successful Backups
|
||
Failed Backups
|
||
Critical Alerts
|
||
Recovery Assurance
|
||
Storage Usage
|
||
```
|
||
|
||
Beispiel:
|
||
|
||
```text
|
||
┌──────────────────────────────────────────────────┐
|
||
│ 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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
/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:
|
||
|
||
```text
|
||
/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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
Database unavailable
|
||
Repository unavailable
|
||
Agent unreachable
|
||
Storage nearly full
|
||
Certificate expired
|
||
Backup chain broken
|
||
Verification failed
|
||
```
|
||
|
||
Das System soll klare Handlungsempfehlungen anzeigen.
|
||
|
||
Nicht:
|
||
|
||
```text
|
||
ERROR 0x18372
|
||
```
|
||
|
||
sondern:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
Max concurrent jobs:
|
||
4
|
||
```
|
||
|
||
Repository-seitige Limits:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
Backup successful
|
||
```
|
||
|
||
Details auf Klick:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
Backup:
|
||
70%
|
||
|
||
Network Failure
|
||
|
||
Resume:
|
||
70%
|
||
```
|
||
|
||
Nicht zwingend wieder bei 0 starten.
|
||
|
||
---
|
||
|
||
# 82. CHECKPOINTING
|
||
|
||
Backup Sessions müssen Checkpoints besitzen.
|
||
|
||
Bei Abbruch:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
Full
|
||
|
|
||
+-- Inc 1
|
||
|
|
||
+-- Inc 2
|
||
|
|
||
+-- Inc 3
|
||
```
|
||
|
||
Wenn Inc 2 beschädigt ist, muss Syncova eindeutig anzeigen:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
Certificate expires in 14 days
|
||
```
|
||
|
||
---
|
||
|
||
# 93. HEALTH ENGINE
|
||
|
||
Jede Komponente besitzt einen Health Status:
|
||
|
||
* Healthy
|
||
* Degraded
|
||
* Warning
|
||
* Critical
|
||
* Offline
|
||
|
||
Gesamtsystem:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
/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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
Install
|
||
|
|
||
Open Web UI
|
||
|
|
||
Create Admin
|
||
|
|
||
Add Repository
|
||
|
|
||
Add Source
|
||
|
|
||
Create Backup
|
||
```
|
||
|
||
---
|
||
|
||
# 122. FIRST RUN WIZARD
|
||
|
||
Beim ersten Start:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
ENOENT
|
||
```
|
||
|
||
besser:
|
||
|
||
```text
|
||
Syncova could not find the configured repository path.
|
||
```
|
||
|
||
Technische Details trotzdem über:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
Performance
|
||
```
|
||
|
||
und:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
Backup Performance
|
||
```
|
||
|
||
und:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
Backup Core
|
||
|
||
|
|
||
+----------------+
|
||
| Provider API |
|
||
+----------------+
|
||
| | |
|
||
v v v
|
||
Proxmox VMware Hyper-V
|
||
```
|
||
|
||
V1:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
Feature funktioniert
|
||
```
|
||
|
||
anzeigen.
|
||
|
||
Stattdessen:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
PARTIAL FAILURE
|
||
```
|
||
|
||
und nicht:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
ApplicationProvider
|
||
```
|
||
|
||
---
|
||
|
||
# 146. PROXMOX APPLICATION AWARENESS
|
||
|
||
Bei Proxmox sollen Guest-Agent-Informationen berücksichtigt werden, sofern verfügbar.
|
||
|
||
Wenn ein Gast-Agent fehlt:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
1 Server
|
||
```
|
||
|
||
bis zu:
|
||
|
||
```text
|
||
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.
|