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 fuer Datenbank-I/O ausgelegt wurde: eine allgemeine VMware- oder Proxmox-Datastore-Freigabe, eine SMB-Freigabe fuer 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 fuer Transaktionsdatenbanken — und die Restore-Praxis, die im Ernstfall dahintersteht.

Warum TrueNAS als Datenbank-Storage sinnvoll ist

TrueNAS bringt drei Eigenschaften mit, die fuer Datenbank-Workloads besonders relevant sind:

ZFS als Dateisystem: Ende-zu-Ende-Pruefsummen, Copy-on-Write und atomare Transaktionen passen konzeptionell gut zu ACID-Datenbanken. Silent Data Corruption — ein realer Killer fuer Datenbanken — wird auf Blockebene erkannt.
Getrennte Zvols pro Datenbank-Volume: Daten, Transaktions-Log und tempdb koennen 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 heisst nicht, dass TrueNAS jedes Enterprise-SAN ersetzt. Wer eine hochskalierte OLTP-Datenbank mit Millionen Transaktionen pro Sekunde betreibt, ist bei anderen Loesungen richtig. Fuer die typischen KMU-Datenbanken — ERP, DMS, Ticketsystem, Warenwirtschaft — ist TrueNAS aber eine ehrliche und wartbare Option.

iSCSI-Anbindung fuer MSSQL, PostgreSQL und MySQL

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

Zvol- und Recordsize-Wahl fuer 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-Groesse und Zvol-Volblocksize. Eine 8K-Page auf einem 64K-Zvol erzeugt Read-Modify-Write-Zyklen und macht Ihnen die Latenz kaputt. Fuer sequenzielle Log-Zvols hingegen ist eine groessere Blockgroesse besser, weil dort ohnehin in grossen zusammenhaengenden Bloecken geschrieben wird.

MSSQL: eigene Volumes fuer Daten, Log und tempdb

Bei Microsoft SQL Server hat sich die Trennung in drei getrennte Volumes bewaehrt:

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 durchschlaegt. 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 laesst, findet in unserem Artikel Proxmox 3-Node-Cluster mit TrueNAS H20 ein passendes Referenz-Setup, das sich auch fuer Datenbank-Workloads eignet.

MySQL / InnoDB: Redo-Log und Datenverzeichnis

Fuer MySQL und MariaDB mit InnoDB gilt eine aehnliche Logik. InnoDB nutzt eine feste 16K-Page-Size — das ist die natuerliche Volblocksize fuer 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 zuverlaessig betreiben will. Der Grund ist einfach: Wenn eine Datenbank ein COMMIT bestaetigt, muss die dazugehoerige Log-Sequenz garantiert persistent auf Disk sein — egal, ob eine Sekunde spaeter der Strom ausfaellt. Ohne sync=always puffert ZFS die Schreiblast im ARC/Write-Cache und meldet den Commit zurueck, bevor die Daten wirklich stabil sind. Genau dafuer wurde sync=always erfunden.

Der Preis: jede synchrone Schreiblast durchlaeuft 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 Ueberblicksseite zu ZFS-Kompression und Speichereffizienz.

Slog Sizing: klein, schnell, geschuetzt

Ein weit verbreitetes Missverstaendnis: das Slog muesse gross sein, damit “viele Daten reinpassen”. Das Gegenteil ist der Fall.

Das Slog nimmt nur die synchronen Writes zwischen zwei Transaction Group Commits auf — typischerweise fuenf Sekunden. Alles, was in diesen fuenf 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 fuer nahezu jede KMU-Datenbank aus.

Wichtiger als die Groesse 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 aeltere ZFS-Versionen unter Umstaenden Datenverlust auf der letzten Transaktion bedeuten.

Fuer die passende Hardware sprechen wir Sie gerne individuell an — die genauen Modelle und Preisrahmen haengen stark vom aktuellen Markt ab. Ein guter Startpunkt fuer die Konfiguration ist unser TrueNAS Konfigurator, fuer Enterprise-Setups die R-Serie mit passenden NVMe-Slots.

Snapshots und Replikation fuer Transaktionsdatenbanken

ZFS-Snapshots sind atomar auf Zvol-Ebene — das ist die halbe Miete. Die andere Haelfte 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 ueber 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 aequivalente pg_backup_start/pg_backup_stop ab Version 15 — danach ist der Snapshot als Basis fuer PITR-Recovery brauchbar.
MySQL/InnoDB: FLUSH TABLES WITH READ LOCK oder besser mysqldump --single-transaction fuer ein logisches Backup zusaetzlich zum Snapshot. XtraBackup bleibt die Alternative fuer heisse Backups.

Die eigentliche Snapshot-Retention-Strategie folgt der klassischen Pyramide: viele kurzfristige Snapshots (z. B. alle 15 Minuten fuer 24 Stunden), taegliche Snapshots ueber vier Wochen, monatliche Snapshots ueber ein Jahr. Details dazu finden Sie in unserem Artikel TrueNAS Snapshots und Replikation erklaert und in ZFS-Backup-Strategien.

Zusaetzlich empfiehlt sich eine ZFS-Replikation auf ein zweites TrueNAS-System — idealerweise offsite oder zumindest in einem anderen Brandabschnitt. Damit ueberleben Sie einen kompletten Verlust des Primaersystems.

Restore-Praxis: Vom Snapshot zurueck ins RDBMS

Ein Backup, das nie zurueckgespielt 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 zurueckzurollen — damit bleibt der Original-Datenstand erhalten, falls der Klon-Restore fehlschlaegt.
Klon als iSCSI-Extent bereitstellen und auf einem separaten Test-Server einbinden.
Datenbank starten, Konsistenz pruefen (DBCC CHECKDB bei MSSQL, pg_amcheck oder Basis-Queries bei PostgreSQL, CHECK TABLE bei MySQL).
Anwendungs-Test mit realistischen Read-Queries.
Erst wenn das durchlaeuft, wird der Klon zum Produktiv-Restore-Ziel oder die Daten werden per pg_dump/mysqldump/T-SQL zurueckgespielt.

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

Haeufige Fehler bei TrueNAS als Datenbank-Storage

sync=standard statt sync=always: Spart Latenz, aber gefaehrdet die letzte Transaktion bei Stromausfall. Bei Datenbanken keine Option.
Ein einziges Zvol fuer alle DB-Files: Daten und Log auf demselben Zvol machen jede Optimierung zunichte — die Zvols muessen getrennt sein.
Consumer-SSDs als Slog: Ohne PLP verlieren Sie im schlimmsten Fall genau die synchronen Writes, die Sie eigentlich schuetzen wollten.
Snapshots ohne DB-Konsistenz: Crash-Consistent ist okay, Application-Consistent ist besser — der Aufwand fuer die richtigen Hooks ist ueberschaubar.
Kein Restore-Test: Die haerteste Wahrheit. Wer den Restore nicht regelmaessig uebt, hat kein Backup, sondern ein Gluecksspiel.

Fazit

TrueNAS ist als Datenbank-Storage fuer MSSQL, PostgreSQL und MySQL eine solide, ehrliche Wahl fuer den KMU-Alltag. Die wesentlichen Bausteine sind: iSCSI mit korrekt gewaehlten Zvols und Recordsizes, sync=always fuer 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 verlaesslich traegt — ohne die Kosten einer proprietaeren Enterprise-SAN-Loesung. Fuer eine passgenaue Auslegung sprechen Sie uns direkt an oder starten Sie mit dem TrueNAS Konfigurator; Preise nennen wir individuell, weil sich die Hardwarelage staendig aendert.

FAQ

Reicht ein einzelnes Slog-Device fuer Datenbanken aus?

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

Wie gross muss ein Slog fuer eine 500-GB-Datenbank sein?

Die Datenbankgroesse spielt keine Rolle, entscheidend ist der synchronale Schreib-Durchsatz pro fuenf Sekunden. Ein 16-GB-Slog deckt bei typischen KMU-Datenbanken auch Spitzen mit dreistelligen MB/s im Log-Bereich ab.

Kann ich MSSQL-Datenbanken ueber SMB laufen lassen?

MSSQL unterstuetzt SMB 3.0 fuer Datenbank-Files, aber wir empfehlen es fuer produktive Umgebungen nicht. iSCSI ist berechenbarer, hat weniger Overhead und laesst sich sauberer mit ZFS Zvols kombinieren.

Wie oft sollten Snapshots von einer Datenbank gemacht werden?

Ein bewaehrter Rhythmus: alle 15 Minuten fuer 24 Stunden, taeglich fuer 30 Tage, monatlich fuer 12 Monate. Wichtig ist, dass mindestens die taeglichen Snapshots DB-konsistent (VSS, pg_backup_start, Xtra-Backup o. Ae.) sind.

Ist TrueNAS SCALE oder TrueNAS CORE besser fuer Datenbank-Storage?

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

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

Ja, ueber ZFS-Replikation. Das ist ausdruecklich empfohlen — damit haben Sie eine zweite Kopie in einem anderen Brandabschnitt oder Standort. Fuer die Absicherung gegen Ransomware koennen die Replika-Snapshots zusaetzlich mit readonly=on geschuetzt werden.

Sie planen einen TrueNAS-Storage als Backend fuer 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