What does "Check Archive *really* check?

Dear folks,

I have a question about the " Check Archive" function in TI 9. Does it merely confirm that the archive is uncorrupted or does it do a file comparison with the source partition to confirm that it's *accurate*?

I suspect the former. In which case it would be really valuable to add a "verify" option for advanced users. I don't much like Retrospect but I do like the fact that actually verifies files ... A LOT! Merely checking the integrity of the archive will only catch about two-thirds of archive errors. I acknowledge that it will catch the most catastrophic ones (ones that make the entire archive unreadable) but I should be able to confirm that my backup is really good, not just probably good.

I understand that there are some caveats that go with this: doing a verify pass flags any files that have changed between the time of back up and the verification, which means you'll always get one or two hits from system files even when doing an immediate verification. It will also be a lot slower than just analyzing a checksum. This is why I'm recommending it be an option for advanced users only. And the first caveat suggests that the smart place to include this would likely be as an option when you set the task, not as a function that you can call it any time, since running it much later would turn up a whole lot of changed files and probably just confuse people.


pax / Ctein
[[ Please excuse any word-salad. ViaVoice in training! ]]
=========================================
-- Ctein's Online Gallery http://www.ctein.com
-- Digital Restorations http://photo-repair.com
=========================================

 

Good point you bring up.

To insure that nothing changes on the source disk this should all take place in the standalone environment. Both the creation of the image and it's verification. This way Windows does not come into play at all.

Doing what you suggest under Windows is not 100% as you rightly point out. Bypassing files that have been changed might lead to a false sense of security. What if a bypassed file happens to be corrupt on the image?

This is better done in the standalone environment.

 

This should be 100% even w/windows ,in case TI locked the HDD before verification finished. Otherwise how can TI make image under windows?

 

I don't think ATI locks the drive in the truest sense. You can still do stuff when ATI is taking an image. From my understanding, all subsequent file updates, once ATI takes a 'snapshot' of the partition, are rerouted through ATI itself. ATI writes it to some buffer of sorts. When the particular sector the file is located on is done processing by ATI it then writes out the data from the buffer to where it really belongs on disk. This way ATI images your partition the way it looks at the moment you take the image and why you can still update files without this causing ATI to have fits.

So when ATI is done imaging, the live partition will be different then the image. So a verify under Windows can't be 100% unless all those buffered files are saved and the verify is done with them instead of the 'real' files on disk.


Something like this.

 

Thanks for your clarification. So if TI will implement the new verification feature, the buffer release should be done after been verified.(not just been imaged).

 

Dear "upurz,"

That's a very good question, and it's also an example of why this is something I would make an advanced user option.

The answer your question is that very few files change quickly under Windows (not counting documents you're working on directly, which is obvious). You can confirm this for yourself by doing a search on your system partition for files modified in the last one day (which won't turn up that many) and then sort them by modification time. If you ignore obvious deadwood like "~*.tmp" files, you'll not find a lot. For instance, on my Windows 2000 partition, in the last 90 minutes only a dozen files changed that weren't temp files or the documents I was actually working on. And the big five, the "software.*" "ntuser.*" and "tvDebug.log" which are updated very frequently, are well known to any advanced user.

In my system partition, which I intentionally keep bare, all the files that changed in the past 90 minutes consume less than 2% of the file space. So, *if* corruption occurs while reading out the partition for archiving (which is extremely unlikely to start with) there's only one chance in 50 that it's going to happen to a file that you ignore because you know it's volatile.

To put it another way, you'll catch 98% of those rare bad disk reads, which is 98% more than you catch if if you aren't doing a true verify. That's good enough for me. I think locking down the system or having to run from a boot CD to guarantee that you're not modifying ANYTHING while the verify is going on is unnecessary overkill.

By the way I do still run Retrospect on my Mac systems, because there it's the best backup software around.I really, truly, don't find it at all confusing when it reports that a couple of system files that I know to be volatile don't match the backup during verify. Actually, it reassures me that the verify function is really working


pax / Ctein
[[ Please excuse any word-salad. ViaVoice in training! ]]
=========================================
-- Ctein's Online Gallery http://www.ctein.com
-- Digital Restorations http://photo-repair.com
=========================================