Datenbanken sind der Teil der IT, bei dem Storage-Fehler am schnellsten weh tun. Ein verlorener Redo-Log, eine korrupte Page in der System-Datenbank oder ein Snapshot ohne konsistenten Restore-Pfad — und der Betrieb steht. Trotzdem laufen erstaunlich viele MSSQL-, PostgreSQL- und MySQL-Instanzen in KMU-Umgebungen auf Storage, das nie für Datenbank-I/O ausgelegt wurde: eine allgemeine VMware- oder Proxmox-Datastore-Freigabe, eine SMB-Freigabe für Backups, ein NAS aus dem Consumer-Regal.

Dieser Artikel zeigt, wie TrueNAS als Datenbank-Storage sauber konfiguriert wird. Es geht nicht um einen Hardware-Benchmark, sondern um die architektonischen Entscheidungen, die im Alltag den Unterschied machen: iSCSI-Anbindung, sync=always, das richtige Slog-Sizing, Snapshots für Transaktionsdatenbanken — und die Restore-Praxis, die im Ernstfall dahintersteht.

Warum TrueNAS als Datenbank-Storage sinnvoll ist

TrueNAS bringt drei Eigenschaften mit, die für Datenbank-Workloads besonders relevant sind:

ZFS als Dateisystem: Ende-zu-Ende-Prüfsummen, Copy-on-Write und atomare Transaktionen passen konzeptionell gut zu ACID-Datenbanken. Silent Data Corruption — ein realer Killer für Datenbanken — wird auf Blockebene erkannt.
Getrennte Zvols pro Datenbank-Volume: Daten, Transaktions-Log und tempdb können jeweils auf einem eigenen Zvol mit passender Recordsize liegen. Das ist mit klassischen RAID-Arrays deutlich aufwendiger.
Snapshots und Replikation als Bordmittel: ZFS-Snapshots sind atomar auf Blockebene. Zusammen mit Datenbank-eigenen Konsistenzmechanismen — VSS bei MSSQL, pg_start_backup/Backup-Label bei PostgreSQL, FLUSH TABLES WITH READ LOCK oder InnoDB-freundliche Alternativen bei MySQL — lassen sich damit brauchbare Point-in-Time-Wiederherstellungen bauen.

Das heißt nicht, dass TrueNAS jedes Enterprise-SAN ersetzt. Wer eine hochskalierte OLTP-Datenbank mit Millionen Transaktionen pro Sekunde betreibt, ist bei anderen Lösungen richtig. Für die typischen KMU-Datenbanken — ERP, DMS, Ticketsystem, Warenwirtschaft — ist TrueNAS aber eine ehrliche und wartbare Option.

iSCSI-Anbindung für MSSQL, PostgreSQL und MySQL

Für Datenbank-Workloads ist iSCSI das Protokoll der Wahl. Block-Level-Zugriff, klare Semantik bei Sync-Writes, gutes Zusammenspiel mit ZFS Zvols. Die grundsätzliche iSCSI-Einrichtung ist in unserem Artikel zu TrueNAS iSCSI-Storage für Proxmox beschrieben — die Datenbank-spezifischen Details folgen hier.

Zvol- und Recordsize-Wahl für Datenbanken

Die Recordsize entscheidet, wie viel Overhead ZFS pro Datenbank-Page erzeugt. Die Empfehlung sieht in der Praxis so aus:

Engine	Datenbereich (Volblocksize)	Log-Bereich	tempdb / Sortierung
MSSQL	8K oder 16K	64K sequenziell	16K
PostgreSQL	8K (entspricht Default-Page)	16K oder 32K	16K
MySQL / InnoDB	16K (Default-Page)	32K	16K

Wichtig ist die Konsistenz zwischen Datenbank-Page-Größe und Zvol-Volblocksize. Eine 8K-Page auf einem 64K-Zvol erzeugt Read-Modify-Write-Zyklen und macht Ihnen die Latenz kaputt. Für sequenzielle Log-Zvols hingegen ist eine größere Blockgröße besser, weil dort ohnehin in großen zusammenhängenden Blöcken geschrieben wird.

MSSQL: eigene Volumes für Daten, Log und tempdb

Bei Microsoft SQL Server hat sich die Trennung in drei getrennte Volumes bewährt:

Datenvolume: mdf/ndf, Volblocksize 8K oder 16K, Compression lz4, sync=always
Logvolume: ldf, Volblocksize 64K, sequenzielle Schreiblast, sync=always
tempdb: eigenes Zvol, Volblocksize 16K, oft mit sync=disabled — weil tempdb bei Neustart ohnehin verworfen wird

Diese Trennung erlaubt es, das Log-Volume mit einem Slog-Device zu beschleunigen, ohne dass tempdb-Traffic durchschlägt. Bei MSSQL sind auch die Instant File Initialization und die passende MAXDOP-Einstellung Themen, die sich stark auf die Storage-Last auswirken.

PostgreSQL: WAL, pg_data und Basetables trennen

PostgreSQL profitiert stark davon, wenn das Write-Ahead-Log (WAL) auf einem eigenen Zvol liegt. Der WAL-Traffic ist rein sequenziell und synchron — das ist genau der Punkt, an dem sync=always und ein gutes Slog-Device den Ausschlag geben.

Empfohlene Aufteilung:

pg_data (Basetables): Zvol mit Volblocksize 8K, lz4, atime=off
pg_wal (WAL): eigenes Zvol, Volblocksize 16K bis 32K, sync=always
pg_stat_tmp / temp_tablespaces: eigenes Zvol, ggf. sync=disabled

Wer PostgreSQL virtualisiert unter Proxmox laufen lässt, findet in unserem Artikel Proxmox 3-Node-Cluster mit TrueNAS H20 ein passendes Referenz-Setup, das sich auch für Datenbank-Workloads eignet.

MySQL / InnoDB: Redo-Log und Datenverzeichnis

Für MySQL und MariaDB mit InnoDB gilt eine ähnliche Logik. InnoDB nutzt eine feste 16K-Page-Size — das ist die natürliche Volblocksize für das Datenverzeichnis. Das InnoDB Redo Log (ib_logfile*) sollte auf einem eigenen Zvol mit sync=always liegen, damit innodb_flush_log_at_trx_commit=1 seine ACID-Garantien halten kann.

Kurz gefasst:

Datenverzeichnis: Volblocksize 16K, lz4, sync=always
Redo Log: eigenes Zvol, Volblocksize 32K, sync=always
Undo/Temp: ggf. eigenes Zvol, sync-Einstellung je nach Recovery-Anforderung

sync=always: Warum Datenbanken es brauchen

sync=always ist die wichtigste ZFS-Einstellung, wenn man Datenbanken zuverlässig betreiben will. Der Grund ist einfach: Wenn eine Datenbank ein COMMIT bestätigt, muss die dazugehörige Log-Sequenz garantiert persistent auf Disk sein — egal, ob eine Sekunde später der Strom ausfällt. Ohne sync=always puffert ZFS die Schreiblast im ARC/Write-Cache und meldet den Commit zurück, bevor die Daten wirklich stabil sind. Genau dafür wurde sync=always erfunden.

Der Preis: jede synchrone Schreiblast durchläuft den ZFS Intent Log (ZIL). Ohne dediziertes Slog-Device wird der ZIL auf denselben Pool geschrieben, auf dem auch die eigentlichen Daten liegen. Das kostet Performance — und genau hier kommt das Slog ins Spiel.

Mehr Hintergrund zu ZFS-Verhalten unter Last und zur Rolle der Cache-Schichten steht in unserem Artikel zur TrueNAS Performance-Optimierung und in unserer Überblicksseite zu ZFS-Kompression und Speichereffizienz.

Slog Sizing: klein, schnell, geschützt

Ein weit verbreitetes Missverständnis: das Slog müsse groß sein, damit “viele Daten reinpassen”. Das Gegenteil ist der Fall.

Das Slog nimmt nur die synchronen Writes zwischen zwei Transaction Group Commits auf — typischerweise fünf Sekunden. Alles, was in diesen fünf Sekunden an synchronen Writes eintrifft, muss im Slog landen. Bei einer Datenbank mit 500 MB/s synchronem Log-Traffic sind das rund 2,5 GB. Ein 16-GB-Slog reicht damit für nahezu jede KMU-Datenbank aus.

Wichtiger als die Größe sind drei andere Eigenschaften:

Latenz: Ein Slog muss deutlich schneller antworten als der Haupt-Pool. NVMe-SSDs mit Power Loss Protection (PLP) sind hier Pflicht.
Endurance: Ein Slog schreibt permanent. Consumer-SSDs sind schnell verschlissen. Datacenter-SSDs mit hohem DWPD-Wert sind Standard.
Redundanz: Ein Mirror aus zwei Slog-Devices ist bei Datenbanken sinnvoll — der Ausfall eines einzelnen Slog kann bei ältere ZFS-Versionen unter Umständen Datenverlust auf der letzten Transaktion bedeuten.

Für die passende Hardware sprechen wir Sie gerne individuell an — die genauen Modelle und Preisrahmen hängen stark vom aktuellen Markt ab. Ein guter Startpunkt für die Konfiguration ist unser TrueNAS Konfigurator, für Enterprise-Setups die R-Serie mit passenden NVMe-Slots.

Snapshots und Replikation für Transaktionsdatenbanken

ZFS-Snapshots sind atomar auf Zvol-Ebene — das ist die halbe Miete. Die andere Hälfte ist die Anwendungs-Konsistenz. Ein Zvol-Snapshot, der mitten in einer Datenbank-Transaktion angelegt wird, ist zwar “crash-consistent” (die Datenbank kann daraus recovern), aber nicht immer “application-consistent”.

Die Best-Practice-Muster:

MSSQL: VSS-basierte Snapshots über den Storage-Provider oder alternativ ein kurzes BACKUP DATABASE ... WITH COPY_ONLY unmittelbar vor dem Zvol-Snapshot.
PostgreSQL: pg_start_backup('label') / pg_stop_backup() bzw. das äquivalente pg_backup_start/pg_backup_stop ab Version 15 — danach ist der Snapshot als Basis für PITR-Recovery brauchbar.
MySQL/InnoDB: FLUSH TABLES WITH READ LOCK oder besser mysqldump --single-transaction für ein logisches Backup zusätzlich zum Snapshot. XtraBackup bleibt die Alternative für heiße Backups.

Die eigentliche Snapshot-Retention-Strategie folgt der klassischen Pyramide: viele kurzfristige Snapshots (z. B. alle 15 Minuten für 24 Stunden), tägliche Snapshots über vier Wochen, monatliche Snapshots über ein Jahr. Details dazu finden Sie in unserem Artikel TrueNAS Snapshots und Replikation erklärt und in ZFS-Backup-Strategien.

Zusätzlich empfiehlt sich eine ZFS-Replikation auf ein zweites TrueNAS-System — idealerweise offsite oder zumindest in einem anderen Brandabschnitt. Damit überleben Sie einen kompletten Verlust des Primärsystems.

Restore-Praxis: Vom Snapshot zurück ins RDBMS

Ein Backup, das nie zurückgespielt wurde, ist kein Backup. Bei Datenbanken ist dieser Grundsatz besonders wichtig, weil die Wiederherstellung mehr Schritte hat als bei einem Datei-Backup.

Ein realistischer Restore-Ablauf sieht so aus:

Snapshot klonen (zfs clone) statt direkt zurückzurollen — damit bleibt der Original-Datenstand erhalten, falls der Klon-Restore fehlschlägt.
Klon als iSCSI-Extent bereitstellen und auf einem separaten Test-Server einbinden.
Datenbank starten, Konsistenz prüfen (DBCC CHECKDB bei MSSQL, pg_amcheck oder Basis-Queries bei PostgreSQL, CHECK TABLE bei MySQL).
Anwendungs-Test mit realistischen Read-Queries.
Erst wenn das durchläuft, wird der Klon zum Produktiv-Restore-Ziel oder die Daten werden per pg_dump/mysqldump/T-SQL zurückgespielt.

Diese Übung sollte mindestens quartalsweise fest im Kalender stehen. Wenn wir bei Kunden Disaster-Recovery-Konzepte planen, ist der DB-Restore-Test ein fester Bestandteil.

Häufige Fehler bei TrueNAS als Datenbank-Storage

sync=standard statt sync=always: Spart Latenz, aber gefährdet die letzte Transaktion bei Stromausfall. Bei Datenbanken keine Option.
Ein einziges Zvol für alle DB-Files: Daten und Log auf demselben Zvol machen jede Optimierung zunichte — die Zvols müssen getrennt sein.
Consumer-SSDs als Slog: Ohne PLP verlieren Sie im schlimmsten Fall genau die synchronen Writes, die Sie eigentlich schützen wollten.
Snapshots ohne DB-Konsistenz: Crash-Consistent ist okay, Application-Consistent ist besser — der Aufwand für die richtigen Hooks ist überschaubar.
Kein Restore-Test: Die härteste Wahrheit. Wer den Restore nicht regelmäßig übt, hat kein Backup, sondern ein Glücksspiel.

Fazit

TrueNAS ist als Datenbank-Storage für MSSQL, PostgreSQL und MySQL eine solide, ehrliche Wahl für den KMU-Alltag. Die wesentlichen Bausteine sind: iSCSI mit korrekt gewählten Zvols und Recordsizes, sync=always für Daten- und Log-Volumes, ein passend dimensioniertes Slog mit PLP-SSDs, saubere Snapshot-Prozesse mit DB-Konsistenz und eine gelebte Restore-Praxis.

Wer diese Punkte adressiert, bekommt eine Storage-Plattform, die Datenbank-Workloads verlässlich trägt — ohne die Kosten einer proprietären Enterprise-SAN-Lösung. Für eine passgenaue Auslegung sprechen Sie uns direkt an oder starten Sie mit dem TrueNAS Konfigurator; Preise nennen wir individuell, weil sich die Hardwarelage ständig ändert.

FAQ

Reicht ein einzelnes Slog-Device für Datenbanken aus?

Technisch ja, in der Praxis nein. Für produktive Datenbanken empfiehlt sich ein Slog-Mirror aus zwei PLP-NVMe-SSDs. Der Kapazitätsbedarf ist gering — 16 bis 32 GB reichen fast immer aus.

Wie groß muss ein Slog für eine 500-GB-Datenbank sein?

Die Datenbankgröße spielt keine Rolle, entscheidend ist der synchronale Schreib-Durchsatz pro fünf Sekunden. Ein 16-GB-Slog deckt bei typischen KMU-Datenbanken auch Spitzen mit dreistelligen MB/s im Log-Bereich ab.

Kann ich MSSQL-Datenbanken über SMB laufen lassen?

MSSQL unterstützt SMB 3.0 für Datenbank-Files, aber wir empfehlen es für produktive Umgebungen nicht. iSCSI ist berechenbarer, hat weniger Overhead und lässt sich sauberer mit ZFS Zvols kombinieren.

Wie oft sollten Snapshots von einer Datenbank gemacht werden?

Ein bewährter Rhythmus: alle 15 Minuten für 24 Stunden, täglich für 30 Tage, monatlich für 12 Monate. Wichtig ist, dass mindestens die täglichen Snapshots DB-konsistent (VSS, pg_backup_start, Xtra-Backup o. Ä.) sind.

Ist TrueNAS SCALE oder TrueNAS CORE besser für Datenbank-Storage?

Beide Varianten nutzen dasselbe OpenZFS. Für neue Setups empfehlen wir TrueNAS SCALE (Linux-Basis, aktive Weiterentwicklung). Hintergründe dazu finden Sie in unserem Artikel TrueNAS SCALE vs CORE.

Kann ich Snapshots eines Datenbank-Zvols auf ein zweites TrueNAS replizieren?

Ja, über ZFS-Replikation. Das ist ausdrücklich empfohlen — damit haben Sie eine zweite Kopie in einem anderen Brandabschnitt oder Standort. Für die Absicherung gegen Ransomware können die Replika-Snapshots zusätzlich mit readonly=on geschützt werden.

Sie planen einen TrueNAS-Storage als Backend für MSSQL, PostgreSQL oder MySQL? Kontaktieren Sie uns — wir dimensionieren Zvols, Slog und Snapshot-Strategie passend zu Ihrer Datenbank und schulen Ihr Team in der Restore-Praxis.

TrueNAS als Datenbank-Storage: MSSQL, PostgreSQL und MySQL sauber anbinden