Trouble recovering emails, questions about recovering crons.

[bobsomebody]

Ok, so I finally had the fantastic fun filled experience of dealing with a motherboard failure on my production server at my data center. Techs got the parts all swapped out in amazing time. I was able to import all the websites and resolved all the issues I ran into with relative ease.

Unfortunately I cannot figure out two things. Well, first and foremost being that I have no idea how to recover email settings and data from linux and port them to a newer system. So far all the version numbers look the same so I dont see any compatibility issues with the data. I spent a good deal of time on google and these forums. This helped me locate the two related mail dir's in each users home dir ( $user/imap and $user/Maildir ). I copied those over on a few users and updated user permissions to match the new system. Nothing happened though. I'm by no means an email guru, shame on me for being lazy and relying on web based email systems. (I'd also like to recover roundcube and squirlmail settings/data if there is any)

If I continue stabbing in the dark on this email issue I'm sure I'm only going to succeed in breaking it further. I instead decided to post this and see if I can get some good feedback, maybe someone else who hit this issue and knows how to resolve it?

The second thing isn't so much something that I don't know how to do, its just something I'm not sure how to do easily, recover all those users crontabs and restore them to the new system.

Note that the new system and the old system pretty much match. I did switch to an x64 OS to catch up with the times.

Forgive me if I left out any needed details or information.

 

[chatwizrd]

If you have 2 systems now I would just do admin level backup and restore. Then this is all you would have to do to restore everything.

http://help.directadmin.com/item.php?id=57

Everything for email is in the users home dirs. The configs for email are in /etc/virtual

All the software that runs everything for directadmin can be reinstalled with custombuild

If you need to reinstall everything you can do:

cd /usr/local/directadmin/custombuild
./build update
./build clean
./build all d

If there is any cronjob data it would be in /usr/local/directadmin/data/users/<username>/crontab.conf

 

[DominionHosting]

If you have access to the old data even if its just the hard drive mounted as a slave I would be willing to help you.

 

[bobsomebody]

Chatwizard: I didn't know about the /etc/virtual location, this is probably the part of the puzzle I'm missing. Also its a single system with the old data mounted as a secondary drive.

DominionHosting: I'd be happy to hear how to safely complete this process. I wasn't able to find much in the way of Directadmin email recovery. Well not much that dealt with bulk operations in command line. Most everything I dug up was years out of date or was nothing more than the backup restore feature in DA.

 

[DominionHosting]

On the old drive cd to the home directory where all the users are located.

tar -cf Maildir.tar ./*/Maildir
tar -cf imap.tar ./*/imap

Then extract in the home directory of the new drive.

That is all your mail itself. The mail settings are in /etc/virtual just tar up /etc/virtual and extract it on the new drive.

 

[bobsomebody]

I was finally able to get it all moved over to the new drive. Well not the whole mess, but enough of a test pool that I can see this is going to work. I got hung up in the /etc/virtual step. I started with a couple cp's (using -fp) to move the data into the right spots. chown'ed those files to match the new users.

It should be noted for future lurkers that if you follow the info in this post, you will need to edit the passwd file in the respective /etc/virtual/domain.com folder and update the user numbers. I spent about 5 hours chasing permission errors when all I needed to do in the first place was change the old user id to the new user id and bang, it all came back to life.

Also, for others in this rut, make a test user to double check folder permissions being produced. Mine differed slightly from the new DA system to the old. It will help sort out that spool of permission errors in your logs

Still cant get the crons to copy over, but in all honesty, they are just one liners that I could reproduce easy enough. Thanks for all the help everyone.