Performing actions Before and After the backup task

This documentation is for an older version of CCC. This article has been retired, so it does not exist in the knowledge base for the newest version.
Last updated on 11 december 2017

Often when you have a backup task that runs on a scheduled basis, there are associated tasks that you would like to run before or after files are actually copied. CCC offers the option to run shell scripts before and after a backup task, unmount or set the destination as the startup disk, and power management options such as sleep, reboot, and shutdown.

Scheduled tasks: Before and After settings

Mounting the source or destination volume before a backup task begins

Without any additional configuration, CCC will attempt to mount your source and destination volumes before a scheduled backup task begins. This applies to many different volume types — ordinary volumes on locally-attached hard drives, disk images, network volumes, and encrypted volumes (Lion only). If your source or destination volume is on a disk that is physically attached to your Mac (e.g. via Firewire or USB), but it is not mounted, CCC can "see" that device and will attempt to mount it. If your source or destination is a network volume, CCC will obtain the credentials that you use to mount that device when you create the scheduled task, and will use those credentials to mount the volume before the task begins.

This also applies for nested volumes. For example, suppose you are backing up to a disk image on a network volume. CCC will first attempt to mount the network volume, then it will attempt to mount the disk image. Likewise, suppose you have a task configured to back up the contents of a folder on an encrypted volume. CCC will unlock and mount the encrypted volume before the backup task begins.

CCC's attempts to mount the source and destination volumes occur automatically before any other tasks, including preflight shell scripts (described below), therefore it is not necessary to implement a shell script to pre-mount the source or destination.

Destination volume options

If you would like CCC to unmount your destination volume at the end of the backup task, choose "Unmount the destination volume" from the Destination volume management menu. If your destination is a folder, the text will be "Unmount the underlying volume". If the destination is a disk image, CCC always unmounts the disk image volume, so this setting refers to the underlying physical volume upon which the disk image resides.

CCC will not forcefully unmount the destination volume. If an application has open files on the destination volume, CCC's attempt to unmount the volume will fail. CCC doesn't issue an error dialog for this condition, though it will make a note of it in the CCC.log file.

If you would like to set the destination volume as the startup disk, for example to automate the regular testing of your backup volume, choose "Set as the startup disk" from the Destination volume management menu.

Destination volume management options are only applied when your backup task ends successfully. If errors are reported, the destination volume will not be unmounted or set as the startup disk.

Power management options

If you choose one of the options from the Power management menu, CCC will sleep, reboot, or shut down your Mac when the backup task finishes successfully. The reboot and shutdown options are not forceful. If you have a document open with unsaved modifications, for example, the application would prompt you to save the document. If save dialog is not attended to, the shutdown or reboot request will time out.

Power management options are only applied when your backup task ends successfully.

Running shell scripts before and after the backup task

If there is functionality that you need that does not exist within CCC, pre and post clone shell scripts may be the solution for you. For example, suppose you want to back up your Open Directory Master with CCC at regular intervals, but you know that a simple file-level copy may not properly back up an open database. The following pre-clone shell script will archive your OD master to a disk image for later restoration via Server Admin. It also dumps copies of Server Admin configurations* as well as your MySQL databases. In the event that your standard backup of the database doesn't open, you can later restore it from the dump.

#!/bin/sh
PATH="$PATH:/Applications/Server.app/Contents/ServerRoot/usr/bin"
PATH="$PATH:/Applications/Server.app/Contents/ServerRoot/usr/sbin"
PATH="$PATH:/Applications/Server.app/Contents/ServerRoot/usr/libexec"
export PATH

# Path to recovery directory (permissions should be 700 -- read-only root or admin)
recover="/etc/recover"
ts=`date ''+%F''`


echo "Removing manual archives older than two weeks"
find $recover/ -mindepth 1 -mtime +14 -exec rm '{}' \;

# mysqldump the databases
dbs="some_database another_database mysql"
for db in $dbs; do
    echo "Dumping $db"
    mysqldump --user=root --password='s3kr!t' $db > $recover/${db}_${ts}.dump
    gzip $recover/${db}_${ts}.dump
done

# If you ever need to restore from a database dump, you would run:
# gunzip $recover/database_name_(timestamp).dump.gz
# mysql -u root -p database_name < $recover/database_name.dump


# grab the server configuration plists (only specify services that are enabled,
# use "serveradmin list" for a list of services)
echo "Generating serveradmin configuration plists"
services="afp dhcp dns ipfilter nat network swupdate vpn web"
for service in $services; do
    serveradmin -x settings $service > $recover/serverconfig/$service.plist
    sleep 1
done

# Backup Open Directory
day=`date ''+%u''`

od_backup=$recover/od_backup
echo "dirserv:backupArchiveParams:archivePassword = s3kr!t" > $od_backup
echo "dirserv:backupArchiveParams:archivePath = $recover/od_$ts" >> $od_backup
echo "dirserv:command = backupArchive" >> $od_backup

serveradmin command < $od_backup

 

* Server Admin configuration plists are valuable as documentation of your settings, but they may not be importable to Server Admin directly.

Pre-clone shell scripts run after CCC has performed "sanity" checks (e.g. are the source and destination volumes present, is connectivity to a remote Macintosh established) but before any other tasks (e.g. mounting a destination disk image, copying files). Post-clone shell scripts run after all other tasks have completed, successfully or not. CCC passes several parameters to shell scripts. For example, the following shell script:

#!/bin/sh

echo "Running $0"
echo `date`
echo "Source: $1"
echo "Destination: $2"
echo "Exit status: $3" # Applicable only to post-clone scripts
echo "Disk image file: $4" # Applicable only to post-clone scripts

 

Would produce the following output (typically in /Library/Logs/CCC.log, though you can redirect as desired):

Running /etc/postaction.sh
Wed Aug 14 21:55:28 CDT 2007
Source: /Volumes/Home
Destination: /Volumes/Offsite Backup
Exit status: 0
Disk image file:

If your task specifies a disk image destination, the destination parameter for a pre-flight script will be the path to the disk image. For a post-clone script, the Destination parameter is the path to the mounted disk image volume, and that volume will probably not be mounted if the task finished successfully (it is provided in case CCC is unable to unmount the disk image and you want to post-process this scenario).

Output from your pre- and post-clone shell scripts will be logged in /Library/Logs/CCC.log. CCC may drop the last output from your script, however, because output handling is handled asynchronously to avoid impacting performance of the backup task. To force all output to be logged, you can add "sleep 1" at the last line of your script, or send all output to stderr instead.

Also, if your pre-clone script exits with a non-zero exit status, it will cause CCC to abort the backup operation if you have selected that option. This can be used to your advantage if you want to apply preconditions to your backup operation.

The post-clone script will run whether the backup task exits successfully or not. If your script should behave differently depending on the result of the task, you can test whether the third parameter is zero (an exit status of "0" means the task ended successfully). For example:

#!/bin/sh

source="$1"
dest="$2"
exitStatus=$3

if [ "$exitStatus" = "0" ]; then
    # foo
else
    # bar
fi

Note: Shell scripts must have a ".sh" suffix, or they will be rejected by CCC. Also, you cannot specify an AppleScript, CCC currently only supports running shell scripts.

Example pre and postflight shell scripts

To use any of these example scripts, download the script and place it somewhere on your startup disk. By default, CCC looks in your home folder at Library/Application Support/com.bombich.ccc. To get to that folder in the Finder, hold down the Option key and choose "Library" from the Finder's Go menu.

parallels_pause.sh
This is a preflight script that you can use to pause all currently-running Parallels VM containers. This script will also retain state information that can be read by the corresponding parallels_start.sh postflight script to resume these VMs after the backup task has completed.

parallels_start.sh
This postflight script will resume any Parallels VM containers that were suspended by the parallels_pause.sh preflight script.

play_sound.sh
If you want to play a unique sound, use this script. You can plug in the path to any audio file of your liking or try one of the examples included.

eject_destination.sh
CCC's option to automatically unmount the destination volume is a volume-level task, not a device task. If you want to eject the destination device, use the attached postflight script instead. Note that ejecting the destination device will unmount all volumes on the device. Also note that this example script adds a 60-second delay to accommodate OS X's desire to automatically regenerate various cache files. This delay can be adjusted if necessary by editing the script.