Overview
This guide shows you how to create software RAID arrays with mdadm for a self-managed ISPConfig mail server, then format, tune and mount the storage so the operating system and the mailboxes are both resilient and fast. The worked example uses two arrays:
- RAID1 across two SSDs (or NVMe drives) for the system disk, hosting the operating system and root filesystem.
- RAID10 across four HDDs for large-capacity mail storage mounted at
/var/vmail.
You can choose other RAID levels to suit your hardware and your own balance of performance against redundancy. The process below is the same regardless of the level you pick.
Important scope note: the root RAID1 is normally created during operating-system installation (the Debian and Ubuntu installers both support software RAID at partitioning time). You cannot build a fresh RAID1 over the disk that is currently running your root filesystem. This guide therefore concentrates on the dedicated mail-storage array at /var/vmail, which can safely be added to a server that is already up and running.
Last reviewed: 27 July 2026, against mdadm on current Debian and Ubuntu Server releases, for use with ISPConfig 3.3.1p1. This guide is written for Noiz hosting and is kept current against the Linux RAID and ISPConfig documentation. It complements, and does not replace, the official documentation linked below.
Official Documentation Reference
- Linux RAID Wiki: RAID setup (kernel.org)
- mdadm(8) manual page
- tune2fs(8) manual page (ext4 tuning)
- ISPConfig official documentation
Prerequisites
- Root (or
sudo) access to the server console. - Dedicated, empty disks for the data array. Never target the disk that holds your running operating system.
mdadminstalled:apt install mdadm.- An understanding that creating an array is destructive to every disk you name. Back up anything you cannot lose before you begin.
Step 1: Identify the disks
List the block devices and confirm exactly which drives you intend to use before you touch anything:
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
mdadm --examine /dev/nvme0n1 /dev/nvme1n1 /dev/sda /dev/sdb /dev/sdc /dev/sdd
Make sure the disks you plan to use are clean and carry no old RAID metadata or partitions. If they still hold stale metadata, clear it:
mdadm --zero-superblock /dev/sda /dev/sdb /dev/sdc /dev/sdd
wipefs -a /dev/sda /dev/sdb /dev/sdc /dev/sdd
Warning: zero-superblock and wipefs permanently erase RAID and filesystem signatures. Run them only against the empty data disks you have positively identified with lsblk. Never run them against a disk that is mounted or that holds the running operating system, or you will destroy the server.
Step 2: Create the array or arrays
Create the system array across the SSDs or NVMe drives (RAID1 in this example). As noted above, do this only at install time or from a rescue environment, never over a live root disk:
mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/nvme0n1 /dev/nvme1n1
Create the mail-storage array across the HDDs (RAID10 in this example). This one can be added to a running server:
mdadm --create --verbose /dev/md3 --level=10 --raid-devices=4 /dev/sda /dev/sdb /dev/sdc /dev/sdd
When prompted, keep the write-intent bitmap enabled. It costs almost nothing and lets a future rebuild or resync resume only the changed regions rather than re-scanning the whole array, which is a large saving on multi-terabyte disks.
Safe during resync? Yes. The initial resync starts automatically in the background as soon as the array is created, and you can continue to the next steps while it runs.
Step 3: Monitor the resync
cat /proc/mdstat
The resync runs in the background and can take several hours on large disks. You may continue with the steps below while it is in progress, but expect reduced throughput until it finishes. For a live progress view, run watch -n5 cat /proc/mdstat.
Step 4: Format the array
mkfs.ext4 -L vmail /dev/md3
Format the array with a filesystem. For maildir mail storage, ext4 is stable and performs well. The -L vmail label makes the filesystem easy to identify later.
Safe during resync? Yes.
Step 5: Tune the filesystem
# Remove the root-reserved space
tune2fs -m 0 /dev/md3
# Directory indexing for large maildirs
tune2fs -O dir_index /dev/md3
# Faster filesystem checks
tune2fs -O uninit_bg /dev/md3
# Optional: faster journal mode
tune2fs -o journal_data_writeback /dev/md3
-m 0: removes the default reservation (around 5% of the array) that is normally set aside for the root user. That reservation protects a system partition from filling completely, but on a dedicated data array it just wastes space, potentially terabytes on a large array.dir_index: speeds up lookups in directories that hold many files, which is exactly what a busy maildir store becomes.uninit_bg: lazily initialises block-group metadata so thatfsckruns faster.journal_data_writeback: improves write throughput at the cost of slightly weaker crash-consistency guarantees for file data, which is an acceptable trade-off for a maildir workload. Leave this off if you prefer the safer default ordered mode.
Safe during resync? Yes.
Step 6: Get the UUID
blkid /dev/md3
Copy the UUID value from the output. You need it for /etc/fstab in the next step. Always mount by UUID rather than by device name, because /dev/mdX numbers can change across reboots while the UUID does not.
Safe during resync? Yes.
Step 7: Mount and configure fstab
mkdir -p /var/vmail
Edit /etc/fstab and add a line for the array, substituting the UUID you copied above (the value below is only an example):
# RAID array for mail storage
UUID=abcd1234-ef56-7890-1234-56789abcdef0 /var/vmail ext4 noatime,lazytime,commit=60,errors=remount-ro 0 2
What the mount options do:
noatime,lazytime: cut down on metadata writes by not updating access times on every read.commit=60: flushes the journal every 60 seconds instead of the default 5, reducing write load. In a power-loss event this widens the window of data that could be lost, so choose the value deliberately.errors=remount-ro: remounts the filesystem read-only if an error is detected, which is the safer behaviour for mail storage.
Reload the unit definitions and mount everything from fstab:
systemctl daemon-reload
mount -a
df -h /var/vmail
Confirm that df shows /var/vmail on the array at the expected size. If mount -a reports an error, re-check the UUID and the fstab syntax before rebooting, because a bad fstab entry can leave the server unable to boot cleanly.
Adding the array to a server that already runs ISPConfig? Two things bite here. Mounting an empty filesystem over /var/vmail hides the mail already stored there, so stop the mail services, copy the existing contents onto the array and only then mount it over the top. And a newly formatted filesystem is owned by root, so hand the mountpoint back to the mail user once it is mounted, matching the ownership and mode the directory had beforehand:
chown vmail:vmail /var/vmail
vmail is the default Mailuser Name and Mailuser Group, both set on the Mail tab under System > Server Config. Read those two fields first if your server uses different values.
Safe during resync? Yes.
Step 8: Persist the RAID configuration
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
update-initramfs -u
This records the arrays so they are recognised and auto-assembled at boot. Without it, the system can boot without the mail array attached, leaving ISPConfig with no mail storage. After running the append, open /etc/mdadm/mdadm.conf and remove any duplicate ARRAY lines if you ran the command more than once.
While that file is open, set the MAILADDR line to an address you actually read. Debian and Ubuntu run mdadm in monitor mode as a service, and that address is where the warning goes when a disk drops out of the array.
Safe during resync? Yes.
Step 9: Reboot test
Ideally, wait until the resync completes before rebooting. If you must reboot sooner, the write-intent bitmap ensures the resync resumes from where it left off rather than starting over.
reboot
After the server comes back up, verify that the array assembled and the mount is present:
cat /proc/mdstat
mount | grep vmail
Checking the array from the ISPConfig panel
If ISPConfig is already installed on this server, you do not need an SSH session to check the array. Go to Monitor > Server State > RAID state, which shows the same /proc/mdstat output used in Step 3, with a status flag on top of it. A degraded array is flagged critical, unless a rebuild is already running, in which case it is flagged as information only.
Two caveats. The page shows a snapshot collected by a scheduled job, so it can sit a few minutes behind the command line. And the status flag is worked out from two-disk mirror patterns, so on a four-disk RAID10 treat the panel as a convenience view and keep the mdadm email alert from Step 8 as the alarm you rely on.
Troubleshooting
Array does not appear after reboot: confirm Step 8 was completed, that /etc/mdadm/mdadm.conf contains the ARRAY line, and that you ran update-initramfs -u afterwards.
mount -a fails or the server drops to an emergency shell on boot: this is almost always a wrong UUID or a typo in /etc/fstab. Re-run blkid /dev/md3 and compare it against the fstab line character for character.
Resync appears stuck at 0%: check cat /proc/mdstat for a queued state. Only one resync runs at a time per controller, so a second array may wait for the first to finish.
Next steps
Your arrays are now created, formatted, tuned, mounted and persistent across reboots. You can proceed to installing ISPConfig, which needs no path changes to use this array. The mail settings default to a Homedir Path of /var/vmail and a Maildir Path of /var/vmail/[domain]/[localpart], so the mailbox for [email protected] lands in /var/vmail/yourdomain.com/user. Both fields sit on the Mail tab under System > Server Config.
If you mount the array somewhere other than /var/vmail and edit those fields to match, keep Maildir Path inside Homedir Path. A maildir path that is not below the home directory will most likely stop the mail system working.
Point the backup directory at the array
ISPConfig writes its backups to one location, set in the Backup directory field on the Server tab under System > Server Config. It defaults to /var/backup, which is on the root disk. Change it to a directory on the dedicated array, for example /var/vmail/backup, so that backups cannot fill the system partition. Mailbox backups are filed there in a subdirectory per mail domain, alongside any website backups, and on a busy mail server they grow quickly.
Leave Backup directory is a mount? on the same tab unticked for an array mounted from /etc/fstab as above. That option is for a backup target that has to be attached on demand: it makes ISPConfig run /usr/local/ispconfig/server/scripts/backup_dir_mount.sh before the backup starts, and you have to write that script yourself.
One caution on placement. A RAID array survives a disk failing, not a mailbox being deleted or a filesystem being corrupted, so treat the array as the fast local copy and keep a second copy off this server.
Need a managed mail server instead?
Building and maintaining a self-managed mail server is involved, from RAID and storage tuning through to deliverability and security hardening. If you would rather Noiz handle the infrastructure, the Noiz support team can advise on managed hosting options that remove this operational burden. Reach the team through your Noiz client area.
