1. Backing up the OD Master with Bash

#!/bin/sh
 
NOW=$(date +"%m-%d-%Y")
 
# Path to recovery directory (permissions should be 700 -- read-only root or admin)
recover="/Volumes/ODBackup"
 
# Backup Open Directory
day=`date ''+%u''`
 
od_backup="$recover/od_backup - "$NOW""
ts=`date ''+%F''`
echo "dirserv:backupArchiveParams:archivePassword = 908239032" > $od_backup
echo "dirserv:backupArchiveParams:archivePath = $recover/od_$ts" >> $od_backup
echo "dirserv:command = backupArchive" >> $od_backup
 
serveradmin command < $od_backup

The above script when run on a daily basis through CRON or LAUNCHD will create a recoverable sparse disk image of your OD Master that you can use to restore from, it saves each master with a date time stamp so you can see which one is which and the instructions to restore are logged to a separate file. The two variables you must change are

# Path to recovery directory (permissions should be 700 -- read-only root or admin)
recover="/Volumes/ODBackup"

This should be the location you want your OD Master backups to live, and

echo "dirserv:backupArchiveParams:archivePassword = 908239032" > $od_backup

the password must be changed as well in the above example the password is 908239032 you can change it to anything you want, this is required to restore when you attempt to restore your OD Master backup in Server Admin you will be prompted for this password.

2. Create an OD Master Replica

Before you start the firewall on the OD Master, the Firewall on the OD Replica server and the Firewall on your router must all have the following ports open, and or port forwarded to their appropriate destination. Open Ports 389, 636, 625, 22, 3659, 106, and 88.

1. Make sure the master, the prospective replica, and every firewall between them is configured to permit SSH communications (port 22).
   You can enable SSH for Mac OS X Server in Server Admin. Select the server in the Servers list, click Settings, click General, then select the Remote Login (SSH) option.

   Make sure that SSH access is not restricted to certain users or groups (using SACLs) on the prospective master. This will cause Server Admin to not have the necessary permissions during creation of the replica. You can temporarily disable SACLs in Server Admin under Settings > Access.

2. Open Server Admin and connect to the server.
3. Click the triangle to the left of the server.
   The list of services appears.
4. From the expanded Servers list, select Open Directory.
5. Click Settings, then click General.
6. Click Change.
   The Service Configuration Assistant opens.
7. Choose Open Directory Replica, then click Continue.
8. Enter the following requested information:
• IP address or DNS name of Open Directory master: Enter the IP address or DNS name of the server that is the Open Directory master.
• Root password on Open Directory master: Enter the password of the Open Directory master system’s root user (user name system administrator).
• Domain administrator’s short name: Enter the name of an LDAP directory domain administrator account.
• Domain administrator’s password: Enter the password of the administrator account whose name you entered.
9. Click Continue.
10. Confirm the Open Directory configuration settings, then click Continue.
11. Click Close.
12. Make sure the date, time, and time zone are correct on the replica and the master.
    The replica and the master should use the same network time service so their clocks remain in sync.

Again the point here is to have a place for your users to authenticate against that can easily be fixed if any issues arise, in my setup I use the replicas to bind clients to for computer authentication, bind my Mail server to for account information and also use it as the basis for my LDAP environment. Replicas are great because they also reduce the response time, and since each server is synced as the users change their passwords or information its virtually instant. If a client is bound to my replica and the replica has a problem it will search for the next nearest replica, connect and authenticate against that which means almost no downtime as well.

3. Carbon Copy Cloner
I am a huge fan of this software which can be found at Carbon Copy Cloners website. I use this software to do a full, incremental clone of my server, which is great because at any given time I can boot off of the backup drive and or restore directly to my server.

I am not going to write another how to on using Carbon Copy Cloner except to link to their own how to section which goes over it in so much more detail than I could here.

Scheduling Tasks in Carbon Copy Cloner >>
Backup Options for Carbon Copy Cloner >>
A more granular approach to Backup (Must Read!!!) >>

If you find their software useful I urge you to donate.

Wrapping things up a bit, I am a big fan of backups and these three options will keep you covered in the event of an Open Directory nightmare! If you have comments or other solutions I am always happy to hear from you and let me know how you approach backups with your systems!

** Note
I was not able to get the above script to run properly with Cron, but it does however with LaunchD. Here is my LaunchD script, I named it com.odbackup.plist and placed it in the /Library/LaunchDaemons/ folder on my server, the script is set to run the backup every morning at 7:45am

<?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 >
<plist version="1.0">
    <dict>
        <key>Label</key>
        <string>com.odbackup</string>
        <key>ProgramArguments</key>
	<array>
	<string>/bin/sh</string> 
        <string>/path/to/backup/script/backup.sh</string>
        </array>
        <key>StartCalendarInterval</key>
        <dict>
            <key>Hour</key>
            <integer>7</integer>
            <key>Minute</key>
            <integer>45</integer>
        </dict>
    </dict>
</plist>

then you start the proceess by running load ctl /Library/LaunchDaemons/com.odbackup.plist or whatever you named it to see if its in the list run launchctl list.

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.

#!/bin/bash
 
echo Sync started `date` >> /Volumes/Logs/Sync_log.txt
 
echo "Now starting rsync"

At this point we are ready for the sync to start, we will start by syncing the files from the primary server to the secondary server. This is a one way sync, whatever we add to the primary server will be copied over to the secondary server. Whatever is deleted from the primary server will also be deleted from the secondary server we accomplish this via the use of rsync.

rsync -avz --delete "/Volumes/PrimaryWebsite/" --rsh='ssh -p8286' username@XX.18.XX.22:www/domains/SecondaryWebsite

Notice that the first line is the path to our primary website, the second value is the port number that you use to ssh into your secondary server if they require that. The third option is the username and the ip address or hostname of the secondary server and then the path to the files on the secondary server. Again in order for this to work you really have to have completed the first step if this is not working refer back to the article that covers the appropriate way to ssh into your remote server Syncing a failover website : Creating an SSH key.

echo "Now starting modifications"
 
scp -oPort=8286 "/Volumes/modifications/wp-config.php" username@XX.18.XX.22:www/domains/SecondaryWebsite

What we are doing above is copying a modified version of the wp-config.php file because we use wordpress installations as our main CMS platform, the configuration settings on the primary server will not always match exactly the configuration settings on your secondary server. Which means that if you failover and the settings on the secondary server are the ones from your first server, and the secondary server uses a different database prefix, username or password the failover will succeed but it will failover to a website that will give you the dreaded “Cannot connect to database” error.

echo "Now starting database sync"
 
mysqldump --user=primarymysqlusername --password=primarymysqlpassword primarydatabasename | ssh secondarysshusername@XX.18.XX.22 -p8286 mysql --user= secondarymysqlusername --password= secondarymysqlpassword secondarydatabasename
 
echo Sync finished `date` >> /Volumes/Logs/Sync_log.txt

The above code, will allow you to sync your database with the database in your secondary location. You will need to modify the settings to match your primary username and password for mysql. Your secondary username and passwords for mysql and the primary and secondary database names in mysql. What this does is it empties the target database and then it re-imports all the content from your primary server. Then it logs a line in the log, stating when it has completed. Here is what the finished script looks like.

#!/bin/bash
 
echo Sync started `date` >> /Volumes/Logs/Sync_log.txt
 
echo "Now starting rsync"
 
rsync -avz --delete "/Volumes/PrimaryWebsite/" --rsh='ssh -p8286' username@XX.18.XX.22:www/domains/SecondaryWebsite
 
echo "Now starting modifications"
 
scp -oPort=8286 "/Volumes/modifications/wp-config.php" username@XX.18.XX.22:www/domains/SecondaryWebsite
 
echo "Now starting database sync"
 
mysqldump --user=primarymysqlusername --password=primarymysqlpassword primarydatabasename | ssh secondarysshusername@XX.18.XX.22 -p8286 mysql --user= secondarymysqlusername --password= secondarymysqlpassword secondarydatabasename
 
echo Sync finished `date` >> /Volumes/Logs/Sync_log.txt

Thats about it, in our next and final article on the topic of syncing multiple websites on multiple servers for failover purposes we will talk about the proper way to schedule your sync.

First, you must have DNS that can process a failover, you must have a script that will sync your files and your databases and most importantly of all you must have an open SSH tunnel between the two servers so that the sync can perform in a secure way without risk of any hacking happening. In this article I am going to outline the process of creating an ssh key for your second server, using terminal, and CPANEL. The failover hosting company we chose uses CPANEL and before we started we had to ask our host to enable jailed SSH access on our account in order to proceed.

Once enabled we must go through the process of creating a set of keys, a public key, and a private key. You must create the key on the computer that is considered to be the primary or the computer that will be running the sync script. Once your logged into that computer run these commands in terminal to create your private and public keys.

 mkdir ~/.ssh

 cd ~/.ssh

 ssh-keygen -b 1024 -t dsa -f id_dsa -P ''

 chmod 400 id_dsa

Now in your ~/.ssh folder you should have an id_dsa file, an id_dsa.pub and a file called authorized_keys. The first file is your private key. The second file is your public key. The last file is a file that protects your primary server, meaning no one will be able to ssh into your primary server without the public or private keys as a form of authorization.

On the secondary server with CPANEL login to your control panel and choose SSH from the list of options. Once there, press the “Import Keys” button and you will see two fields one for a public key one for the private key. Copy and paste the contents of your private key id_dsa on your primary server into the private key field. Copy the contents of id_dsa.pub into the second field labeled public key. Name the key, in the top field and press save.

Now that you have the keys there, you must authorize the keys, once you have you will be able to ssh into your secondary server from your primary server without entering your password. Your host may have you connect to their ssh tunnel using a custom port, if this is the case then this is the syntax.

 ssh -p8569 username@host_name

This will give you access to your account area, in our next article we will talk about how to create the sync script and sync your files, and databases over from the primary server to the secondary server on a scheduled basis.

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!

*** UPDATE 12/8/2011 ***
Here is the script that I am using to date for your use. It logs the backups and emails me when they are complete.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

#!/bin/bash
 
# This adds a record to our backup log
 
echo backup started daily backup `date` >> /Scripts/Logs/Backup_log.txt
 
# This backs up the files
 
rsync -avu /location/of/mail/spool /Volumes/backup-volume/
 
# This adds another record to our backup log
 
echo backup daily backup completed `date` >> /Scripts/Logs/Backup_log.txt
 
# This emails the Sys Admin
 
NOW=$(date +"%m-%d-%Y")
 
SUBJECT="Email Backed Up - "$NOW""
 
EMAIL="email@user.com"
 
EMAILMESSAGE="/Scripts/Logs/Backup_log.txt"
 
mail -s "$SUBJECT" "$EMAIL" < "$EMAILMESSAGE"

The easiest way to start / stop this is to setup a LaunchD or Cronjob, I prefer Cron since its easier in my opinion to setup. Setup the rsync script that you have below and put the code in a bash script. I use a GUI tool called Cronix http://code.google.com/p/cronnix/ once you download this launch it and put the full path to the bash script at the bottom the cron job code for every ten minutes is

0/10 * * * * * /path/to/bash/script.sh