http:// qmail.jms1.net / 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 For qmail alias
qmaild qmaill qmailp

Groups
nofiles qmail

qmailq qmailr qmails

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:
/var/qmail/alias /var/qmail/control /var/qmail/users

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:

If a given message is in the queue when the backup is done, that message will almost certainly have been delivered and properly removed from the queue by the time a restore is needed. If you were to restore the queue, that same message would be delivered again, which would probably confuse the recipient. More importantly, it's impossible to correctly restore these files in the first place. The filenames of the actual messages (the files in the /var/qmail/queue/mess directories) must match their inode numbers, and there is no way for a "restore" process to create a file with the correct inode number. What is an inode? On most "unix-style" filesystems, files don't really have names of their own- each file is an "inode", and each inode is identified using a unique number within that filesystem. The filenames that we're all used to using are really just names which point to inode numbers. The inodes are the actual files- they hold the files' contents, permissions, ownership information, timestamps, and some other housekeeping information. Each filename consists of the name itself, and the inode number it corresponds to. This kind of arrangement makes it possible for one file (inode) to have multiple names pointing to it. Cases where multiple names point to the same inode are known as "hard links", and can be created using the "ln" command (when used without the "-s" option.)

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:

The ~vpopmail/domains directory tree contains the contents of every mailbox in every domain on the system, along with their passwords and quota information. Of course, if you compiled vpopmail to use mysql, you will need to use something like mysqldump or mysqlhotcopy to make a backup of the entire database containing that information, and you will need to restore it at the same time you restore the mailbox directories. The ~vpopmail/etc directory MIGHT need to be backed up. It may contain a few configuration items- for example, if you are using vpopmail with mysql then this directory will contain the file holding the mysql credentials that vpopmail will use to connect to the database. Depending on the version of vpopmail that you use, it may also contain an onchange script which you will have written and/or customized. If you do back up this directory, you should NOT back up the inc_deps and lib_deps files. These files will be created by the vpopmail install process on the new system, and contain information which is specific to that machine. Copying these files from one server to another can cause problems on the new machine.

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:
/usr/lib/courier-imap/etc/imapd /usr/lib/courier-imap/etc/imapd-ssl /usr/lib/courier-imap/etc/pop3d /usr/lib/courier-imap/etc/pop3d-ssl /usr/lib/courier-imap/share/imapd.pem /usr/lib/courier-imap/share/pop3d.pem

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