Crontab is one of the longest lasting scheduling daemons around, its part of any linux / unix system and uses a file that will trigger a script at a specific time at specific intervals. Cron can be pretty amazing but pretty daunting too if you are unsure about how to use cron, I recommend starting out easy and using this GUI for Mac OSX called Cronnix.

Cronnix is a great tool because it lets you modify, save and create crontab cronjobs in a very easy to use interface. Before Cronnix you basically had to use the VI editor in order to edit the crontab file manually which did not always prove successful. Once your ready to make your first schedule then you need to know what time or at what intervals you want the backup to run. I had my backup script run at midnight every-night so my crontab looked like this.

1

0 0 * * * /bin/bash /path/to/my/sync/script.sh

Here are some other popular crontab examples that might give you some greater insight and understanding on the whole cronjob scheduling schema.

1
2
3
4
5
6

0 0 * * *          -- midnight every day
0 0 * * 1-5        -- midnight every weekday
0 0 1,15 * *       -- midnight on 1st and 15th
                      of month
0 0 1 * 5          -- midnight on 1st of month
                      and every Friday

The second method for scheduling tasks on a Mac OSX Server platform is Launcd. This is the timer system that Apple has written and sanctioned as being the best way to schedule tasks, the reason is that unlike a cronjob where if you want to pause the job, you must remove it from the system entirely and then re-enter it when you want it to resume. With launchd you can unload / or load schedules to run at startup or on regularly scheduled intervals. I would be lying if I told you I was a launchd master, but I do like the advantages that launchd has to offer.

While getting my script up and running I used This tutorial to get me started. The launchd file below is what I used in order to get my backup scheduled. In order to install your launchd file place it in one of these locations.

/System/Library/LaunchDaemons (admin level system daemons)
/System/Library/LaunchAgents (admin level user agents)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

< ? xml version="1.0" encoding="UTF-8" ? >
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" \ "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<dict>
        <key>Label</key>
        <string>com.macresearch.backup</string>
        <key>LowPriorityIO</key>
        <true/>
        <key>Program</key>
        <string>/Users/gohara/Library/Scripts/backup.sh</string>
        <key>ProgramArguments</key>
        <array>
                <string>backup.sh</string>
        </array>
        <key>WatchPaths</key>
        <array>
        <string>/Volumes</string>
        </array>
</dict>
</plist>

Once you have your launchd file installed you must register the launchd file with your system by running

1

  launchctl load ~/Library/LaunchAgents

Then issue

1

 launchctl list

Then you should see something like this

1
2

[Voyager:~/Library/Scripts] gohara% launchctl list
com.macresearch.backup

for my sync script I chose to use a crontab, because my knowledge of launchd is limited and my experience with cronjobs is more extensive I found that adding a cronjob was faster, quicker and more efficient for permanent scheduled items on my servers. I would love to get your feedback however and learn more about launchd from you.

The one great thing about 10.5.8 was the development of Mailbfr this was an amazing script that would help you backup your entire mailstore, recover email accounts, repair quotas, and of course rebuild or repair the entire mail-store. This was an invaluable tool, however since switching we have had to come up with our own solution.

We tried at first to get RSYNC running however this did not work because we did not have the permission to copy the mailstore with the permissions in tact. The reason is that while the root account does have access to look at the mailstore the secondary user on the mailstore folder is the mail user itself. Without running the script as each user then its near impossible to use RSYNC to move the mailstore or to even perform a simple backup.

Our solution was to create a backup script that use SCP with SCP we were able to move our mail-store to another drive on the server. It copies the store over and it resets the permissions to the administrator account. This solution works very well however after some time with a large mailstore you will run out of space on the target volume. Unlike RSYNC which uses hard links to save space SCP creates a new copy of the mailstore each time it is run.

In order to save space on the backup volume the oldest 2 weeks worth of backed up email gets dumped to DVD and removed from the drive on a monthly basis. This is fine but not optimal. Here is a copy of the script that we use on our server.

1
2
3
4
5
6

#!/bin/bash
echo backup started daily backup `date` >> /Volumes/EMAIL\ BACKUP/Backup/Logs/Backup_log.txt
 
scp -r /Volumes/Mailstore-Location/spool /Volumes/EMAIL\ BACKUP/Email-Backups/$(date +%d)-$(date +%m)-$(date +%Y)backup 
 
echo backup daily backup completed `date` >> /Volumes/EMAIL\ BACKUP/Backup/Logs/Backup_log.txt

This will backup the mailstore and then log each time that it does so. To recover an email to the original mailstore is not as hard as it seems. Navigate to the backed up mailstore destination and match up the name of the folder to the users UID of which you want to recover. For example if the users UID is 7458-58713-952554-544226 then you would look for a folder with the same name. Once in the folder you can copy or look at individual email files. Find the ones or one that you need and copy it to the folder of the original mailstore. In order to do this you will have to use sudo. For example this is how you would restore the entire folder

1

sudo scp -r "Volumes/EMAIL\ BACKUP/Email-Backups/7458-58713-952554-544226/.*" "/Volumes/Mailstore-Location/spool/7458-58713-952554-544226/.*"

Until Mailbfr comes back for Dovecot this is how we are protecting ourself against the accidental loss of email. I am not saying that this is the best method it is simply the one we are using. If you have another solution that works bette than please let me know and share your own experience!