TrueNAS für E-Commerce: Shop-Storage mit Media-Content, Datenbank-Backup und schnellen Snapshots

E-Commerce ist für die meisten mittelständischen Shop-Betreiber kein Nebenschauplatz mehr. Ein Shop mit 15.000 Artikeln, täglicher Produktpflege und einer Handvoll Marketing-Deployments pro Monat ist IT-seitig ein kleines Rechenzentrum im Miniaturformat. Was dabei oft fehlt, ist eine saubere Storage-Strategie: Produktbilder landen im Shop-Hosting, Datenbank-Backups liegen im besten Fall auf einem zweiten Server, und wenn ein Deployment schiefgeht, wird aus einem geplanten Zehn-Minuten-Fenster schnell ein halber Nachmittag mit Hotline-Telefonaten.

Dieser Artikel beschreibt, wie wir bei DATAZONE TrueNAS als zentralen Shop-Storage in E-Commerce-Umgebungen einsetzen. Im Fokus stehen die drei typischen Baustellen: Media-Assets, Datenbank-Backup und Snapshots vor Deployments. Beispielhaft am Shopware-, Magento- und WooCommerce-Alltag, aber die Muster übertragen sich auch auf OXID, JTL-Shop oder Spryker.

Warum Shop-Storage im Mittelstand anders tickt als klassische File-Shares

Ein Shop-System produziert eine Mischung aus zwei sehr unterschiedlichen Datentypen: viele kleine Dateien, die oft gelesen werden (Produktbilder, Thumbnails, Varianten), und wenige große, strukturierte Datenbestände, die regelmäßig geschrieben und gesichert werden müssen (die Shop-Datenbank, Konfiguration, Plugins, Theme-Daten). Dazu kommen Session-Daten, Caches, Logs und Export-Dateien aus Marketplace-Anbindungen.

In vielen KMU-Setups liegt das alles zusammen auf dem Hoster-Server, der eigentlich für die Shop-Auslieferung gedacht ist. Das funktioniert, bis einer dieser drei Punkte eintritt: die Bildermenge wächst über das normale Backup-Fenster hinaus, ein Datenbank-Backup wird nicht sauber nachts eingespielt oder ein Deployment legt den Shop in die Timeout-Zone. In allen drei Fällen hilft es, den Storage sauber vom Shop-Hosting zu entkoppeln und ihm die Rolle zuzuteilen, die ein TrueNAS-System seit Jahren gut kann: zuverlässig vorhalten, konsistent sichern, schnell zurückrollen.

Die typische Ausgangslage bei einem mittelständischen Shopware-Setup

Ein konkretes Beispiel aus unserer Praxis: ein Hersteller aus Oberbayern mit knapp 12.000 Produkten, Shopware 6 bei einem deutschen Hoster, Marketing-Fotos aus dem eigenen Studio in hoher Auflösung. Media-Verzeichnis rund 480 Gigabyte, Datenbank etwa 18 Gigabyte, zusätzlich ein paar hundert Megabyte für ERP-Export-Dateien, die der Mandant selbst nachts generiert. Das Hoster-Backup lief einmal nachts, dauerte zuletzt über fünf Stunden und hatte in den letzten sechs Monaten zweimal nicht sauber durchgelaufen. Mit einem TrueNAS vor Ort und einer sauberen Trennung der Backup-Pfade war das Thema in einem Nachmittag abgeräumt.

Media-Assets: viele kleine Dateien gehören auf ZFS

Shop-Media-Verzeichnisse sind der Albtraum jedes File-Systems, das für große Dateien ausgelegt ist. 12.000 Produkte mit jeweils fünf bis zwölf Varianten in unterschiedlichen Auflösungen ergeben schnell einige hunderttausend Dateien, viele davon zwischen 50 Kilobyte und 2 Megabyte. ZFS auf einer vernünftig dimensionierten TrueNAS-Hardware ist für genau dieses Muster gut.

Wir legen Media-Verzeichnisse grundsätzlich auf einem eigenen Dataset ab. Das hat drei konkrete Vorteile: erstens lassen sich Snapshot-Policies gezielt auf das Dataset ziehen, zweitens kann die Replikation ins Backup-Ziel pro Dataset gesteuert werden, drittens trennt die ACL-Vererbung Media-Pfade sauber von anderen Shop-Daten. Für Shopware heißt das in der Praxis: /public/media wandert auf ein Dataset shop/media, gemountet per SMB oder NFS je nach Hoster-Setup und Betriebssystem der Shop-Instanz. Für Magento ist es das pub/media-Verzeichnis, für WooCommerce der wp-content/uploads-Pfad.

Snapshot-Policy für Media: hohe Frequenz, abgestufte Retention

Für Media-Datasets fahren wir meist eine mehrstufige Snapshot-Policy: alle sechs Stunden einen Snapshot für drei Tage, täglich einen für zwei Wochen, wöchentlich einen für drei Monate. Das klingt viel, kostet aber dank ZFS-Deduplikation auf Blockebene und der inkrementellen Natur von ZFS-Snapshots nur wenige Prozent des Nutzbaren. Der Mehrwert: wenn jemand im Shop-Backend versehentlich ein Produkt mit allen Bildern löscht, ist der Zustand von vor sechs Stunden in Minuten wieder da — ohne dass der Hoster überhaupt kontaktiert werden muss.

Wichtig ist dabei die Trennung von Produktion und Thumbnails. Thumbnails lassen sich bei Shopware und Magento jederzeit neu generieren und müssen nicht Teil des Media-Snapshots sein. Wer sie trotzdem mitnimmt, verschenkt Plattenplatz. Wir legen für Thumbnails ein separates Dataset ohne Snapshot-Policy an, das sich bei Bedarf aus der Produktion neu aufbauen lässt.

Datenbank-Backup: konsistent, versioniert und getrennt vom Shop-Server

Die Shop-Datenbank ist das Herzstück und zugleich der größte Hebel für Risiko. Ein inkonsistentes Backup, das beim Restore nicht sauber importiert werden kann, ist schlimmer als gar kein Backup, weil es das falsche Sicherheitsgefühl erzeugt. Für MySQL/MariaDB bei Shopware, Magento und WooCommerce verwenden wir fast immer Percona XtraBackup oder mariabackup für konsistente Online-Dumps, die auf das TrueNAS geschrieben werden.

Technisch läuft das meist so: ein Cronjob auf dem Shop-Server oder einer dedizierten Backup-VM erzeugt den konsistenten Dump, komprimiert ihn und schreibt ihn in ein TrueNAS-Dataset shop/db-dumps. Das Dataset hat eine Snapshot-Policy, die drei Monate rückwärts erreicht — in dreimonatiger Rückwärts-Sicht gab es noch jedes Datenproblem, das wir aufgearbeitet haben, von der versehentlich geleerten Kategorie bis zum fehlgeschlagenen Plugin-Update, das 400 Kundendatensätze beschädigt hat.

Replikation auf einen zweiten Standort

Für den Fall, dass das primäre TrueNAS selbst ausfällt oder gezielt kompromittiert wird, replizieren wir das Datenbank-Backup-Dataset verschlüsselt auf einen zweiten Standort. Das kann ein Zweit-TrueNAS beim Kunden sein oder bei kleineren Setups ein TrueNAS Mini R in unserem Rechenzentrum. Mehr zur Logik dahinter steht in unserem Artikel zu Backup-Strategie für KMU mit Proxmox und TrueNAS. Die Grundregel bleibt: ein Backup, das nur neben dem Original steht, ist kein Backup.

Restore-Tests gehören zum Betrieb

Ein unterschätzter Punkt in Shop-Umgebungen: der Restore-Test. Wir empfehlen bei E-Commerce-Kunden mindestens einen quartalsweisen Testrestore in eine Staging-Umgebung. Das deckt Dinge auf, die niemand sehen will — etwa dass die Shopware-Konfiguration auf absolute Pfade zeigt, die beim Restore nicht mitwandern, oder dass ein Plugin eine zusätzliche Datenbank-Tabelle angelegt hat, die im Dump-Skript nicht berücksichtigt war. Wie wir Restore-Drills strukturieren, haben wir in einem eigenen Beitrag zum 30-Tage-Restore-Drill beschrieben.

Snapshots vor Deployments: der stille Lebensretter

Jedes Shop-Deployment ist ein Eingriff ins laufende System. Theme-Update, Plugin-Installation, Shopware-Minor-Release, PHP-Version-Wechsel: alle diese Vorgänge sind getestet, aber keiner ist risikofrei. Ein TrueNAS-Snapshot auf dem Media-Dataset und ein frischer Datenbank-Dump unmittelbar vor dem Deployment reduzieren das Rollback-Risiko dramatisch.

Der praktische Ablauf, den wir mit Kunden eingespielt haben, sieht so aus: ein Deployment-Skript — egal ob Deployer, Capistrano, GitLab-CI oder ein hausgemachtes Bash-Skript — löst vor dem eigentlichen Deployment zwei Aktionen aus. Erstens einen manuellen Snapshot auf dem relevanten Media- und Config-Dataset mit einem sprechenden Namen, etwa pre-deploy-plugin-xyz-20261107-1430. Zweitens einen expliziten Datenbank-Dump, der getrennt von den regulären Backups abgelegt wird.

Warum ZFS-Snapshots in diesem Szenario schlagen

Ein TrueNAS-Snapshot ist atomar, dauert wenige Sekunden und bindet so lange keinen zusätzlichen Plattenplatz, bis das Original sich ändert. Das heißt: ein Deployment-Snapshot vor einem Shopware-Plugin-Update ist in dem Moment, in dem er erzeugt wird, nahezu kostenlos. Wenn das Deployment sauber durchläuft, kann der Snapshot nach ein paar Tagen gelöscht werden. Wenn es schiefgeht, ist der Rollback-Weg eine ZFS-Operation von wenigen Sekunden — plus Datenbank-Restore aus dem frisch gezogenen Dump.

Für die Datenbank-Seite nutzen wir je nach Kundenumgebung entweder einen klassischen SQL-Dump oder ein XtraBackup-Snapshot. Die Entscheidung hängt an Datenbankgröße und akzeptabler Downtime: unter 5 Gigabyte reicht ein SQL-Dump, darüber empfehlen wir XtraBackup, weil der Restore deutlich schneller ist.

Staging-Umgebungen aus Snapshots: ein unterschätzter Vorteil

Ein Nebeneffekt der Snapshot-Strategie ist, dass sich daraus mit wenig Aufwand eine Staging-Umgebung bauen lässt. Ein ZFS-Snapshot kann als Clone genutzt werden — das heißt, man bekommt eine beschreibbare Kopie des Produktionsstands, ohne dass der Snapshot selbst verändert wird. Für Shopware oder Magento heißt das: ein Entwickler bekommt in Minuten eine Staging-Umgebung mit dem aktuellen Produktionsdatenstand, kann dort Plugin-Updates oder Theme-Änderungen durchtesten und wirft die Umgebung danach einfach weg.

Das reduziert die Zahl der Fehler, die erst in Produktion auffliegen, deutlich. Wer regelmäßig mit Deployments arbeitet und keinen produktionsnahen Staging-Zustand hat, deployed effektiv blind. Mehr Hintergrund zu Snapshot-basiertem Arbeiten findet sich auch in unserem Artikel zu ZFS-Dataset-Quotas und Reservations.

Hardware-Rahmen: was passt zu welcher Shop-Größe

Für mittelständische Shop-Umgebungen reicht in den meisten Fällen eine R-Serie oder bei flash-lastigen Setups eine F-Serie von TrueNAS. Ein Shopware-Setup mit 500 Gigabyte Media-Daten, 20 Gigabyte Datenbank und einer dreimonatigen Backup-Retention passt gut auf eine R20 mit ausreichend NVMe-Cache. Wer zusätzlich Virtualisierungs-Workloads oder einen zweiten Standort bedient, sollte eine R30 oder höher einplanen. Die M-Serie mit M30 und M40 kommt bei größeren Shops oder Konzernstrukturen zum Einsatz — die früheren M50 und M60 sind EOL und für Neuprojekte nicht mehr vorgesehen.

Für die konkrete Konfiguration — Pool-Größe, Netzwerk-Interfaces, Replikationstopologie — ist unser TrueNAS-Konfigurator der schnellste Weg zur Vorab-Einschätzung. Festpreise nennen wir dort bewusst nicht, weil Komponentenpreise sich im Quartalstakt bewegen; stattdessen bekommen Interessenten einen aktuellen Preisrahmen oder ein individuelles Angebot. Die Bestellstrecke läuft über unseren TrueNAS-Kaufbereich.

Ein Wort zum Thema Hoster versus On-Premise

Nicht jeder mittelständische Shop muss sein TrueNAS vor Ort stehen haben. In vielen unserer Projekte steht das primäre System beim Kunden im Serverraum oder Netzwerkschrank, und das Replikationsziel läuft in unserem Rechenzentrum. In anderen Fällen — insbesondere wenn kein eigener Serverraum vorhanden ist — übernehmen wir beide Standorte und binden das TrueNAS per VPN direkt an die Shop-Hosting-Umgebung an. Der Weg ist weniger wichtig als das Ziel: Media-Assets und Datenbank-Backups müssen physisch und logisch getrennt vom laufenden Shop-System liegen, sonst taugt die ganze Konstruktion im Ernstfall nichts.

Fazit: TrueNAS macht den Shop nicht schneller, aber deutlich belastbarer

TrueNAS ist kein Performance-Booster für Shopware oder Magento. Es ist der ruhige Partner im Hintergrund, der dafür sorgt, dass Media-Assets konsistent gesichert, Datenbank-Backups überprüft und Deployments rückrollbar sind. In unserer Praxis macht das den Unterschied zwischen einem Shop, der im Alltag funktioniert, und einem, der im Störfall auch noch funktioniert.

Wenn du für dein Shop-System überlegst, wie du den Storage-Teil der Infrastruktur strukturieren willst — ob für Shopware, Magento, WooCommerce oder eine andere Plattform — melde dich bei uns. Wir sehen in unseren Projekten regelmäßig, wo die typischen Fallstricke liegen, und können einen Rahmen vorschlagen, der zur Größe deines Shops und deinem Betriebsmodell passt.

FAQ

Lohnt sich ein eigenes TrueNAS, wenn der Shop beim Hoster läuft?

In vielen Fällen ja. Der Hoster liefert typischerweise ein Standard-Backup, das für die eigene Hochverfügbarkeit reicht, aber selten für einen echten Restore-Fall taugt. Ein eigenes TrueNAS mit replizierten Datenbank-Dumps und Media-Snapshots schließt genau diese Lücke, ohne den Hoster-Vertrag zu verändern. Für mittelständische Shops ab einem gewissen Umsatzrisiko ist der Aufwand überschaubar und der Mehrwert messbar.

Welche TrueNAS-Hardware passt zu einem Shopware-Shop mit rund 500 Gigabyte Media-Daten?

Für diese Größenordnung ist eine R-Serie, konkret eine R20 oder R30, der typische Einstieg. Entscheidend sind weniger die Rohdaten als die Backup-Retention und die Frage, ob zusätzlich ein zweiter Standort bedient werden soll. Konkrete Konfigurationen lassen sich im TrueNAS-Konfigurator durchrechnen oder in einem kurzen Gespräch mit uns abstimmen.

Wie oft sollten Snapshots auf dem Media-Dataset laufen?

Für aktive Shops empfehlen wir einen Snapshot alle sechs Stunden mit drei Tagen Retention, dazu tägliche Snapshots für zwei Wochen und wöchentliche für drei Monate. Dank ZFS-Inkremental-Verhalten ist der Platzverbrauch gering, der Mehrwert bei versehentlichen Löschungen aber hoch. Wichtig ist zusätzlich ein expliziter Snapshot direkt vor jedem Deployment.

Wie wird die Shop-Datenbank konsistent auf TrueNAS gesichert?

Für MySQL und MariaDB — also die Datenbanken hinter Shopware, Magento und WooCommerce — nutzen wir meist Percona XtraBackup oder mariabackup für konsistente Online-Backups. Der Dump wird komprimiert auf ein eigenes TrueNAS-Dataset geschrieben, dort versioniert per Snapshot vorgehalten und auf einen zweiten Standort repliziert. SQL-Dumps per mysqldump sind für kleine Datenbanken bis fünf Gigabyte eine valide Alternative, darüber wird der Restore zu langsam.

Kann TrueNAS als Live-Storage für den Shop selbst dienen?

In den meisten mittelständischen Setups ist das nicht sinnvoll. Der produktive Shop läuft weiter beim Hoster oder auf einer eigenen VM-Plattform, TrueNAS übernimmt Backup, Media-Archiv und Snapshot-Rolle. In speziellen Konstellationen — etwa bei On-Premise-Shops mit eigenem Rechenzentrum — kann ein TrueNAS auch als NFS- oder iSCSI-Backend für die Shop-VMs dienen. Das ist aber ein Projekt, das individuell geplant werden sollte, nicht ein Standardweg.

Wie viel Zeit kostet die Einrichtung eines solchen Shop-Storage-Setups?

Für ein typisches mittelständisches Shopware- oder Magento-Setup planen wir ein bis zwei Tage für Installation, Dataset-Struktur, Snapshot-Policies, Replikation und Erst-Backup. Dazu kommt ein strukturierter Restore-Test, den wir im Rahmen des Projekts einmal gemeinsam durchlaufen. Danach läuft der Betrieb weitgehend automatisch, mit vierteljährlichen Restore-Drills als empfohlenem Pflegerhythmus.