SuperDuper! scripts redux
October 14, 2009 at 12:58 PM by Dr. Drang
You may have heard that a new version of SuperDuper! was released yesterday, so I thought I’d repost my SuperDuper! scripts. I don’t think I’ve made any changes since these scripts were first posted, but this seemed like a good time to bring them all together in a single article.
I use SuperDuper! instead of Time Machine because I like the idea of having a complete, bootable clone of my startup drive, and SuperDuper! is probably the easiest way to make such a clone. My experience with hard disk failures has taught me to clone the entire drive instead of just my data. Hard disk failures never happen at a convenient time, and reinstalling the operating system and all your applications can take forever. When you need to get your computer back up and running, there’s nothing better than booting from an external drive and having your normal working environment there for you.
On my office Mac, I have SuperDuper! set up to do a backup automatically every weeknight. The backup drive is always plugged in and running, but I prefer to have it unmounted except when the backup is being made. This keeps the disk off my Desktop and and prevents me from inadvertently opening it, reading from it, and—worst of all—writing to it. I have two shell scripts, mount_backup and unmount_backup, that SuperDuper! runs before and after the copy via these settings in its Advanced Options pane:
Both scripts use the diskutil program, both to get the drive identifier for the backup disk and to to [un]mount it. Here’s a typical output from running diskutil list:
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk0
1: EFI 209.7 MB disk0s1
2: Apple_HFS HD 499.8 GB disk0s2
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: Apple_partition_scheme *500.1 GB disk1
1: Apple_partition_map 32.3 KB disk1s1
2: Apple_Driver43 28.7 KB disk1s2
3: Apple_Driver43 28.7 KB disk1s3
4: Apple_Driver_ATA 28.7 KB disk1s4
5: Apple_Driver_ATA 28.7 KB disk1s5
6: Apple_FWDriver 262.1 KB disk1s6
7: Apple_Driver_IOKit 262.1 KB disk1s7
8: Apple_Patches 262.1 KB disk1s8
9: Apple_HFS Backup 500.0 GB disk1s10
From this, we see that the backup disk (the one I’ve cleverly named “Backup”) has a device identifier of disk1s10. It’s this device identifier that has to be passed to the diskutil mount and diskutil unmount commands. Putting everything together, the mount_backup script is
1: #!/bin/bash
2:
3: BDISK=`/usr/sbin/diskutil list | awk '$3=="Backup" {print $6}'`
4: /usr/sbin/diskutil mount $BDISK > /dev/null
and the unmount_backup script is
1: #!/bin/bash
2:
3: BDISK=`/usr/sbin/diskutil list | awk '$3=="Backup" {print $6}'`
4: /usr/sbin/diskutil unmount $BDISK > /dev/null
In both scripts, awk is used to extract the device identifier from the output of diskutil list.
The new version of SuperDuper! has an option to eject (unmount) the backup disk after copying in the General Options pane.
This would suggest that unmount_backup is no longer needed, but it looks to me as if you cannot choose an option that both ejects the backup disk and quits SuperDuper!, so I’m sticking with my script.
My third SuperDuper! script extracts a few lines from the SuperDuper! log file. It’s a Perl script called dupersummary:
1: #!/usr/bin/env perl
2:
3: # Where the log files are kept.
4: $dir = "$ENV{'HOME'}/Library/Application Support/" .
5: "SuperDuper!/Scheduled Copies/" .
6: "Smart Update Backup from HD.sdsp/Logs";
7:
8: # Get the contents of the directory.
9: opendir DIR, $dir;
10: @allfiles = readdir DIR;
11:
12: # Restrict to log files.
13: @logs = grep /\.sdlog$/, @allfiles;
14:
15: # Pick out the latest log file.
16: @logs = reverse sort @logs;
17: $latest = $logs[0];
18:
19: # Get the contents of the latest log file.
20: open LOG, "$dir/$latest";
21: @lines = <LOG>;
22:
23: # Start the output.
24: # push @wanted, "******************** SuperDuper! ********************\n";
25:
26: # Pluck out the lines of interest and delete extraneous text.
27: push @wanted, grep /Started on/, @lines;
28: push @wanted, grep /PHASE:/, @lines;
29: push @wanted, $lines[-2];
30: grep {s/^\| //; s/\\//; s/ Info \|//;} @wanted;
31:
32: print join "", @wanted;
SuperDuper! keeps its log files in the deeply nested folder indicated on Lines 4-6. The exact name of this directory depends on the name of the disk being backed up and the type of backup being done. Because my startup drive is called “HD” and I’m using a Smart Backup (I can’t imagine why you’d use anything else), the parent directory of the log folder is called “Smart Update Backup from HD.sdsp.” For most people, I suspect that directory would be called “Smart Update Backup from Macintosh HD.sdsp.”
The real purpose of dupersummary is to output a few lines of the most recent log file for displaying on the Desktop via GeekTool.
I do this to reassure myself that last night’s backup was successful, but I doubt it’s really necessary. The few times the backup has failed (usually because I had for some reason turned off the backup disk during the day and forgot to turn it back on), SuperDuper! has remained open; its presence on my screen when I walk into my office is all I need to tell me that something went wrong the night before. Still, I keep it running just in case.
As I said at the top, there’s nothing really new in this discussion; it’s just a summary and reorganization. The original posts in which these scripts are discussed are here, here, and here. You may find a bit more detail in them.
Finally, although I really like SuperDuper! and have always found it to be rock-solid and reliable, I must question Shirt Pocket’s claim that the new version, 2.6.2, is up to twice as fast as the previous version. For me, last night’s backup with the old version took 32 minutes; today’s backup—a test run of v2.6.2—took 25 minutes. This is really no improvement at all considering how few files had changed between the two backups. Maybe the big speed improvement has come with non-Smart backups—when every file is copied instead of just those that have changed—but I have to think that non-Smart backups are a pretty rare use of the application.
