Skip to content

Archiving, backup and restore

1. Scope and responsibility

FLEET Mira archives tachograph data and financial documents locally before performing any backup. The local primary archive is authoritative; an external backup is optional and does not enable business functions.

  • archive_dir contains immutable compressed tachograph originals.
  • financial_archive_dir contains originals and manifests for supplier invoices and e-invoices.
  • document_archive beside the database contains originals and manifests for personnel and vehicle records.
  • SQLite stores metadata, relationships, statuses and audit data.
  • A backup target contains only downstream verified replicas and database snapshots.

Import, display, analysis, verification, booking and export remain fully available without a backup target. Remote changes are never synchronised automatically into the local primary archive.

2. Primary archive and backup layout

The local primary archives use separate configurable paths:

archive_dir/
  YYYY/MM/<archive-id>.ddd.gz

financial_archive_dir/
  YYYY/<invoice-id>/<document-id>/
    original.<ext>
    manifest.json

An optional backup target continues to use the compatible prefix:

DLTNG/<installation-id>/
  archives/YYYY/MM/<archive-id>.ddd.gz[.enc]
  financial-documents/YYYY/<invoice-id>/<document-id>_<sha256>.<ext>[.enc]
  documents/YYYY/<person|vehicle>/<record-id>/<document-id>_<sha256>.<ext>[.enc]
  manifests/...
  database/YYYY/MM/archive_YYYY-MM-DD_HHmmssZ.db.gz[.enc]

DLTNG is not renamed so existing objects remain reachable. The primary archive and backup target must not resolve to the same path.

3. Status model

Archive status and backup status are independent.

Archive status Meaning
STAGING local storage has not yet been confirmed
LOCAL_VERIFIED the local original was fully read back and SHA-256 verified
LOCAL_MISSING the expected local original is missing
LOCAL_CORRUPT local size or checksum does not match
REMOVED_AFTER_RETENTION an administrator removed the original after retention review
Backup status Meaning
NOT_CONFIGURED no active target; not a business error
PENDING a durable backup job exists
UPLOADING transfer is active
VERIFIED the backup object was fully read back and verified
FAILED a retryable failure was recorded
REMOTE_MISSING a previously verified backup object is missing

LOCAL_VERIFIED is the prerequisite for business functions. backup_status describes only the additional copy.

4. Archiving and backup flow

flowchart TD
    A["Import: DDD, supplier document or e-invoice"] --> B{"Document type"}

    B -->|"Tachograph data"| C["Compress DDD locally and calculate original/stored hashes"]
    B -->|"Supplier invoice"| D["Store original in the local financial archive"]
    B -->|"XRechnung"| E["Prepare original, structured XML and validation report"]

    C --> F["Read back and verify local file and manifest"]
    D --> F
    E --> F

    F --> G{"Local verification successful?"}
    G -->|"No"| H["Abort import, clean temporary objects and audit the error"]
    G -->|"Yes"| I["Commit metadata, relationships and audit to SQLite"]

    I --> J["Status LOCAL_VERIFIED"]
    J --> K["Display, analysis, verification, booking and export available"]
    J --> L{"External backup configured?"}

    L -->|"No"| M["Complete local operation"]
    L -->|"Yes"| N["Persist backup job"]
    N --> O["Optionally encrypt and transfer to target"]
    O --> P["Read back complete backup and verify hash"]
    P --> Q{"Backup verification successful?"}
    Q -->|"Yes"| R["Backup status VERIFIED and audit"]
    Q -->|"No"| S["Backup status FAILED and automatic retry"]

    S --> K
    R --> K
  1. Every import is archived locally first.
  2. DDD files retain their GZIP layout; financial and e-invoice documents receive an original and manifest in the financial archive.
  3. Only successful local read-back and hash verification produces LOCAL_VERIFIED.
  4. LOCAL_VERIFIED enables every business function.
  5. Without a backup target, the workflow completes successfully in local mode.
  6. With a target, an additional copy is created asynchronously.
  7. Backup failures change only backup status and do not block locally verified documents.
  8. Local originals are not deleted after successful backup.
  9. A verified backup can restore the local primary archive after loss or corruption.

5. Document-specific flows

Tachograph data

DDD files are compressed locally under archive_dir. Original and stored hashes, archive ID, source and audit are stored in SQLite. Search, analysis, export and logical deletion work without a backup target. The existing layout is not migrated.

Supplier invoices

Original documents are stored atomically with a manifest under financial_archive_dir and read back. Verification, booking, preview and accounting export require a locally verified original rather than a cloud object. Retention and legal hold apply to the local original and manifest.

XML XRechnung and hybrid PDF

Import prepares the received original, embedded XML for a hybrid PDF, and validation report as one unit. Invoice, lines, allocations and document relationships are committed only after every required object is locally verified. Failure removes temporary objects and leaves no partial invoice.

6. Configure a backup target

Target-independent Quick Backup

Basic and Pro can create a consistent SQLite database backup as a local ZIP at any time under Administration → Backups → Quick Backup. The ZIP contains archive.db and a manifest with SHA-256, size and verification result. No backup target is required.

Quick Backup does not contain DDD, PDF, financial or record-document archives. A complete backup must therefore also copy the configured archive directories or use the Pro backup described below.

Exactly one active target can be configured under Administration → Backups:

  • LOCAL_FILESYSTEM: a second local drive or UNC/NAS share;
  • HTTPS WebDAV;
  • Google Drive.

The wizard tests availability, write access, upload, complete read-back and SHA-256. A LOCAL_FILESYSTEM target must be physically or administratively separate from the primary archive. HTTP WebDAV is rejected. Google Drive uses drive.file; OAuth tokens are DPAPI-protected.

Client-side AES-256-GCM encryption is a backup-target property. The local primary archive is protected through Windows, volume and filesystem controls. An exported recovery key must be stored separately and offline.

7. Optional backup and retry

After LOCAL_VERIFIED, an active target receives a durable job. The object is optionally encrypted, transferred, fully read back and checked. Only then is backup status VERIFIED.

Retries occur after 1, 5, 15 and 60 minutes and then no more often than every six hours. A restart resumes pending jobs. Different content under the same object ID is a conflict and is not overwritten.

The task option Wait for external backup before deleting at source defers tachograph mark_processed and terminal deletion until VERIFIED. It is disabled without an active target. In standard mode, local archiving completes the download and backup follows asynchronously.

8. Database snapshots

Snapshots run daily at 02:00 UTC by default:

  1. create a consistent file through the SQLite Backup API;
  2. run PRAGMA integrity_check;
  3. calculate SHA-256 and GZIP compress;
  4. optionally encrypt;
  5. transfer to the active filesystem, WebDAV or Google Drive target and read it back.

Retention keeps 30 daily snapshots and one monthly snapshot for 12 months. Only expired database snapshots are deleted automatically, never DDD or financial archive objects.

9. Migrate existing cloud documents

Existing documents without a local original are migrated automatically and resumably:

  1. adopt existing spool files after checking stored SHA-256;
  2. download and, where necessary, decrypt remote-only originals;
  3. verify size and original hash;
  4. atomically store original and manifest under financial_archive_dir;
  5. set LOCAL_VERIFIED and audit the migration.

Failures become visible as LOCAL_MISSING or LOCAL_CORRUPT. Legacy documents remain remotely readable until migration; business processing requires successful local adoption. Administration shows total, migrated, pending and failed counts.

10. Restore one object

  1. Select the object and a verified backup.
  2. Confirm administrative permission and required reason.
  3. Read the backup into a temporary file.
  4. Verify backup hash, decrypt where necessary and verify the original hash.
  5. Atomically move it into the expected local primary archive.
  6. Fully read and verify the restored local object.
  7. Only then reconcile archive and backup statuses and audit the restore.

Failure leaves existing local objects unchanged and removes partial files. A logically deleted business row is not reactivated automatically.

11. Database restore

flowchart TD
    A["Select snapshot"] --> B["Read temporarily from backup target"]
    B --> C["Verify hash, decrypt and decompress"]
    C --> D["SQLite integrity_check"]
    D --> E["Stop schedulers and writers"]
    E --> F["Create safety copy of current DB"]
    F --> G["Atomically replace database"]
    G --> H["Restart application and run migrations"]
    H --> I["Reconcile primary archives and backup status"]

Database replacement is staged for restart if the live connection cannot be closed safely. Failed preflight validation does not create a replacement request.

12. Full disaster recovery

  1. Install a compatible FLEET Mira version in isolation.
  2. Configure the backup target without starting normal imports.
  3. Supply the recovery key where necessary.
  4. Restore and verify the database snapshot.
  5. Reconstruct the DDD and financial primary archives from manifests.
  6. Verify all compressed/decompressed DDD hashes and document SHA-256 values.
  7. Reconcile database relationships, local archive status, backup status, retention and audit.
  8. Test representative C/M analysis, sign-in, supplier invoice and XRechnung workflows.
  9. Document approval before production cutover.

13. Target change, permissions and audit

A target cannot be deleted while retained objects reference it. Target change copies, reads back and verifies objects; references change only after success. Keep the old target until the reconciliation report is approved.

  • backup.read: read status;
  • backup.run: retry and verify jobs;
  • backup.manage: manage targets and encryption;
  • backup.restore: restore objects.

Target changes, connection tests, key-export confirmations, failures, snapshots, retention deletion, migration and restore are audited without secrets, tokens or keys.

14. Operational checklist

  • daily: primary archive availability and free space, local integrity errors, backup backlog and latest database snapshot;
  • weekly: target availability, quota, authentication and random hash verification;
  • monthly: database retention, financial archive completeness and migration progress;
  • quarterly: isolated restore of database, DDD archive and financial archive;
  • after path, credential, target or version changes: connection test and immediate snapshot;
  • incident: preserve logs and audit and do not overwrite the last known-good database.

These mechanisms support integrity, traceability and retention. Formal GoBD compliance additionally depends on operations, permissions and procedural documentation.