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>
46 lines
1.2 KiB
TypeScript
46 lines
1.2 KiB
TypeScript
/// <reference types="vitest/config" />
|
|
import { defineConfig } from 'vite';
|
|
import react from '@vitejs/plugin-react';
|
|
|
|
/**
|
|
* Vite-Konfiguration der Syncova-Weboberflaeche.
|
|
*
|
|
* Die API-Adresse wird niemals fest im Code hinterlegt: im Entwicklungsbetrieb
|
|
* laeuft sie ueber einen Proxy, im Produktionsbetrieb liefert derselbe Ursprung
|
|
* Oberflaeche und API aus (PROMPT.md §98: keine hardcoded Production-URLs).
|
|
*/
|
|
export default defineConfig({
|
|
plugins: [react()],
|
|
|
|
server: {
|
|
// Der Entwicklungsserver bindet nur lokal.
|
|
host: '127.0.0.1',
|
|
port: 5173,
|
|
proxy: {
|
|
// Anfragen an die API werden an den lokalen Go-Dienst weitergereicht.
|
|
// Dadurch bleibt der Ursprung gleich und es wird kein CORS benoetigt.
|
|
'/api': {
|
|
target: 'http://127.0.0.1:8080',
|
|
changeOrigin: false,
|
|
},
|
|
'/health': {
|
|
target: 'http://127.0.0.1:8080',
|
|
changeOrigin: false,
|
|
},
|
|
},
|
|
},
|
|
|
|
build: {
|
|
outDir: 'dist',
|
|
// Source Maps erleichtern die Fehlersuche im Betrieb, ohne Quellcode auszuliefern.
|
|
sourcemap: true,
|
|
},
|
|
|
|
test: {
|
|
environment: 'jsdom',
|
|
globals: true,
|
|
setupFiles: ['./src/test/setup.ts'],
|
|
css: false,
|
|
},
|
|
});
|