http:// / backup.shtml

Backing up a qmail system

Some of the most common questions that I see have to do with backing up a qmail server, restoring from that backup, or migrating a domain (or a set of domains) from one server to another.

Most peoples' first instinct is to just back up the entire /var/qmail and /home/vpopmail directory trees. While this will preserve the content, chances are that when you try to restore these directories, the result will not be usable. This is because there are some very specific requirements for the ownership, permissions, and inode numbers (which cannot be directly modified) of some of the files involved.

This page will explain these issues, and show you how to make a safe and usable backup of a qmail server.

User and Group IDs

The most important thing to remember when working with the actual files that qmail and vpopmail create, is that the ownership of the files must be maintained in addition to the content of the files. This is because both qmail and vpopmail have the numeric "UID" codes for the qmail userids on the system compiled into the programs, and if these UID values are not the same when you restore the data, the qmail and/or vpopmail programs will have problems accessing the restored files.

The same is true for the "GID" values of the groups whcih are used by qmail and vpopmail- they must have the same numeric value on the system where you restore the files, as they did on the system from which you backed up the files.

This is probably not an issue if you are restoring files to the same system where you backed them up- as long as the numeric values in the /etc/passwd and /etc/group files (or your system's equivalent) did not change from the time the backup was made until the time you restore the files.

The users and groups whose UID and GID values must be preserved are:

Users Groups
For qmail alias
For vpopmail vpopmail vchkpw

What I do is this- whenever I build a qmail server, for myself or for a client, I always use the exact same numeric values for the users and groups created as part of the initial setup. I make it easier for myself by using scripts to install qmail and vpopmail. I don't give out copies of my scripts (please don't ask) but I will show an example of what the relevant lines from that script look like:

For qmail...

groupadd -g 161 nofiles
groupadd -g 162 qmail

useradd -u 161 -g 161 -s /bin/true -M -d /var/qmail/alias -c 'QMail alias user' alias
useradd -u 162 -g 161 -s /bin/true -M -d /var/qmail -c 'QMail daemon user' qmaild
useradd -u 163 -g 161 -s /bin/true -M -d /var/qmail -c 'QMail log user' qmaill
useradd -u 164 -g 161 -s /bin/true -M -d /var/qmail -c 'QMail password user' qmailp
useradd -u 165 -g 162 -s /bin/true -M -d /var/qmail -c 'QMail queue user' qmailq
useradd -u 166 -g 162 -s /bin/true -M -d /var/qmail -c 'QMail remote user' qmailr
useradd -u 167 -g 162 -s /bin/true -M -d /var/qmail -c 'QMail send user' qmails

For vpopmail...

groupadd -g 89 vchkpw
useradd -u 89 -g 89 -M -d /vpop vpopmail

The "useradd", "adduser", "groupadd", and "addgroup" commands work differently on different systems, including different Linux distributions, and even different versions of those distributions. This page originally used "adduser" because that's what worked on RedHat 7.3, which was current at the time- however I'm now (2008-12-16) using CentOS 5, and "adduser" is just a symlink to "useradd" (they used to be two different commands which did the same job but took their command line arguments in different manners.) The commands above do work with CentOS, and I've been told they work with Debian and Slackware as well. However, you should check the documentation for your own system before running these commands or committing them to a script.

I use the numbers 161-167 for the qmail UIDs and GIDs because on the systems I use (all RedHat and derivatives, or Debian) the "system" UIDs defined by the distro are all lower than 100, while normal user accounts start with 500, so I figured these numbers were safe (and so far they have been.) Using 89 for vpopmail is a semi-official standard, the BSD guys have officially assigned 89 to vpopmail for this purpose and so far I haven't found any conflicts with Linux. Be aware of what you're doing, and check your system first to make sure these numbers aren't already being used by some other UID/GID before running these commands, and if they are, choose different numbers.

Backing up qmail files

Making a backup of just the relevant qmail information is actually rather simple. You really only need three directories within the /var/qmail tree:

Backing up the entire /var/qmail tree is generally not a good idea. In particular, the /var/qmail/queue directory should not be backed up at all, for two reasons:

An emergency measure, if you have already tried to restore a /var/qmail/queue directory tree and found out the hard way that you shouldn't do it, is the qfixq script. Part of what it checks is to make sure that the mess filenames match their own inode numbers. If it finds a message where they don't match, the "fix" will rename the appropriate files (in all directories of the queue) to match the new inode number. While this will give you a working queue, it's not an ideal solution because it changes the message numbers within the queue, and tools such as the mtrack script which correlate log entries by using the message numbers will become confused. The messages will still be delivered, but mtrack won't be able to correctly show you that information.

If you're backing up a qmail system, you should also back up any information needed to restore your services to proper operation- in particular, any services' "run" scripts which you may have modified or customized.

And finally, if you are using any tcpserver access control lists, you should back these files up as well. On my own server this means backing up the entire /etc/tcp directory, however not everybody organizes their tcpserver access control files the same way I do. You should know where these files are on your system, and make sure they are backed up as well.

Backing up vpopmail files

Backing up a vpopmail system is also fairly easy. Again make sure you are preserving the user and group ID, and then back up the following directories:

Backing up courier-authlib and courier-imap

The courier-authlib and courier-imap packages don't have any real "data" to save, like the contents of the mailboxes or the configuration of the entire qmail system. The only things you really need to save are the configuration files for authdaemond (from courier-authlib) and the IMAP and POP3 services.

For courier-authlib, you should back up the /etc/authlib directory, which contains the files which configure authdaemond and some of the specific authentication modules.

For courier-imap, you should save the following files:

In addition, if you are running courier-authlib and/or courier-imap from daemontools, you should also save the "run" scripts from the services.