[CallMeTechie]

Worum es geht

Bis 1.258.1 wurde das verschlüsselte Offsite-Archiv (.gcbk) als ein Buffer gebaut und so an WebDAV/S3/SMB/SFTP übergeben. Mit ~400 MB Plugin-Daten heißt das: das ganze Archiv (~400 MB) liegt im Arbeitsspeicher, die Spitze lag bei über 500 MB RSS – zu viel für einen kleinen VPS.

Jetzt wird das Archiv als Stream in eine Datei geschrieben und von dort hochgeladen. Der zusätzliche Speicher bleibt bei einigen zehn MB, egal wie groß das Archiv ist.

Änderungen

Archiv (gcbk.writeBackupArchive)

• Backup-Datei → gzip → AES-256-GCM → Archivdatei, alles als Stream (Format GCBK1 unverändert).
• Größe und – nur wenn ein S3-Ziel aktiv ist – SHA-256 je S3-Teil werden beim Schreiben berechnet (kein zweites Lesen).
• Ablage in <Backup-Ordner>/.incoming (0700, Name zufällig vom Server, Pfad über backupUpload.incomingPath geprüft). Vorher Prüfung des freien Platzes (backup.checkFreeSpace aus Backup: Plugin-Daten bis 512 MB, unvollständige Backups deutlich sichtbar #458), Löschen im finally, Reste eines Absturzes werden beim ersten Gebrauch entfernt.
• Zu wenig Platz → NO_SPACE (507) mit Hinweis no_space; die Oberfläche zeigt einen deutschen Text („Auf dem GateControl-Server ist zu wenig Speicherplatz frei …“).

Transporte (services/offsite/source.js: Archivdatei oder – für Schreibtests – Buffer)

• WebDAV: PUT als Stream mit Content-Length (nie chunked).
• S3: bis 64 MiB ein PUT als Stream, darüber Multipart in 64-MiB-Teilen, Teil für Teil aus der Datei gelesen. Jeder Teil ist mit seinem echten SHA-256 signiert (weiterhin kein UNSIGNED-PAYLOAD). Bei einem Fehler (auch bei „200 mit <Error>“ beim Abschließen) folgt AbortMultipartUpload.
• SMB: put direkt aus der Archivdatei (smbclient liest in Blöcken), keine Kopie in eine Temp-Datei mehr.
• SFTP: put direkt aus der Archivdatei.
• SMB/SFTP: Das harte Zeitlimit wächst mit der Größe (Basis + Größe bei 1 Mbit/s). Vorher endete die Übertragung nach festen 3 Minuten, was für einige hundert MB über eine langsame Leitung nicht reicht.
• Jeder Versuch öffnet einen frischen Lese-Stream: Die Wiederholung nach „Zertifikat beim ersten Kontakt gemerkt“ (withTrust) startet sauber von vorn.
• via (VPN-Gerät/Weiterleitung), tls_ca, Zertifikats-Pinning und SMB3-Verschlüsselung (feat(storage): NAS-Zertifikat ohne PEM-Datei vertrauen, Offsite-S3 über VPN, SMB3-Verschlüsselung #457) sind unverändert und laufen über dieselben Wege.

Wiederherstellungstest

• downloadTo statt download: Das Archiv wird Stück für Stück in eine Datei geladen (mit Größenlimit), das Entschlüsseln läuft wie seit Backup: Plugin-Daten bis 512 MB, unvollständige Backups deutlich sichtbar #458 als Stream. Vorher lag es einmal ganz im Speicher.

Aufbewahrung, Status/SSE, Fehlertexte und der Ablauf des Wiederherstellungstests bleiben gleich.

Speicher – vorher/nachher

node scripts/offsite-memory-check.js --mb 400 [--legacy]: 400 MB Plugin-Daten, Archiv 402 MB, Upload an WebDAV und S3 (Multipart, 16-MiB-Teile) in einem Prozess, RSS alle 10 ms gemessen.

	zusätzlicher RSS	Spitze RSS
vorher (Archiv als Buffer)	+441 MB	517 MB
jetzt (Datei + Streams)	+43 MB	118 MB

Mit 50 MB, 160 MB und 800 MB Archiv bleibt der Zusatz gleich bei ~43–45 MB (Arbeitsspeicher von V8 und zlib, nicht das Archiv).

Tests

• Fake-S3 (prüft SigV4 inkl. Payload-Hash): Multipart mit abgesenkter Teilgröße, Hashes vom Schreiben und aus der Datei, falscher Hash wird abgelehnt, Abbruch bei fehlerhaftem Teil und bei spätem Fehler, Content-Length statt chunked.
• WebDAV, SMB, SFTP: Upload aus der Datei, downloadTo, unzulässige lokale Pfade werden abgelehnt (", ; …).
• API: Archivdatei nach Erfolg und nach Fehler entfernt, Reste-Bereinigung, NO_SPACE/507 mit Hinweis, auch in last_error_hint.
• writeBackupArchive: Größe, Teil-Hashes, Rechte 0600, kein Überschreiben, Aufräumen bei ENOSPC mitten im Schreiben.
• Neu im CI-Job „storage targets (S3, WebDAV, SMB)“: tests/offsite_live.test.js gegen moto, wsgidav und Samba. Ein echtes Archiv (~12 MB) geht hoch, kommt Byte für Byte zurück und wird entschlüsselt. S3 läuft als Multipart mit 5 MiB (drei Teile) mit und ohne vorberechnete Hashes und als einzelner PUT; SMB mit erzwungener SMB3-Verschlüsselung. Lokal gegen dieselben Server grün.
• tests/offsite_memory.test.js: Ein Archiv von 160 MB muss mit < 100 MB zusätzlichem RSS hochgehen.

Lokal (Node 22): volle Suite grün bis auf den bekannten lokalen Fehler config_hash_stub_guard. ESLint-Security und no-undef wie in der CI: keine neuen Befunde.

Nicht getestet

• Gegen einen echten S3-Server, der Signaturen prüft (MinIO, Synology C2, Garage, AWS): Moto im CI prüft sie nicht. Die Signaturen je Teil sind gegen den signaturprüfenden Fake-S3 der Unit-Tests geprüft.
• SFTP gegen einen echten Server (wie bisher nur mit Shims).

---

Generated by Claude Code