Creating and preparing RAID arrays for a private ISPConfig mail server Print

Overview

This article explains how to create RAID arrays for use with ISPConfig’s mail system. The arrays will be mounted so that the operating system and mail storage are resilient and optimized. In our example setup, we use:

• RAID1 for SSDs (system disks, hosting the OS and root filesystem).
• RAID10 for HDDs (large-capacity mail storage at /var/vmail).

You may choose other RAID levels depending on your hardware and performance vs redundancy requirements. The same process applies regardless of RAID level.

Step 1: Identify disks

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
mdadm --examine /dev/sda /dev/sdb /dev/sdc /dev/sdd

Check which disks are available. Ensure they are clean and do not contain old RAID metadata or partitions. If they do, clear them:

mdadm --zero-superblock /dev/sda /dev/sdb /dev/sdc /dev/sdd
wipefs -a /dev/sda /dev/sdb /dev/sdc /dev/sdd

Step 2: Create your array(s)

Create an array on the system SSDs (for example, RAID1):

mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/nvme0n1 /dev/nvme1n1

Create an array on the HDDs (for example, RAID10):

mdadm --create --verbose /dev/md3 --level=10 --raid-devices=4 /dev/sda /dev/sdb /dev/sdc /dev/sdd

When prompted, enable the write-intent bitmap to speed up future recovery.

Safe during resync? Yes. Resync starts automatically in the background after creation.

Step 3: Monitor resync

cat /proc/mdstat

The resync runs in the background. It may take hours on large disks. You can continue with the following steps while resync is in progress, but performance will be reduced until it completes.

Step 4: Format the array

mkfs.ext4 -L vmail /dev/md3

Format the array with a filesystem. For mail storage, ext4 is stable and performant. Use a label to help identify the filesystem.

Safe during resync? Yes.

Step 5: Tune the filesystem

# Remove 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: Prevents ~5% of the array being reserved for root (saves TBs on large arrays).
• dir_index: Speeds up directory access when many maildir files are present.
• uninit_bg: Makes fsck faster by lazily initializing metadata.
• journal_data_writeback: Improves write speed; slightly weaker crash consistency, but acceptable for maildir workloads.

Safe during resync? Yes.

Step 6: Get UUID

blkid /dev/md3

Copy the UUID. This is required for /etc/fstab.

Safe during resync? Yes.

Step 7: Mount and configure fstab

mkdir -p /var/vmail

Edit /etc/fstab and add:

# RAID array for mail storage
UUID=abcd1234-ef56-7890-1234-56789abcdef0  /var/vmail  ext4  noatime,lazytime,commit=60,errors=remount-ro  0  2

Options explained:

• noatime,lazytime: Reduces metadata writes.
• commit=60: Commits journal every 60 seconds instead of 5, reducing write load.
• errors=remount-ro: Safer behavior if errors occur.

Apply immediately:

mount -a
systemctl daemon-reload
df -h /var/vmail

Safe during resync? Yes.

Step 8: Persist RAID configuration

mdadm --detail --scan >> /etc/mdadm/mdadm.conf
update-initramfs -u

This ensures the array is recognized and auto-assembled at boot. Without this step, the system may boot without the mail array.

Safe during resync? Yes.

Step 9: Reboot test

It is best to wait until resync completes before rebooting. If you must reboot earlier, the bitmap ensures resync will resume from where it left off.

reboot

After reboot, verify:

cat /proc/mdstat
mount | grep vmail

Conclusion

Your arrays are now created, formatted, tuned, and mounted in the correct place. The RAID setup will survive reboots and is ready for the next stage: installing ISPConfig, which will use /var/vmail by default for mail storage.