Move Cyrus mail folders: best practice?
Günther Schwarz
/var/spool/imap is slowly filling up. So I want to move the mail folder
to another partition on the server. I'm a newbie with Cyrus so I would
like to know if one of the following two schemes will be preferable. I do
not find a comment on this on the project's web pages:
1) Change the entry in /etc/imapd.conf, e.g.
old:
partition-default: /var/spool/imap
new:
partition-default: /new_partition/imap
Will this break something when starting up again?
2) Move the folder to /new_partition/imap and then setting a link:
/var/spool/imap -> /new_partition/imap
This should not require any changes in the configuration files, but might
be considered as ugly if one wants to keep the filesystem clean.
Sorry if this is a FAQ or a somehow stupid question.
Günther
Grant Taylor
> /var/spool/imap is slowly filling up. So I want to move the mail folder
> to another partition on the server. I'm a newbie with Cyrus so I would
> like to know if one of the following two schemes will be preferable. I do
> not find a comment on this on the project's web pages:
I have not dealt with Cyrus but I have dealt with this type of problem
with other things.
> 1) Change the entry in /etc/imapd.conf, e.g.
> old:
> partition-default: /var/spool/imap
> new:
> partition-default: /new_partition/imap
> Will this break something when starting up again?
This will work if you can find all the locations that reference the old
path and update them to the new path. The catch is that there is always
a chance that you will miss something.
> 2) Move the folder to /new_partition/imap and then setting a link:
> /var/spool/imap -> /new_partition/imap
> This should not require any changes in the configuration files, but might
> be considered as ugly if one wants to keep the filesystem clean.
This is my personal preferred method of doing this. I have done this
with things from databases to web servers to you name it.
> Sorry if this is a FAQ or a somehow stupid question.
I don't think this is a stupid question at all.
I think I'd do #2 for sure. I might also consider doing #1 so that
access to files does not have to traverse the sym-link. But I would
definitely do #2.
Another option (3) would be to mount a new file system directly on to
/var/spool/imap and not change the path at all.
The only problem that I can see is if there is something else out side
of /var/spool/imap that needs to hard link to something in
/var/spool/imap. If this is the case, that would also have to be moved
to the new file system. Though this is extremely unlikely as things
like this usually are under a common directory. BackupPC is an example,
but it too puts everything under it's backuppc directory, where ever it
is located.
Grant. . . .
Günther Schwarz
> On 08/27/09 14:20, Günther Schwarz wrote:
>> 1) Change the entry in /etc/imapd.conf, e.g. old:
>> partition-default: /var/spool/imap
>> new:
>> partition-default: /new_partition/imap Will this break something when
>> starting up again?
>
> This will work if you can find all the locations that reference the old
> path and update them to the new path. The catch is that there is always
> a chance that you will miss something.
That is what I'm worried about. I do not know much about how the imapd
works. It somehow keeps a database of the mail folders which might or
might not contain absolute path names.
>> 2) Move the folder to /new_partition/imap and then setting a link:
>> /var/spool/imap -> /new_partition/imap This should not require any
>> changes in the configuration files, but might be considered as ugly if
>> one wants to keep the filesystem clean.
>
> This is my personal preferred method of doing this. I have done this
> with things from databases to web servers to you name it.
This is safe to do in most cases. But it can't be excluded that there are
relative directives of the form ../../some_directory. Bad programming,
but not completely unknown.
>> Sorry if this is a FAQ or a somehow stupid question.
>
> I don't think this is a stupid question at all.
>
> I think I'd do #2 for sure. I might also consider doing #1 so that
> access to files does not have to traverse the sym-link. But I would
> definitely do #2.
>
> Another option (3) would be to mount a new file system directly on to
> /var/spool/imap and not change the path at all.
This I did not think about. Thanks for the hint.
> The only problem that I can see is if there is something else out side
> of /var/spool/imap that needs to hard link to something in
> /var/spool/imap. If this is the case, that would also have to be moved
> to the new file system. Though this is extremely unlikely as things
> like this usually are under a common directory.
ACK, this will be highly unlikely. Let's see if an expert for Cyrus will
comment on the questions.
I'm a bit frightened to make the move. It is not a big server, but still
some of the users have large mail folders. Besides avoiding to mess up
the thing completely I also want to make sure that the clients stay
synchronized and do not have to freshly load all the mail headers.
Günther
hgd
IMHO, the best approach, and the one we regularly use, is to leave the
old partition alone and add another one. Add a line
partition-new (or whatever you want to call it)
to your imapd.conf, plus the line
defaultpartition: new (if that's what you called it)
That way, new users will be created on the new partition. You can move
folders from the old to the new by using cyradm's rename command. We
even run a cronjob that automatically moves folders across partitions,
depending on how full the partitions are ... currently we have 4
partitions with more than 3 TB in total.
Guenther Schwarz
> On Aug 27, 9:20 pm, G�nther Schwarz <st...@gmx.de> wrote:
>> cyrus-imapd-2.2.3-83.35
>>
>> /var/spool/imap is slowly filling up. So I want to move the mail folder
>> to another partition on the server.
> IMHO, the best approach, and the one we regularly use, is to leave the
> old partition alone and add another one. Add a line
>
> partition-new (or whatever you want to call it)
>
> to your imapd.conf, plus the line
>
> defaultpartition: new (if that's what you called it)
OK, this way I do not have to "cheat" the imapd with links or additional
mounts.
> That way, new users will be created on the new partition. You can move
> folders from the old to the new by using cyradm's rename command.
So with cyrus-imapd-2.2.3-83.35 assuming an inbox for user alice with
subfolders "user.alice (\HasChildren)" and a second partition called "new":
# cyradm --user cyrus localhost
localhost> renamemailbox user.alice user.alice new
This will move the inbox for user alice and all her subfolders to the
new partition, right? Excuse me for asking in such detail, but I do not
have a second installation available to play with.
G�nther
Guenther Schwarz
> hgd wrote:
>> You can move
>> folders from the old to the new by using cyradm's rename command.
>
> So with cyrus-imapd-2.2.3-83.35 assuming an inbox for user alice with
> subfolders "user.alice (\HasChildren)" and a second partition called "new":
> # cyradm --user cyrus localhost
> localhost> renamemailbox user.alice user.alice new
>
> This will move the inbox for user alice and all her subfolders to the
> new partition, right?
So after defining the new partition in imapd.conf and reloading I get
the following error:
# renamemailbox user.alice user.alice new
renamemailbox: System I/O error
G�nther
Guenther Schwarz
> Guenther Schwarz wrote:
> So after defining the new partition in imapd.conf and reloading I get
> the following error:
> # renamemailbox user.alice user.alice new
> renamemailbox: System I/O error
Note to self: always check the file permissions and ownership prior to
posting error messages :-)
A second error occured because cyrus-imapd-2.2.3-83.35, in contrast to
what the local man pages say, only accepts one version of the command
syntax:
# renamemailbox --partition new user.alice user.alice
This works just fine and moves alice's inbox as well as all subfolders
to the new location.
Thanks for the kind help.
G�nther
Grant Taylor
> This I did not think about. Thanks for the hint.
*nod*
LVMs make this even better.
Though, I think I like what hgd has suggested better.
Grant. . . .
hgd
I'm glad it worked for you.
Günther Schwarz
> On 08/27/09 15:44, Günther Schwarz wrote:
>> This I did not think about. Thanks for the hint.
>
> *nod*
>
> LVMs make this even better.
It is actually an EVMS/LVM system. But then in general I prefer to create
a new partition instead of resizing an existing one. I'm too afraid to
break things.
> Though, I think I like what hgd has suggested better.
Seems to be the cleaner solution as it keeps the files system more tidy
and simple. The configuration of Cyrus get only slightly more complex.
Günther