View Single Post
  #1  
Old 09-12-2009, 09:06 PM
avramd avramd is offline
Registered User
 
Join Date: Sep 2009
Posts: 2
Requesting "Ultra-smart" TM-based backup feature

Hello,

I would like to open a discussion about a possible new feature. Obviously the panacea that everyone wishes either TM or SD! could do is automatically maintain a bootable backup that is up-to-date within the hour.

I believe I just discovered how SD! could do it; I would like a feature where SD combines TimeMachine's backup data, with the inode comparison technique used by timedog, to "UltraSmart Update" to a bootable backup drive by only copying the files that TimeMachine has found changes in since the last time the feature was used on the same target drive.

timedog is able to detect changes between TM backups incredibly quickly because it simply compares inodes. Since TM makes hard links for directories that have not changed, timedog does not have to scan the contents of a directory if its contents did not change. The heavy-lifting of identifying changes has already been done by Time Machine.

Some timedog performance bites: 1.5 secs to identify the changes of a 70-change TM backup of a 2.8GHz MBP w/ 90GB used on the drive being checked), and 2 min to identify the changes of a 20,000-change TM backup of the same drive (this was after updating to iPhoto 9 & letting it update my photo library).

Another benefit of this strategy is that it should be able to run from a network TM backup (e.g. TimeCapsule), since the image file mounts locally as a true HFS+ partition - so the generation of the up-to-date bootable backup could happen on another machine - and you can even take your machine away since TM is already done with it.

Also, you wouldn't need to be this pro-active with SD! - You can just run it say weekly, and let TM do it's thin in the mean time. Then after a crash, you run it again to turn your week-old SD! backup into a <1hr old one.

One obvious caveat of this technique is that the *first* backup would itself have to be generated from Time Machine data, to ensure proper continuity. Rather than building that capability into SD!, it would probably make more sense to generate it using TM's own restore feature.
Reply With Quote