PDA

View Full Version : ZeroScan


Anyse
06-01-2008, 04:33 AM
I was reading about 3 software programs from Decimus called Synk (backup, standard and pro). What caught my eye is the technology called "ZeroScan." They describe it as a log created by the program/system of files that have been added, changed, or deleted and that, when the program is run, only those files will be changed accordingly. As they say, and it would seem to be true, this makes a full scan of the backup drive unnecessary and saves a lot of time with the backup process AFTER the first backup has been created, of course.

To me, this seems like a really good deal so that my disks aren't working as hard and the overall time is cut to a quick CD sized set of files to be changed. I remember one backup program long ago in the System 7 days that also did this and never got off of the ground!

What are the "disadvantages" to a ZeroScan scheme of things as opposed to what SuperDuper does. I can't find ANYTHING wrong with SuperDuper so far. However, I would like to know more about how SuperDuper approaches the synchronization process. Does it only synchronize files at the time of operation? If so, what would one expect to be the scan times for 100, 200, 300, 500, 750 and 1000GB drives?

Thank you so much and I hope that this will not be too much work for you.

I can say that, in my correspondence with you in the past, you, like your product, are "SuperDuper!"

Anyse

dnanian
06-01-2008, 08:18 AM
ZeroScan basically relies upon the 'fsevents' daemon, which is a kernel-level feature that 'broadcasts' all file changes at a very low level. It was exposed differently in Leopard so that you can find out what folders have been modified for a given time.

There are a lot of disadvantages to using the 'older' style, which ZeroScan was originally based on, most of which are highly technical and beyond the scope of what I think is appropriate.

In Leopard, the new FSEvents database has some advantages -- since it's fully supported and doesn't require kernel-level event trapping. But it's also brand new technology, has some fragility that requires full scanning in many situations, and isn't yet terribly mature.

Since SuperDuper! can scan and backup quite quickly -- for example, my own typical 2+million file backup takes about 20 minutes, including the time to scan and copy. Since it's scheduled for the middle of the night, I don't really care about the minutes that might be saved by doing the scan a different way, especially given the fact that it might need to be done that way anyway... considering that the underlying facility to provide the information is still pretty young, and really only 'properly' available in Leopard (and we support Tiger, too).

So -- while we're looking at FSEvents for future versions of SuperDuper! -- the time saved didn't seem worth the risks... especially given the fact that SD! (unlike Time Machine, which also uses FSEvents) isn't designed to run constantly, and is typically run when you can certainly afford the extra few minutes needed to do a full, complete, thorough -- and correct -- scan.