TrueNAS for E-Commerce: Shop Storage for Media Content, Database Backup and Fast Snapshots

For most mid-sized shop operators, e-commerce is no longer a side show. A shop with 15,000 products, daily product maintenance and a handful of marketing deployments per month is, from an IT point of view, a small data centre in miniature. What is often missing is a clean storage strategy: product images live on the shop hosting, database backups sit at best on a second server, and when a deployment goes sideways, a planned ten-minute window turns into half an afternoon on the hotline.

This article describes how we at DATAZONE use TrueNAS as central shop storage in e-commerce environments. The focus is on the three typical pain points: media assets, database backup, and snapshots before deployments. The examples come from the day-to-day with Shopware, Magento and WooCommerce, but the patterns transfer to OXID, JTL-Shop or Spryker.

Why shop storage in SMBs behaves differently from classic file shares

A shop system produces a mix of two very different data types: many small files that are read often (product images, thumbnails, variants) and few large structured datasets that are written and backed up on a regular schedule (the shop database, configuration, plugins, theme data). Add session data, caches, logs and export files from marketplace integrations.

In many SMB setups, all of this lives together on the hoster’s server, which is really intended for shop delivery. That works until one of three things happens: the image volume grows beyond the normal backup window, a database backup fails to import cleanly overnight, or a deployment pushes the shop into timeout territory. In all three cases it helps to decouple storage cleanly from shop hosting and give it the role a TrueNAS system has handled well for years: hold data reliably, back it up consistently, roll back fast.

A typical starting point at a mid-market Shopware setup

A concrete example from our own practice: a manufacturer from Upper Bavaria with roughly 12,000 products, Shopware 6 at a German hoster, marketing photos from the in-house studio in high resolution. Media directory around 480 gigabytes, database around 18 gigabytes, plus a few hundred megabytes for ERP export files that the customer generates themselves at night. The hoster backup ran once a night, had grown to over five hours and had failed to complete cleanly twice in the past six months. With an on-site TrueNAS and a clean split of the backup paths, the whole topic was cleared up in a single afternoon.

Media assets: lots of small files belong on ZFS

Shop media directories are the nightmare of any file system that is tuned for large files. 12,000 products with five to twelve variants each at different resolutions quickly yield several hundred thousand files, many of them between 50 kilobytes and 2 megabytes. ZFS on sensibly sized TrueNAS hardware is a good match for exactly that pattern.

We always put media directories on a dedicated dataset. That has three concrete advantages: first, snapshot policies can be targeted precisely at the dataset; second, replication to the backup target can be driven per dataset; third, ACL inheritance separates media paths cleanly from other shop data. In practice, for Shopware that means /public/media moves to a dataset shop/media, mounted via SMB or NFS depending on the hoster setup and the operating system of the shop instance. For Magento that is the pub/media directory, for WooCommerce the wp-content/uploads path.

Snapshot policy for media: high frequency, tiered retention

For media datasets we usually run a tiered snapshot policy: every six hours a snapshot for three days, daily snapshots for two weeks, weekly snapshots for three months. That sounds like a lot, but thanks to the incremental nature of ZFS snapshots it only costs a few percent of usable storage. The benefit: when someone accidentally deletes a product with all its images in the shop backend, the state from six hours ago is back in minutes — without even having to contact the hoster.

A relevant detail here is separating production media from thumbnails. Thumbnails can be regenerated at any time in Shopware and Magento and do not need to be part of the media snapshot. Those who keep them in there anyway waste disk space. We put thumbnails on a separate dataset without a snapshot policy, so they can be rebuilt from production when needed.

Database backup: consistent, versioned and separated from the shop server

The shop database is the heart of the system and at the same time the largest lever on risk. An inconsistent backup that cannot be restored cleanly is worse than no backup at all, because it creates a false sense of safety. For MySQL/MariaDB behind Shopware, Magento and WooCommerce, we almost always use Percona XtraBackup or mariabackup for consistent online dumps written to the TrueNAS.

Technically it usually looks like this: a cron job on the shop server or a dedicated backup VM creates the consistent dump, compresses it, and writes it into a TrueNAS dataset shop/db-dumps. That dataset has a snapshot policy that reaches three months back — in a three-month rear-view we have resolved every data issue we have faced, from an accidentally emptied category to a failed plugin update that corrupted 400 customer records.

Replication to a second site

In case the primary TrueNAS itself fails or is deliberately compromised, we replicate the database-backup dataset in encrypted form to a second site. That can be a second TrueNAS at the customer, or for smaller setups a TrueNAS Mini R in our data centre. More on the reasoning in our article on backup strategy for SMBs with Proxmox and TrueNAS. The base rule stays: a backup that only sits next to the original is not a backup.

Restore tests belong to operations

An underrated point in shop environments: the restore test. For e-commerce customers we recommend at least one quarterly test restore into a staging environment. That surfaces things no one wants to see — such as a Shopware configuration pointing at absolute paths that do not survive the restore, or a plugin creating an additional database table that was not covered in the dump script. How we structure restore drills is in our own article on the 30-day restore drill.

Snapshots before deployments: the quiet lifesaver

Every shop deployment is an intervention in a live system. Theme update, plugin install, Shopware minor release, PHP version change: all of these are tested, but none of them is risk-free. A TrueNAS snapshot on the media dataset plus a fresh database dump just before the deployment reduces rollback risk dramatically.

The practical workflow we have put in place with customers looks like this: a deployment script — Deployer, Capistrano, GitLab CI or a home-grown bash script — triggers two actions before the deployment itself. First, a manual snapshot on the relevant media and config dataset with a descriptive name, for example pre-deploy-plugin-xyz-20261107-1430. Second, an explicit database dump stored separately from the regular backups.

Why ZFS snapshots win in this scenario

A TrueNAS snapshot is atomic, takes seconds, and consumes no extra disk space until the original changes. That means a deployment snapshot before a Shopware plugin update is practically free at the moment it is created. If the deployment runs through cleanly, the snapshot can be deleted after a few days. If it goes wrong, the rollback is a ZFS operation of a few seconds — plus a database restore from the freshly taken dump.

For the database side we use either a classic SQL dump or an XtraBackup snapshot depending on the customer environment. The decision depends on database size and acceptable downtime: under 5 gigabytes a SQL dump is enough, above that we recommend XtraBackup because the restore is significantly faster.

Staging environments from snapshots: an underrated side effect

A side effect of the snapshot strategy is that it allows a staging environment to be built with little effort. A ZFS snapshot can be used as a clone — a writable copy of the production state that leaves the snapshot itself unchanged. For Shopware or Magento that means a developer gets a staging environment with the current production data in minutes, can test plugin updates or theme changes there, and throws the environment away afterwards.

That reduces the number of errors that only surface in production. Anyone who deploys regularly without a production-like staging state effectively deploys blind. More background on snapshot-based work is in our article on using ZFS dataset quotas and reservations.

Hardware frame: what fits which shop size

For mid-market shop environments, an R-Series or, for flash-heavy setups, an F-Series TrueNAS is a good fit in most cases. A Shopware setup with 500 gigabytes of media data, a 20-gigabyte database and three-month backup retention fits well on an R20 with enough NVMe cache. If virtualisation workloads or a second site are added, an R30 or above is a better plan. The M-Series with M30 and M40 is used for larger shops or group structures — the earlier M50 and M60 are EOL and no longer available for new projects.

For a concrete configuration — pool size, network interfaces, replication topology — our TrueNAS configurator is the fastest way to a quick estimate. We deliberately do not quote fixed prices there because component prices move on a quarterly rhythm; instead, interested customers get an up-to-date price range or an individual quote. The ordering path runs through our TrueNAS purchase section.

A word on hoster versus on-premise

Not every mid-sized shop needs its TrueNAS on-site. In many of our projects the primary system sits in the customer’s server room or network cabinet, and the replication target runs in our data centre. In others — especially when there is no own server room — we handle both sites and connect the TrueNAS to the shop hosting environment via VPN. The path matters less than the goal: media assets and database backups need to be physically and logically separated from the live shop system, otherwise the whole construct is of no use in an emergency.

Conclusion: TrueNAS does not make the shop faster, but a lot more resilient

TrueNAS is not a performance booster for Shopware or Magento. It is the quiet partner in the background that keeps media assets consistently backed up, database backups verified, and deployments rollback-able. In our practice that is the difference between a shop that works day to day and one that still works when something goes wrong.

If you are thinking about how to structure the storage side of your shop infrastructure — whether for Shopware, Magento, WooCommerce or another platform — get in touch. We regularly see where the typical pitfalls are and can propose a frame that fits the size of your shop and your operating model.

FAQ

Does a dedicated TrueNAS make sense when the shop runs at a hoster?

In many cases, yes. The hoster typically supplies a standard backup that is fine for its own availability but rarely good enough for a real restore case. A dedicated TrueNAS with replicated database dumps and media snapshots fills exactly that gap without changing the hoster contract. For mid-market shops above a certain revenue risk, the effort is manageable and the benefit measurable.

Which TrueNAS hardware fits a Shopware shop with around 500 gigabytes of media data?

For that size range, an R-Series — specifically an R20 or R30 — is the typical entry point. The deciding factor is less the raw data volume and more the backup retention and whether a second site is in scope. Concrete configurations can be worked out in the TrueNAS configurator or in a short call with us.

How often should snapshots run on the media dataset?

For active shops we recommend a snapshot every six hours with three days of retention, plus daily snapshots for two weeks and weekly snapshots for three months. Thanks to the incremental ZFS behaviour the space consumption is low, while the benefit on accidental deletions is high. On top of that, an explicit snapshot right before each deployment is important.

How is the shop database backed up to TrueNAS consistently?

For MySQL and MariaDB — the databases behind Shopware, Magento and WooCommerce — we mostly use Percona XtraBackup or mariabackup for consistent online backups. The dump is written compressed to a dedicated TrueNAS dataset, versioned there via snapshots and replicated to a second site. Plain mysqldump SQL dumps are a valid alternative for small databases up to five gigabytes; above that the restore is too slow.

Can TrueNAS serve as live storage for the shop itself?

In most mid-market setups that is not advisable. The live shop keeps running at the hoster or on a dedicated VM platform, while TrueNAS handles backup, media archive and the snapshot role. In special constellations — on-premise shops with a dedicated data centre, for example — a TrueNAS can also serve as NFS or iSCSI back-end for the shop VMs. That is a project to plan individually, not a standard path.

How much time does setting up such a shop storage take?

For a typical mid-market Shopware or Magento setup we plan one to two days for installation, dataset structure, snapshot policies, replication and the initial backup. On top of that comes a structured restore test that we run together once as part of the project. Afterwards operations are largely automatic, with quarterly restore drills as the recommended maintenance rhythm.