Steuerberater-Kanzleien sind im Datenschutz-Sinn eine der konservativsten Branchen: Mandantenakten unterliegen dem Berufsgeheimnis (§ 203 StGB), die Buchhaltungsdaten den GoBD-Anforderungen und der DSGVO, und im Schadensfall haftet die Kanzlei persönlich. Eine Storage-Architektur, die im Mittelstand “gut genug” ist, ist hier oft schon zu wenig.

Wir werden bei DATAZONE häufig gefragt, ob TrueNAS allein “GoBD-konform” sei. Die kurze Antwort: Nein — denn GoBD ist kein Storage-Feature, sondern eine Kombination aus Prozess, Software und Storage. Die längere Antwort: TrueNAS liefert mehrere technische Bausteine, die zusammen mit einer ordentlichen Buchhaltungssoftware und einem dokumentierten Prozess das ergeben, was eine Betriebsprüfung erwartet.

Dieser Artikel zeigt, welche GoBD-Anforderungen TrueNAS unterstützt, welche Lücken bleiben und wie eine typische Kanzlei-Architektur aussieht.

Was die GoBD verlangen — sehr kurz

Die “Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff” sind das BMF-Schreiben, das die elektronische Buchführung regelt. Vier Kernanforderungen interessieren uns für die Storage-Architektur:

Unveränderbarkeit — Einmal gebuchte Datensätze dürfen nicht mehr verändert werden, ohne dass die Änderung protokolliert wird
Vollständigkeit — Es darf nichts verloren gehen
Nachvollziehbarkeit / Nachprüfbarkeit — Eine Betriebsprüfung muss die Daten lesen und prüfen können
Aufbewahrungsfrist 10 Jahre für Buchungsbelege, Jahresabschlüsse, Inventare und vergleichbare Unterlagen

Daraus leiten sich für die Storage-Seite konkrete Bedürfnisse ab: WORM-Eigenschaft (Write Once, Read Many) bzw. Unveränderbarkeit der gespeicherten Datensätze, integritätsgesicherte Aufbewahrung über zehn Jahre, Wiederherstellbarkeit im Zugriffsfall durch die Finanzverwaltung.

Wichtig: GoBD-Konformität ist nie ein Eigenschaft des Storage-Systems allein. Sie ist eine Eigenschaft des Gesamtsystems aus Buchhaltungssoftware (DATEV, Lexware, Sage etc.), Archivierungslösung (DATEV-DMS, ELO, d.velop documents etc.) und Storage. Der Prüfer testet, ob Buchungsdaten unveränderbar sind, nachdem sie festgeschrieben wurden — nicht, wie viele Snapshots ZFS hält.

Was TrueNAS technisch beiträgt

1. ZFS-Snapshots — read-only by default

ZFS-Snapshots sind nach Erstellung nicht beschreibbar. Ein Snapshot eines Datasets vom 31.12.2026 stellt den Zustand zu diesem Zeitpunkt dar. Auch ein Admin mit Vollrechten kann den Snapshot nicht verändern — er kann ihn nur löschen. Wenn das Löschen administrativ beschränkt ist (z.B. durch dedizierten Snapshot-Admin, Audit-Logging und Vier-Augen-Prinzip), bleibt der Snapshot in der Form, in der er entstanden ist.

Konkret heißt das für ein Buchhaltungs-Dataset:

tank/datev
  ├── @auto-daily-2026-12-31 (read-only, 10 Jahre Hold)
  ├── @auto-daily-2026-12-30
  └── ...

Mit einem Snapshot-Hold auf den Jahresend-Snapshot ist eine Löschung auch durch Admin-Befehle blockiert, solange der Hold besteht.

2. ZFS-Integrität (Checksums + Scrub)

Jeder Datenblock in ZFS hat eine SHA-256- oder Fletcher-Checksumme. Bei jedem Lesevorgang prüft ZFS, ob der Block noch zur Checksumme passt. Bei Mirror- oder RAIDZ-Pools repariert ZFS einen erkannten Bit-Rot automatisch aus der Redundanz.

Ein periodischer Scrub (Standard bei TrueNAS: monatlich oder zweiwöchentlich) liest den kompletten Pool und prüft jeden Block. Damit ist sichergestellt, dass über zehn Jahre Lagerung kein “schleichender” Datenverlust auftritt, der erst beim Zugriff sichtbar wird.

Für Steuerberater-Datasets empfehlen wir wöchentliche Scrubs und monatliche Reports an die IT-Verantwortlichen.

3. Replikation in zweites System

Eine zweite Kopie auf einem zweiten TrueNAS-System ist Pflicht. TrueNAS bietet native ZFS-Replikation via zfs send/recv, die

inkrementell läuft (nach Erst-Sync nur Block-Deltas)
verschlüsselt übertragen wird (über SSH)
die Read-only-Eigenschaft der Snapshots am Ziel erhält

Klassisches Setup: Primärsystem im Kanzlei-Serverraum, Sekundärsystem im Rechenzentrum eines Kollegen oder bei einem Co-Location-Anbieter. Die Replikation läuft täglich, die Snapshot-Retention am Ziel ist deutlich länger als am Quellsystem.

4. Access-Audits

TrueNAS schreibt Zugriffe in das Audit-Log — wer hat sich angemeldet, welche Datasets wurden geändert, welche API-Calls wurden ausgeführt. Für GoBD-Zwecke ist das interessant, weil Manipulationen am Snapshot-Bestand (Löschen, Hold entfernen) protokolliert werden. Bei einer Prüfung lässt sich nachweisen, dass keine Schwärzung der Historie stattgefunden hat.

Audit-Logs sollten ihrerseits an einen externen Log-Server (Syslog, Wazuh, Graylog) gehen — sonst wäre der Admin in der Lage, seine eigenen Spuren zu verwischen.

5. SMB mit ACL-Trennung

In einer Kanzlei werden Mandantenakten typischerweise per SMB freigegeben. TrueNAS unterstützt Windows-ACLs vollständig — das heißt: Pro Mandantenakte können konkrete Zugriffsrechte für definierte Mitarbeiter gesetzt werden. Das ist nicht GoBD-spezifisch, aber berufsrechtlich (Berufsgeheimnis nach § 203 StGB) entscheidend.

Was TrueNAS nicht abdeckt

Damit klar ist, was eine ergänzende Lösung leisten muss:

Anforderung	TrueNAS allein?	Was zusätzlich nötig ist
Buchungsdatenfestschreibung	Nein	DATEV / Lexware / Sage — Festschreibung im Buchhaltungssystem
Belegarchiv mit Aufbewahrungs-Lifecycle	Nein	DMS wie DATEV-DMS, ELO, d.velop documents
Verfahrensdokumentation (Pflicht!)	Nein	Schriftliche Doku, regelmäßig aktualisiert
Datenzugriff-Z3-Schnittstelle für Prüfer	Nein	Buchhaltungs-/DMS-Export — TrueNAS liefert nur die Datei
Berechtigungs-Konzept der Kanzlei	Teilweise	Organisatorische Doku + technische ACLs auf TrueNAS

Storage ist die Aufbewahrungsschicht unter dem GoBD-Stack. Was darüber liegt — Buchhaltung und Archivierung — bestimmt, ob “GoBD-konform” abgehakt ist.

Architektur-Vorschlag für eine mittelgroße Kanzlei

Für eine Kanzlei mit 5–25 Mitarbeitenden, eigenem Serverraum und Anbindung an ein Backup-RZ schlagen wir folgende Architektur vor:

Primärsystem: TrueNAS Mini X+ oder R-Serie

Zwei Pools: tank-mandate (Mandanten-Akten, SMB-Freigabe) und tank-buchhaltung (DATEV-Datenbank, iSCSI an den DATEV-Server)
Snapshot-Plan auf tank-buchhaltung: 4-stündlich (3 Tage), täglich (30 Tage), wöchentlich (12 Wochen), monatlich (12 Monate), jährlich (11 Jahre, mit Hold)
Snapshot-Plan auf tank-mandate: täglich (90 Tage), monatlich (60 Monate), jährlich (11 Jahre, mit Hold)
Wöchentlicher Scrub mit Mail-Report

Replikation: TrueNAS Mini X+ am zweiten Standort

Über VPN/WireGuard zum Backup-Standort
Replikation alle 4 Stunden, Read-only-Snapshots am Ziel
Andere Admin-Credentials als am Primärsystem (Wichtig: Ein kompromittierter Kanzlei-Admin darf das Replikat nicht zerstören können)

Belegarchiv: ELO / DATEV-DMS / d.velop documents

Belege landen aus dem Scan-Workflow direkt im DMS
DMS schreibt verschlüsselte WORM-Container auf TrueNAS
TrueNAS speichert nur die DMS-Pakete — der Aufbewahrungs-Lifecycle wird im DMS gepflegt

Backup: Proxmox Backup Server + Tape oder Object-Lock-Cloud

Tägliche Image-Backups der DATEV-VM
Wöchentlicher Backup-Verify
Monatlicher Tape-Auswurf zur Aufbewahrung im Bankschließfach (für klassische “Air-Gap”-Variante) oder Replikation in einen Cloud-Tier mit Object-Lock

Diese Architektur trennt drei Lebensphasen der Daten:

Aktive Bearbeitung — Live-Pool auf TrueNAS, hohe IO-Performance
Inaktive Aufbewahrung — Snapshots mit Hold, langzeitliche Read-only-Bestände
Backup / Wiederherstellung — Image-Backups via PBS, zusätzlich extern

Verfahrensdokumentation: das vergessene Pflichtdokument

Die Verfahrensdokumentation ist seit GoBD 2014 explizit gefordert. Sie beschreibt, wie die Buchführung organisatorisch und technisch abläuft — und das mit dem Detailgrad, dass ein sachverständiger Dritter die Buchführung nachvollziehen kann. Inhaltlich gehören dort hinein:

Allgemeine Beschreibung der Buchführungs-Software und der eingesetzten Hardware
Anwender-Dokumentation mit Berechtigungen, Zugriffs-Konzept
Technische Doku der Server- und Storage-Architektur — hier kommt TrueNAS rein
Betriebsdokumentation — Datensicherung, Wiederherstellung, Notfallplan
Datensicherheitsdokumentation — Verschlüsselung, MFA, Snapshots, Archivierung

Bei Betriebsprüfungen wird die Verfahrensdokumentation regelmäßig zuerst geprüft, lange bevor in die eigentlichen Buchungsdaten geschaut wird. Eine ordentliche Verfahrensdoku ist also kein optionales Beiwerk — sie ist der Filter, durch den die Prüfung läuft.

DSGVO-Aspekte: Auftragsverarbeitung und Verschlüsselung

Mandantendaten sind in aller Regel personenbezogen im DSGVO-Sinn. Daraus folgen Anforderungen, die TrueNAS in Teilen direkt erfüllt:

Verschlüsselung at-rest — TrueNAS unterstützt Dataset-Encryption (AES-256-GCM), Schlüssel können HSM-gehalten werden
Verschlüsselung in-flight — SMB 3.1.1 verschlüsselt automatisch, iSCSI über IPsec oder dedizierte VLANs
Zugriffs-Logging — siehe oben
Löschkonzept nach Mandanten-Ende — über Dataset-Strukturen (“ein Dataset pro Mandant”) wird das organisatorisch sauber

Bei Auslagerung in eine Cloud (z.B. Backup zu AWS S3 oder Hetzner Object Storage) gilt: Es ist ein AV-Vertrag mit dem Cloud-Anbieter erforderlich. Wir empfehlen für Kanzleien deutsche oder EU-ansässige Provider — datenrechtlich klar (Schrems-II-konform) und mit Standardvertragsklauseln, die bereits anwendbar sind.

Was Steuerberater bei DATAZONE typischerweise einkaufen

Aus konkreten Kanzlei-Projekten der letzten zwei Jahre die häufigsten Setups:

Kanzlei-Größe	Primär-TrueNAS	Replikation	Backup
1–10 Mitarbeitende	Mini X+ (8–16 TB)	Mini X+ am zweiten Standort	PBS + Tape (LTO-8)
10–25 Mitarbeitende	R20 (24–48 TB)	R20 am zweiten Standort	PBS + Tape + Object-Lock-Cloud
25–50 Mitarbeitende	H10 oder R40	R40 im Backup-RZ	PBS-Cluster + Tape + Cloud
>50 Mitarbeitende	Individuelle Beratung	Individuelle Beratung	Individuelle Beratung

Die Modellauswahl machen wir live im TrueNAS-Konfigurator durch — pro Kanzlei mit Bay-Bestückung, RAID-Topologie und Kapazitätsberechnung.

Fazit

TrueNAS allein macht eine Kanzlei nicht GoBD-konform — das ist genauso unsinnig, wie wenn man sagen würde, ein DATEV-Server allein mache GoBD-konform. Aber TrueNAS liefert die Storage-Schicht, die GoBD-Anforderungen technisch realistisch unterfüttert: Unveränderbarkeit über read-only Snapshots, Integrität über ZFS-Checksums, Wiederherstellbarkeit über Replikation, Aufbewahrungssicherheit über Snapshot-Holds.

Was zusätzlich da sein muss — Buchhaltung mit Festschreibung, DMS mit WORM-Eigenschaft, Verfahrensdokumentation, DSGVO-AV-Verträge — gehört zu jedem ordentlichen Kanzlei-IT-Projekt. Wenn diese vier Bausteine zusammenkommen, ist eine Kanzlei für eine Betriebsprüfung gut aufgestellt — und für eine Versicherungsanfrage nach einem Sicherheits-Vorfall ebenfalls.

TrueNAS für Steuerberater: GoBD-konforme Datenhaltung