Determining date of an SD backup
 

Is there an easy way of looking at a Super Duper backup disk and determining the date and time it was done. I can sort of get to it by looking for the latest modification dates of files but it's a bit trial and error. This assumes I don't have access to the original log file by the way

There's no really 'easy' way, no...

Dave, why won't the Date Modified in the Get Info window on the target volume work?

Thanks,

Dave P.

Because that's generally modified by Finder directly, and isn't stored in a file or folder... so, you wouldn't see it updated (in my experience).

You can write a shell script, of course, to touch a file in the 'root' of the drive that would have the date/time, but that's not an easy process...

Yesterday I did an SD backup onto a drive that was last used as an SD destination drive in July. The volume Get Info showed a July Date Modified.

Today I checked the volume Get Info and it shows Yesterday as the Date Modified.

Isn't this what's supposed to happen? I'm not sure I fully understand what you're saying.

Thanks,

Dave P.

That's what's supposed to happen, but we haven't found it to be consistent behavior, so I don't consider it reliable.

Any chance of Shirt Pocket adding this as a feature to SD! so users don't have to write shell scripts? It could be selected as one of the 'On Successful Completion' options.

I'd love to be able to rely on the volume Date Modified info to determine the date of the backup.

Dave P.

There's always a chance, Dave, but it's not a widely requested feature.

After backing up "Boot" drive, I have SD run a shell script (named "Finish Boot.command") to run an AppleScript script (named "Finish Backup.scpt") which touches a dummy file (named "Boot Date"). The shell script is:

osascript ~/Documents/SuperDuper/Finish\ Backup.scpt Boot &

The AppleScript script is:

on run {backupDisk}
tell application "Finder"
set modification date of file ((path to documents folder as string) ¬
& "SuperDuper:" & backupDisk & " Date") to current date
end tell
(other stuff here)
end run

Another AppleScript (run at startup) reads the dummy file modification date and notifies me when it's time for the next backup. This has all proven to be extremely reliable.

billearl,

That is very interesting. It surely is more elegant than my technique of putting some blue painter's tape on the drive with the date of the backup.

I think the only thing that would be nice to add would be a contextual menu item "Date of Backup" which would access the date in the file or perhaps display the date in a Get Info.

Cheers

My AppleScript script for that (run from a Butler menu item) is:

tell application "System Events" to set frontApp to name of (processes whose frontmost is true) as string
set SDPath to (path to documents folder as string) & "SuperDuper:"
set buDaysBoot to ((current date) - (modification date of (info for alias (SDPath & "Boot Date")) as date)) / days
tell application "System Events"
activate
display dialog (((round (buDaysBoot * 10)) / 10) as string) & " days since Boot backup." buttons {"OK"} default button "OK"
end tell
tell application frontApp to activate

I run the following shell script at the end of a clone:


#! /bin/tcsh -f
#

set target="$4"
set dsfile="$target/DateStamp.txt"
echo "Latest clone was done on `date`" > "${dsfile}"
echo "Latest clone was done on $target on `date`" >> "/Users/xxxxxxx/Documents/CloneLog.txt"

I clone regularly to two different hard disks. One at home and one at work. The idea of this script is that it rights a file at the top level of the clone with the date it was cloned and it keeps a list on my startup disk of all the clones done. The list on my startup disk is saved with DropBox and, of course, on the clones.

So, in theory, if I can't start up I boot from a clone. Go on the web and look at CloneLog.txt on www.dropbox.com and then I know if I have to restore from the work clone or the home clone and how old they are. In principle DropBox or TimeMachine will make up the stuff since the clone.

Luckily I haven't had to test this setup. Just leaning down to touch the wooden floor ...

Michael

PS: My knowledge of shell scripts is definitely in the "a little knowledge is a dangerous thing" range so use at your own risk.