Backing up SquirrelMail
 

I have a server running Debian Sarge, EXIM4, Courier IMAP and PoP servers, and Squirrelmail. It works fine, but I want to back up the files (yeah, I know, its a bit of an abberation to be backing stuff up, but humour me:) )

I have set up an alternative server, and by shifting the contents of the ~/Maildir/ directories, and the squirrelmail "data" directory I have most of the configuration and some of the mail files. However, there is a problem....

On the original server , there are additional subdirectories under "INBOX", like "INBOX.jobs" and "INBOX.richard". I can't find them anywhere on the original server, though Squirrelmail finds them fine.

Anyone got any ideas where Squirrelmail puts additional directories, and is there a proper way of simply backing up the server? doing it the way I have is only partial, and not something I want to rely on...

how does mail get into these locations? normally this is the job of the SMTP server or a secondary process kicked off by it, like procmail. squirrelmail itself wouldn't put mail in these folders unless you configure rules and things, which i didn't even think it could do (and the idea of a single client being in control of a server based data set potentially accessed by multiple clients is horrible anyway. if you want a copy, you could use a client like fetchmail on the backup box to just periodically pull all mail down over imap fairly simply, or use a forwarder on the main server to push all mail to a secondary mail server.

as for where those folders actually are, it's probably most likely that INBOX.jobs is ~/Maildir/.jobs note the "." so it'd be hidden by default.

D'Oh!
 

:mad: I must be getting old! Thanks Chris, talk about having to tell me the bleedin' obvious! It's a wonderful thing the "-al" switch, especially when used with "ls"!

They're all there! All sitting in ~/Mailbox/ as hidden files, all available to mail clients, and all available to back up if I were just to remember basic UNIX commands...

i think that's one all then ehh?

But I won the penalty shootout....
 

...because you didn't mention imapsync...I've worn google to death after totally trashing my target ~/Maildir structure, cp-ing files from the original server to the new one, and imapsync suddenly appeared as a way forward. I'll see how it works tonight when everyone is offline :)

Have you any experience of imapsync? howtos, warnings gratefully accepted.

"Making Mistakes" is how I learnt Linux...and am still learning, thank god!

no, i found imapfilter the other day, but not imapsync. there are loads of ways you could synchronize mail, a full sync would be more involved and complete than a relpication of initial data i guess. whilst a tool called imapsync sounds like a good tool for the job you could still use rsync or many other tools to create a file level sync.

Imapsync
 

OK, final comment on this from me....

Ran imapsync last night, after installing it on just the system I was migrating to. Did a vanilla sync, specifying source/target notes and their credentials, and let it rip. It spat out a couple of lines of message that I'm sorry to say I did not note down. However, about that time it ran the processor util up to 100%, put all the fans on, and made the server look stressed. It then did nothing for about half an hour. I ran Ethereal on the target node to see if stuff was being taken, and there was no communication at all. I stopped (<cntlC>) imapsync, and punched temporary holes in the firewalls, both ways, for TCP 143, and restarted.

I was running with the "--dry" option, which shows all the console messages, but does nothing to the files (yeah, I've been burnt before). Anyway, the process ran properly this time (D'oh!) finished with a bunch of messages that indicated success, so I let it loose without "--dry". It ran for about 30 mins, completed, and although I had started with a slightly toasted ~/Maildir/ (see earlier posts!) the final result was a perfect replica with all files in place, flags spot on, it even brought a mail across that arrived during transfer time, and retained the "unread" status on the new server.

It makes the processor sweat, though! I was running on a single 3.06G Intel P4, and it just sat there at 100% for the entire duration, with the fans at full speed, so while this is a good utility, and it does what is says it will do, it's certainly not something I would want to run on a Monday at 0900!!!

Hope this is useful to someone, If I'd read this last week I could have saved myself about 10 hours of headscratching and swearing :)