choosing a file system

[Jorey Bump]

Andrew McNamara wrote, at 01/19/2009 01:29 AM:
>> Yeah, except Postfix encodes the inode of the queue files in its queue
>> IDs, so it gets very confused if you do this.  Same with restoring
>> queues from backups.
> 
> You should be able to get away with this if, when moving the queue to
> another machine, you move the queued mail from hold, incoming, active and
> deferred directories into the maildrop directory on the target instance.
> 
> This (somewhat old, but still correct, I think) message from Wietse
> might shed more light on it:
> 
>     Date: Thu, 12 Sep 2002 20:33:08 -0400 (EDT)
>     From: wietse at porcupine.org (Wietse Venema)
>     Subject: Re: postfix migration
> 
>     > I want to migrate postfix to another machine. What are also the steps so 
>     > that I won't lose mails on the process?
> 
>     This is the safe procedure.
> 
>     1) On the old machine, stop Postfix.
> 
>     2) On the old machine, run as super-user:
> 
>             postsuper -r ALL
> 
>        This moves all queue files to the maildrop queue.
> 
>     3) On the old machine, back up /var/spool/postfix/maildrop
> 
>     4) On the new machine, make sure Postfix works.
> 
>     5) On the new machine, stop Postfix.
> 
>     6) On the new machine, restore /var/spool/postfix/maildrop
> 
>     7) On the new machine, start Postfix.
> 
>     There are ways to skip the "postsuper -r ALL" step, and copy the
>     incoming + active + deferred + bounce + defer + flush + hold
>     directories to the new machine, but that would be safe only with
>     an empty queue on the new machine.
> 

This has become somewhat off-topic for this list, but you might be able
to simply sync the entire Postfix queue to the backup machine, and run
postsuper -s before starting Postfix on the backup. From the postsuper
man page:

  -s     Structure  check and structure repair.  This should be done
         once before Postfix startup.

         Rename files whose name does not match the message file inode
         number. This operation  is necessary after restoring a mail
         queue from a different machine, or from backup media.

The important thing to keep in mind is that Postfix embeds the inode
number in the filename simply to keep the name unique while the message
resides on the filesystem. Obviously, this approach breaks when the
files are copied to another filesystem. Renaming them appropriately on
the new destination ensures no files will be overwritten as the queue is
processed or new messages enter the queue. Of course, the scheme I
proposed earlier requires that once the backup Postfix is brought up, it
must be impossible for the primary to begin resyncing files to the same
location on the backup if it becomes active again (or refuses to die a
graceful death). Certainly tricky, but it sounds like the use case is to
 preserve the queue in case of a total failure, just to make sure the
mail goes out (even it means it goes out twice).