Firmen-Datensicherung

Firmenadmins und Inhaber öffnen in der Webapp ihre Firma und wählen Datensicherung. Dort können sie Sicherungen anfordern, fertige ZIP-Dateien herunterladen und API-Schlüssel für den eigenen Backup-Server verwalten. Die Mobile-App bietet diesen Export nicht an.

Umfang und Grenzen

Die Sicherung enthält gewöhnliche Projekt-Chats der Firma, auch archivierte Chats, mit Nachrichten, Reaktionen, Chat-Karten und den zugeordneten hochgeladenen Anhängen. Dazu kommen Projekt- und Chat-Metadaten, Namen der beteiligten Nutzer sowie veröffentlichte Firmenbelege im Chat. Firmenadmins und Inhaber dürfen damit auch Firmen-Chats sichern, denen sie nicht persönlich beigetreten sind.

Direktnachrichten, private Notizen, persönlich sichtbare Leistungen, firmenübergreifende Chats und persönliche Entwürfe sind ausgeschlossen. Das Firmen-Drive und Inhalte externer Links gehören nicht zu diesem Chat-Export. Fehlende zugeordnete Anhänge lassen die Erstellung fehlschlagen. Das ZIP ist ein Datenexport; einen automatischen Import zurück in Skava gibt es dafür noch nicht.

Limits, inkrementelle Sicherungen und Aufbewahrung

Pro Firma kann innerhalb von 7 Tagen eine Vollsicherung und innerhalb von 24 Stunden zwei Teilsicherungen angefordert werden. Diese Zeitfenster rollen ab dem jeweiligen Anforderungszeitpunkt. Wiederholte Downloads derselben fertigen Datei verbrauchen kein weiteres Erstellungskontingent. Fehlgeschlagene Erstellungen zählen nicht gegen diese Limits.

Jede Teilsicherung enthält Änderungen und Löschungen seit der letzten vollständig übertragenen und per Prüfsumme bestätigten Sicherung. Die Kette lautet A + B + C: A ist die Vollsicherung, B enthält Änderungen seit A, C nur die weiteren Änderungen seit B. Zum Rekonstruieren wendest du alle Pakete der Reihe nach an. Unveränderte Anhänge verweisen auf eine bereits vorhandene Datei in dieser Kette.

Ein Download steht 24 Stunden ab Fertigstellung bereit. Danach wird die ZIP-Datei entfernt, die Historie bleibt erhalten. Bewahre die Vollsicherung und alle zugehörigen Teilsicherungen lokal auf. Der Vergleichsstand bleibt höchstens 90 Tage ab Vollsicherung nutzbar; danach ist eine neue Vollsicherung nötig. Jedes Incremental nennt ID und SHA-256 sowohl der Vollsicherung als auch des direkten Vorgängers.

Erst ein vollständig empfangenes und bestätigtes Paket wird zum neuen Vorgänger. Solange eine Teilsicherung zum Download bereitsteht und nicht bestätigt wurde, ist die nächste Teilsicherung gesperrt. Ist ein unbestätigtes Paket abgelaufen, startet der nächste Versuch wieder vom letzten bestätigten Stand und umfasst auch die noch nicht gesicherten Änderungen. Fehlt ein bereits bestätigter Teil lokal, lade ihn innerhalb seiner 24 Stunden erneut herunter oder beginne mit einer neuen Vollsicherung unter Beachtung des Wochenlimits. Nutze möglichst ein gemeinsames Backup-Verzeichnis je Firma; mehrere unabhängige Clients müssen dieselbe vollständige Kette besitzen.

API-Schlüssel einrichten

Gib unter API-Schlüssel einen Namen wie „Firmen-NAS“ ein und erstelle den Schlüssel. Er wird einmal angezeigt, gilt ein Jahr und kann jederzeit widerrufen werden. Speichere ihn im geschützten Secret-Speicher deiner Backup-Umgebung. Der Schlüssel gehört der Firma und darf ausschließlich deren Backup-API verwenden. Er läuft unabhängig von der späteren Anmeldung seines Erstellers.

Sende ihn über HTTPS im Header Authorization: Bearer YOUR_BACKUP_TOKEN. Schlüssel gehören weder in URLs noch in öffentliche Skripte oder Protokolle. Nur Firmenadmins und Inhaber dürfen Schlüssel erstellen, einsehen und widerrufen.

Python: Vollsicherung und Teilsicherungen herunterladen

Lade den Python-Client company_backup.py herunter und lege ihn neben dein Skript. Er benötigt Python 3.10 oder neuer unter Linux oder macOS und ausschließlich die Standardbibliothek. Hinterlege SKAVA_BACKUP_TOKEN in der geschützten Prozessumgebung und ersetze 42 durch die ID deiner Firma aus der Webapp-Adresse.

import os
from company_backup import BackupClient

client = BackupClient("https://chat.skava.io", 42,
                      os.environ["SKAVA_BACKUP_TOKEN"])
full = client.backup("full", "backups")  # once every 7 days
# Later, up to twice in a rolling 24-hour window:
diff = client.backup("diff", "backups")

Für geplante Jobs kannst du denselben Client direkt aufrufen:

python3 company_backup.py --company 42 --kind full --directory backups
python3 company_backup.py --company 42 --kind diff --directory backups

Der Client fordert die Erstellung an, fragt den Status ab, lädt die Datei auf die Festplatte, prüft Größe, SHA-256 und ZIP-Inhalt und bestätigt den Empfang. Er speichert Vollsicherung und Differenzen als getrennte Dateien. Behalte auch die versteckte Zustandsdatei im Verzeichnis: Sie enthält die Sicherungskette und Wiederaufnahmeinformationen. Vor jedem Incremental prüft der Client alle bisherigen ZIP-Dateien auf Vollständigkeit und Prüfsumme. Nach einem Abbruch wiederholst du denselben Befehl. Gleichzeitig gestartete Jobs für dieselbe Firma im selben Verzeichnis werden verhindert.

API-Ablauf ohne dauerhafte Verbindung

1. Anfordern: POST /api/v1/companies/42/backups mit {"kind":"full","request_id":"YOUR_UNIQUE_ID"}. Für Differenzen sende kind als diff die lokale Vollsicherungs-ID als base_id und die zuletzt bestätigte Paket-ID als parent_id. Die Antwort liefert job.id. Verwende bei Wiederholung dieselbe request_id.
2. Status abfragen: GET /api/v1/companies/42/backups/JOB_ID, ungefähr alle zehn Sekunden. Während queued oder running läuft die Erstellung im Hintergrund. Dazwischen besteht keine offene Verbindung.
3. Herunterladen: Bei ready und available: true rufst du GET /api/v1/companies/42/backups/JOB_ID/download auf. Nur dieser Transfer hält eine Verbindung. Bei einem Abbruch wird die komplette Datei erneut geladen.
4. Empfang bestätigen: Prüfe job.bytes und job.sha256. Übernimm die Download-Header X-Backup-Download-Id und X-Backup-Receipt. Sende POST /api/v1/companies/42/backups/JOB_ID/downloads/DOWNLOAD_ID/confirm mit {"receipt":"RECEIPT","bytes":12345,"sha256":"SHA256"}. Ohne vollständigen Transfer und passende Bestätigung gilt der Download nicht als erfolgreich.

GET /api/v1/companies/42/backups liefert die Historie mit Seitennavigation über next_offset. Bei ausgeschöpftem Kontingent oder vorübergehender Auslastung antwortet die API mit HTTP 429 und Retry-After. Die Sicherungen werden begrenzt nacheinander erstellt, damit zeitgleiche Nachtjobs die Anwendung nicht überlasten.

Downloadhistorie verstehen

Die Historie zeigt Vollsicherung oder Teilsicherung, Anforderung, Ablaufdatum, Vollsicherung, Vorgänger und jeden Downloadversuch mit übertragenen Bytes. „Bereit“ bezeichnet die fertige Datei. „Übertragen“ bedeutet, dass der Server alle Bytes gesendet hat. „Prüfsumme bestätigt“ bedeutet, dass der Client den vollständigen Empfang geprüft und bestätigt hat. Abgebrochene und fehlgeschlagene Versuche bleiben sichtbar.

Die Webapp prüft den Empfang im Browser vor dem Speichern-Dialog. Diese Bestätigung belegt nicht, dass die Datei anschließend dauerhaft auf deinem Rechner gespeichert wurde. Für automatisierte Sicherungen schreibt der Python-Client die Datei auf die Festplatte, bevor er den Empfang bestätigt. Webapp-Downloads sind auf 64 MiB begrenzt; größere Archive lädst du mit dem Python-Client.