# 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.