Archivierung, Backup und Wiederherstellung¶

1. Umfang und Verantwortung¶

FLEET Mira archiviert Tachodaten und Finanzbelege zuerst vollständig lokal. Das lokale Primärarchiv ist die führende Quelle; ein externes Backup ist optional und schaltet keine Fachfunktion frei.

archive_dir enthält unveränderte, komprimierte Tachographenoriginale.
financial_archive_dir enthält Originale und Manifeste von Fremd- und E-Rechnungen.
document_archive neben der Datenbank enthält Originale und Manifeste der Personal- und Fahrzeugakten.
SQLite speichert Metadaten, Verknüpfungen, Status und Auditdaten.
Ein Backupziel enthält nur nachgelagerte, verifizierte Replikate und Datenbanksnapshots.

Ohne Backupziel bleiben Import, Anzeige, Auswertung, Prüfung, Buchung und Export vollständig verfügbar. Remoteänderungen werden nie automatisch in das lokale Primärarchiv zurücksynchronisiert.

2. Primärarchiv und Backupstruktur¶

Die lokalen Primärarchive verwenden getrennte konfigurierbare Pfade:

archive_dir/
  YYYY/MM/<Archiv-ID>.ddd.gz

financial_archive_dir/
  YYYY/<Rechnungs-ID>/<Dokument-ID>/
    original.<ext>
    manifest.json

Ein optionales Backupziel verwendet weiterhin das kompatible Präfix:

DLTNG/<Installations-ID>/
  archives/YYYY/MM/<Archiv-ID>.ddd.gz[.enc]
  financial-documents/YYYY/<Rechnungs-ID>/<Dokument-ID>_<sha256>.<ext>[.enc]
  documents/YYYY/<personal|vehicle>/<Akten-ID>/<Dokument-ID>_<sha256>.<ext>[.enc]
  manifests/...
  database/YYYY/MM/archive_YYYY-MM-DD_HHmmssZ.db.gz[.enc]

DLTNG wird nicht umbenannt, damit Bestandsobjekte erreichbar bleiben. Primärarchiv und Backupziel dürfen nicht auf denselben aufgelösten Pfad zeigen.

3. Statusmodell¶

Archivstatus und Backupstatus sind unabhängig.

Archivstatus	Bedeutung
`STAGING`	lokale, noch nicht bestätigte Ablage läuft
`LOCAL_VERIFIED`	lokales Original wurde vollständig zurückgelesen und per SHA-256 verifiziert
`LOCAL_MISSING`	erwartetes lokales Original fehlt
`LOCAL_CORRUPT`	lokale Größe oder Prüfsumme stimmt nicht
`REMOVED_AFTER_RETENTION`	Original wurde nach Aufbewahrungsprüfung administrativ entfernt

Backupstatus	Bedeutung
`NOT_CONFIGURED`	kein aktives Backupziel; kein fachlicher Fehler
`PENDING`	dauerhafter Backupauftrag vorhanden
`UPLOADING`	Transfer aktiv
`VERIFIED`	Backupobjekt wurde vollständig zurückgelesen und verifiziert
`FAILED`	Fehler protokolliert; Wiederholung möglich
`REMOTE_MISSING`	zuvor verifiziertes Backupobjekt fehlt

LOCAL_VERIFIED ist die Voraussetzung für Fachfunktionen. backup_status beschreibt ausschließlich die zusätzliche Sicherung.

4. Archivierungs- und Backupablauf¶

flowchart TD
    A["Import: DDD, Fremdbeleg oder E-Rechnung"] --> B{"Dokumentart"}

    B -->|"Tachodaten"| C["DDD lokal komprimieren und Original-/Speicherhash bilden"]
    B -->|"Fremdrechnung"| D["Originalbeleg im lokalen Finanzarchiv ablegen"]
    B -->|"XRechnung"| E["Original, strukturiertes XML und Prüfbericht vorbereiten"]

    C --> F["Datei und Manifest lokal rücklesen und prüfen"]
    D --> F
    E --> F

    F --> G{"Lokale Prüfung erfolgreich?"}
    G -->|"Nein"| H["Import abbrechen, temporäre Objekte bereinigen und Fehler auditieren"]
    G -->|"Ja"| I["Metadaten, Verknüpfungen und Audit in SQLite bestätigen"]

    I --> J["Status LOCAL_VERIFIED"]
    J --> K["Anzeige, Auswertung, Prüfung, Buchung und Export verfügbar"]
    J --> L{"Externes Backup konfiguriert?"}

    L -->|"Nein"| M["Vollständiger lokaler Betrieb"]
    L -->|"Ja"| N["Backupauftrag dauerhaft einreihen"]
    N --> O["Optional verschlüsseln und zum Ziel übertragen"]
    O --> P["Backup vollständig zurücklesen und Hash prüfen"]
    P --> Q{"Backupprüfung erfolgreich?"}
    Q -->|"Ja"| R["Backupstatus VERIFIED und Audit"]
    Q -->|"Nein"| S["Backupstatus FAILED und automatische Wiederholung"]

    S --> K
    R --> K

Jeder Import wird zuerst vollständig lokal archiviert.
DDD-Dateien behalten ihre GZIP-Ablage; Finanz- und E-Rechnungsbelege erhalten Original und Manifest im Finanzarchiv.
Erst eine erfolgreiche lokale Rücklese- und Hashprüfung erzeugt LOCAL_VERIFIED.
LOCAL_VERIFIED schaltet sämtliche Fachfunktionen frei.
Ohne Backupziel endet der Ablauf erfolgreich im lokalen Betrieb.
Mit Backupziel wird asynchron eine zusätzliche Kopie erstellt.
Backupfehler ändern nur den Backupstatus und blockieren keine lokal verifizierten Dokumente.
Lokale Originale werden nach erfolgreicher Sicherung nicht gelöscht.
Bei Verlust oder Beschädigung kann ein verifiziertes Backup das lokale Primärarchiv wiederherstellen.

5. Abläufe nach Dokumentart¶

Tachodaten¶

DDD-Dateien werden unter archive_dir lokal komprimiert. Original- und Speicherhash, Archiv-ID, Quelle und Audit werden in SQLite gespeichert. Suche, Analyse, Export und logisches Löschen arbeiten ohne Backupziel. Die bestehende Ablagestruktur wird nicht migriert.

Fremdrechnungen¶

Originalbelege werden unter financial_archive_dir atomar mit Manifest abgelegt und zurückgelesen. Prüfung, Buchung, Vorschau und FiBu-Export verlangen einen lokal verifizierten Originalbeleg, nicht ein Cloudobjekt. Aufbewahrung und Legal Hold gelten für das lokale Original und dessen Manifest.

XML-XRechnung und Hybrid-PDF¶

Der Import bereitet Empfangsoriginal, bei Hybrid-PDF das eingebettete XML und den Validierungsbericht gemeinsam vor. Erst wenn alle erforderlichen Objekte lokal verifiziert sind, werden Rechnung, Positionen, Zuordnungen und Dokumentverweise bestätigt. Ein Fehler entfernt temporäre Objekte und lässt keine Teilrechnung zurück.

6. Backupziel einrichten¶

Zielunabhängiges Quick Backup¶

Basic und Pro können unter Administration → Sicherungen → Quick Backup jederzeit eine konsistente SQLite-Datenbanksicherung als lokale ZIP-Datei erstellen. Das ZIP enthält archive.db und ein Manifest mit SHA-256, Größe und Prüfergebnis. Dafür ist kein Backupziel erforderlich.

Das Quick Backup enthält keine DDD-, PDF-, Finanz- oder Dokumentarchive. Für eine vollständige Sicherung müssen deshalb zusätzlich die konfigurierten Archivordner kopiert oder die nachfolgend beschriebene Pro-Sicherung verwendet werden.

Unter Administration → Backups kann genau ein aktives Ziel eingerichtet werden:

LOCAL_FILESYSTEM: zweites lokales Laufwerk oder UNC-/NAS-Freigabe;
HTTPS-WebDAV;
Google Drive.

Der Assistent prüft Erreichbarkeit, Schreibrecht, Upload, vollständiges Rücklesen und SHA-256. Für LOCAL_FILESYSTEM muss das Ziel physisch oder administrativ vom Primärarchiv getrennt sein. HTTP-WebDAV wird abgewiesen. Google Drive verwendet drive.file; OAuth-Tokens werden DPAPI-geschützt.

Clientseitige AES-256-GCM-Verschlüsselung ist eine Eigenschaft des Backupziels. Das lokale Primärarchiv wird über Windows-, Volume- und Dateisystemschutz abgesichert. Ein exportierter Recovery-Key muss separat und offline verwahrt werden.

7. Optionales Backup und Wiederholung¶

Nach LOCAL_VERIFIED wird bei aktivem Ziel ein dauerhafter Auftrag erzeugt. Das Objekt wird optional verschlüsselt, übertragen, vollständig zurückgelesen und geprüft. Erst danach gilt der Backupstatus als VERIFIED.

Wiederholungen erfolgen nach 1, 5, 15 und 60 Minuten, danach höchstens alle sechs Stunden. Ein Neustart setzt offene Aufträge fort. Abweichender Inhalt unter derselben Objekt-ID ist ein Konflikt und wird nicht überschrieben.

Die Taskoption Externes Backup vor Löschen an der Quelle abwarten verschiebt bei Tachodaten mark_processed und die Löschung am Terminal bis VERIFIED. Ohne aktives Ziel ist die Option deaktiviert. Im Standardbetrieb beendet die lokale Archivierung den Download; das Backup folgt asynchron.

8. Datenbanksnapshots¶

Snapshots werden standardmäßig täglich um 02:00 UTC erstellt:

konsistente Datei über die SQLite Backup API erzeugen;
PRAGMA integrity_check ausführen;
SHA-256 bilden und GZIP komprimieren;
optional verschlüsseln;
zum aktiven Dateisystem-, WebDAV- oder Google-Drive-Ziel übertragen und zurückprüfen.

Die Retention behält 30 Tagesstände und einen Monatsstand für 12 Monate. Automatisch gelöscht werden nur abgelaufene Datenbanksnapshots, nie DDD- oder Finanzarchivobjekte.

9. Migration bestehender Cloudbelege¶

Bestehende Belege ohne lokales Original werden automatisch und wiederaufnehmbar migriert:

vorhandene Spooldateien anhand des gespeicherten SHA-256 übernehmen;
ausschließlich remote vorhandene Originale herunterladen und gegebenenfalls entschlüsseln;
Größe und Originalhash prüfen;
Original und Manifest atomar unter financial_archive_dir ablegen;
LOCAL_VERIFIED und Audit setzen.

Fehler werden als LOCAL_MISSING oder LOCAL_CORRUPT sichtbar. Altbelege bleiben bis zur Migration remote lesbar; fachliche Verarbeitung setzt die erfolgreiche lokale Übernahme voraus. Der Administrationsbereich zeigt Gesamtzahl, migriert, ausstehend und fehlerhaft.

10. Einzelobjekt wiederherstellen¶

Objekt und verifiziertes Backup auswählen.
Adminberechtigung und Pflichtgrund bestätigen.
Backup in eine temporäre Datei laden.
Backuphash prüfen, gegebenenfalls entschlüsseln und Originalhash prüfen.
In das erwartete lokale Primärarchiv atomar verschieben.
Lokales Objekt erneut vollständig lesen und verifizieren.
Erst danach Archiv- und Backupstatus abgleichen und den Restore auditieren.

Ein Fehler lässt vorhandene lokale Objekte unverändert und entfernt Teildateien. Eine logisch gelöschte Fachzeile wird nicht automatisch reaktiviert.

11. Datenbankrestore¶

flowchart TD
    A["Snapshot auswählen"] --> B["Temporär vom Backupziel lesen"]
    B --> C["Hash prüfen, entschlüsseln und dekomprimieren"]
    C --> D["SQLite integrity_check"]
    D --> E["Scheduler und Writer stoppen"]
    E --> F["Sicherheitskopie der aktuellen DB"]
    F --> G["Datenbank atomar ersetzen"]
    G --> H["Anwendung neu starten und Migrationen ausführen"]
    H --> I["Primärarchive und Backupstatus abgleichen"]

Kann die Liveverbindung nicht sicher geschlossen werden, wird der Austausch für den Neustart vorgemerkt. Eine fehlgeschlagene Vorprüfung schreibt keinen Austauschauftrag.

12. Vollständige Notfallwiederherstellung¶

kompatible FLEET-Mira-Version isoliert installieren;
Backupziel ohne normale Importe konfigurieren;
gegebenenfalls Recovery-Key bereitstellen;
Datenbanksnapshot wiederherstellen und prüfen;
DDD-Primärarchiv und Finanzprimärarchiv aus den Manifesten rekonstruieren;
alle komprimierten/dekomprimierten DDD-Hashes und Dokument-SHA-256 prüfen;
Datenbankverknüpfungen, lokale Archivstatus, Backupstatus, Retention und Audit abgleichen;
C-/M-Auswertung, Anmeldung, Fremdrechnung und XRechnung repräsentativ testen;
Freigabe vor Produktivumschaltung dokumentieren.

13. Zielwechsel, Berechtigungen und Audit¶

Ein Ziel kann nicht gelöscht werden, solange Aufbewahrungsobjekte darauf verweisen. Beim Zielwechsel werden Objekte kopiert, zurückgelesen und verifiziert; Referenzen ändern sich erst nach Erfolg. Das alte Ziel bleibt bis zur Freigabe des Abgleichberichts erhalten.

backup.read: Status lesen;
backup.run: Aufträge wiederholen und prüfen;
backup.manage: Ziele und Verschlüsselung verwalten;
backup.restore: Objekte wiederherstellen.

Zieländerungen, Verbindungstests, Key-Exportbestätigungen, Fehler, Snapshots, Retentionslöschungen, Migrationen und Restores werden ohne Secrets, Tokens oder Schlüssel auditiert.

14. Betriebscheckliste¶

täglich: Erreichbarkeit und freier Speicher der Primärarchive, lokale Integritätsfehler, Backupstau und letzter Datenbanksnapshot;
wöchentlich: Zielerreichbarkeit, Quota, Authentifizierung und zufällige Hashprüfung;
monatlich: Datenbankretention, Vollständigkeit des Finanzarchivs und Migrationsfortschritt;
vierteljährlich: isolierter Restore von Datenbank, DDD-Archiv und Finanzarchiv;
nach Pfad-, Credential-, Ziel- oder Versionsänderung: Verbindungstest und Sofortsnapshot;
bei Incident: Logs und Audit sichern und die letzte gültige Datenbank nicht überschreiben.

Diese Mechanismen unterstützen Integrität, Nachvollziehbarkeit und Aufbewahrung. Eine formale GoBD-Konformität hängt zusätzlich von Betrieb, Berechtigungen und Verfahrensdokumentation ab.