Error 206 in Retrospect 6.1: Can snapshot be re-done?

[baweeks]

First time ever got this error; longtime user of Retro since v.4.x days. Retro 6.1.230; driver 6.1.16.100, Intel C2Duo MacBookPro 4,1 running 10.5.7. Log gave no notices during the copy phase of an incremental backup, but gave a few thousand lines like this:

 

Trouble reading: “A-Backup MiniWork†(444452933), error 206 (drive reported a failure: dirty heads, bad media, etc.).

 

with the only difference between each line was that the long number in parentheses increased by (3) (three) on the last digit (e.g., 444452936 for the next line, vs. the line above).

 

I noticed the power cord to the external hard disk was a little loose. Pushed it in better. Tried another incremental backup, and it worked fine, although there were just a hundred or so log files, sync files, etc., to back up. This worked fine with no issues (save the usual compare error of some log files having been written to between the time of copy and time of compare).

 

Question 1: Is that snapshot of several thousand files, including many documents I want backed up, hosed?

 

Question 1a: If we cannot be sure if those files in that snapshot are hosed or not, can we re-perform a backup of >just those files in that snapshot?<

 

Question 1c: Or, can we ask 6.1 to at least verify the files in just that snapshot? Watching Retro compare this second backup, it didn't seem to me like it compared the thousands-of-files in the failed snapshot immediately before; the compare of this followup snapshot just took a few seconds.

 

How does Retrospect manage this type of thing and how should I best respond to it?

 

Thanks to all.

baweeks

[twickland]

A snapshot is just a listing of the file and folder structure of a given source volume at the time of a particular backup, and is part of the backup set's catalog. By default, Retrospect retains only the most recent snapshot for each source volume in the catalog, but earlier snapshots are stored on the backup set's media.

 

It sounds like you may instead be questioning the integrity of the backup set itself or its catalog. You could go to Tools> Repair> Repair file backup set (if that's the type of backup set you're using) and see if things seem OK. Tools> Verify will perform a more thorough examination of the data. I would also test and confirm that you are able to successfully restore data from the backup set.

[rhwalker]

First time ever got this error; longtime user of Retro since v.4.x days. Retro 6.1.230; driver 6.1.16.100, Intel C2Duo MacBookPro 4,1 running 10.5.7. Log gave no notices during the copy phase of an incremental backup, but gave a few thousand lines like this:

 

Trouble reading: “A-Backup MiniWork†(444452933), error 206 (drive reported a failure: dirty heads, bad media, etc.).

 

with the only difference between each line was that the long number in parentheses increased by (3) (three) on the last digit (e.g., 444452936 for the next line, vs. the line above).

 

I noticed the power cord to the external hard disk was a little loose. Pushed it in better. Tried another incremental backup, and it worked fine, although there were just a hundred or so log files, sync files, etc., to back up. This worked fine with no issues (save the usual compare error of some log files having been written to between the time of copy and time of compare).

It's unclear from the incomplete information provided whether the data on the tape gave an error during the "read-after-write" verification that many drives do (without intervention by Retrospect) using a separate "read" head following the "write" head, such that it was a "read-after-write" comparison error reported by the drive during the write phase, or whether this was a read error during Retrospect's verification phase. Regardless, it's highly unlikely that futzing with the power plug changed anything. Best remediation in such situations is to do a cleaning cycle with a cleaning tape (although there is a remote chance that a power disturbance could have caused a "read-after-write" verification error.

 

Question 1: Is that snapshot of several thousand files, including many documents I want backed up, hosed?

Unclear. See above. Because Retrospect only backed up a few files on the next incremental, Retrospect thinks that the files were backed up, which probably indicates that the error occurred during Retrospect's verification phase.

 

twickland correctly states:

 

A snapshot is just a listing of the file and folder structure of a given source volume at the time of a particular backup, and is part of the backup set's catalog. By default, Retrospect retains only the most recent snapshot for each source volume in the catalog, but earlier snapshots are stored on the backup set's media.

The "snapshot" isn't stored on the tape, but the files are (and other information needed to create the snapshot). In order for Retrospect to figure out what a past snapshot is, it has to review the history of files backed up in each session and figure out what the "snapshot" (files present during the session) was at that time. That's the basis of the Zulch patent:

Zulch, U.S. Patent 5,150,473

See also:

Zulch, U.S. Patent 5,966,730

 

You can also get Retrospect to show more snapshots than the "most recent" one by, for example:

Immediate > Restore, Restore files from a backup,

Select a backup set, Add Snapshot, Select a session, Retrieve

 

and the chosen snapshot will be rebuilt from the information in the backup set (you don't have to actually do the restore).

 

So, you could try to get Retrospect to show your questionable past snapshot using the above procedure, see what you get.

 

Question 1a: If we cannot be sure if those files in that snapshot are hosed or not, can we re-perform a backup of >just those files in that snapshot?<

See above for a discussion. If Retrospect thinks that the files in that snapshot are in the backup set, it won't back them up again. The files either are in the backup set or they aren't, regardless of what happened in the verification phase (if that's where the error occurred). I don't think you really want to ask the question that you are asking because "just those files in that snapshot" includes all files on the disk at that instant, regardless of whether they were backed up during that session.

 

Remember, Retrospect's "snapshot" paradigm is an illusion of what was on the disk when the session occurred, and has little relation to the files actually backed up during that session. That's the magic of Retrospect, which permits you to browse files for restore as if you were browsing a listing of the disk at the time the backup session occurred, rather than a listing of the files backed up during that incremental session. Think of the snapshot as a database of pointers into the entire past backup history of the backup set; as files change without deletion, the pointers for those files in the new (most recent) snapshot are updated to point into more recent incremental sessions. With other backup technologies, you first have to restore the initial "full" backup and then every incremental from that point forward so that later incremental copies of files overwrite the earlier ones.

 

Question 1c: Or, can we ask 6.1 to at least verify the files in just that snapshot? Watching Retro compare this second backup, it didn't seem to me like it compared the thousands-of-files in the failed snapshot immediately before; the compare of this followup snapshot just took a few seconds.

Two problems here. First, it's unclear from your problem description whether Retrospect was looking at the "right" older snapshot. See above regarding how to get Retrospect to show older snapshots (after rebuilding them from the backup set). Second, the files may have changed in the interim, so compare errors may be found that are unrelated to your particular tape errors (dirty heads, whatever).

 

The "right" solution, not possible in Retrospect 6.x (but possible in Retrospect 8.x and in Windows Retrospect 7.x) is to calculate MD5 polynomials (digests) on the files as they are written, and to save those MD5 digests in the catalog. Then, when you want to verify the integrity of the backup sets, you read the backup set and recalculate the MD5 digests for the files in the backup sets, compare that recalculation with the MD5 calculations at the time of the backup. If the two don't compare, then the integrity of the files in the backup set is known to be bad, regardless of the cause, without having the original files for comparison. Clear?

 

How does Retrospect manage this type of thing and how should I best respond to it?

See above, do a cleaning cycle on your tape drive, verify the backup set tape. That tells you that the tape is good (or bad, as the case may be). If the tape is bad, mark the member as missing, do another backup, and Retrospect will back up all of the still-present files of that missing member, because they will all be marked as not being backed up. If the tape is good, then add the older snapshot (see above), do some test restores. You may want to rebuild the catalog from the tape just for good measure before doing all of this, although I don't see anything in your problem statement that would lead me to think that there is anything wrong with your existing catalog.

 

Of course, to cover the case of your primary backup set's tapes going bad, you are doing alternating backup sets, aren't you? Review the above discussion and you will realize that Retrospect will "do the right thing" for your alternating backup set because whatever happens to the primary backup set (including what files were backed up in the primary) doesn't affect the secondary backup set, which is treated independently. Understanding this takes a bit of reflection after review of the above.

 

Does this sound like a plan?

 

Russ

[rhwalker]

baweeks,

 

Upon re-reading your post, it's unclear whether tape is involved because specifics of the destination device aren't clearly given.

 

The underlying strategy given above, however, is still sound.

 

If you have a disk or optical media involved, use Disk Utility to verify the media. If it's a disk and there are disk errors found, decide whether you value the backup history on the disk. If you don't care about the backup history, then reformat the drive using Disk Utility (with a zero erase to cause every sector to be rewritten and with bad sectors being re-mapped to good sectors (automatically, by the drive) if problems), and do a "recycle" backup. If you value the backup history on the disk, then buy another disk, use Retrospect to do a "Transfer" from the old disk to a new backup set on the new disk. You seem like a long-time user of Retrospect, you should be able to figure out the details.

 

Russ

[baweeks]

To srhwalker and twickland:

I thank you for taking the time to thoughtfully respond. I tried to write the problem clearly, but (clearly), I failed.

To try to clarify, these errors came up in the 'compare' phase of the backup. It is a file backup to a USB external hard disk. The first backup was a year or so ago; this was just an incremental backup of the files since the session before.

I might well be having terminology trouble with the word 'snapshot.' What I'm meaning by that word (and Retrospect might use a different word) is the x-thousand files that were backed up during that incremental backup session. It seems from the log file that they were backed up w/o complaint, but each file when being compared, rendered in the log file the -206 error when they were in the compare phase.

So I'm worried that that session of x-thousand files in that one incremental backup session might be written to the destination file, but in a corrupt manner, as the power cord was loose on the hard drive during both the backup and compare phases. Also, worry is that the catalog might be bad, too (?)

How to ensure that that session's x-thousand files were backed up in a non-corrupt manner is the main question. Possibly bad catalog, too. How to check the integrity of the files backed up in that session.

Having dual rotating backups is the best solution. Thankfully, I have that setup.

Will read your posts more carefully later today or tomorrow to study your suggestions on how to see if that session's files can be checked to be sure if they are OK. While some of that session's log files and sync files may be gone now (it's only yesterday), all the important-to-save 'document' files are still in the same spot, untouched, since yesterday.

Again, thank you for your time. Will study your postings.

Am planning to upgrade to 8 shortly.

baweeks

 

[rhwalker]

To try to clarify, these errors came up in the 'compare' phase of the backup. It is a file backup to a USB external hard disk. The first backup was a year or so ago; this was just an incremental backup of the files since the session before.

Ok. Unknown whether your disk drive has a read-after-write head, so it's unknown whether the writes were OK during the write phase. But verification of the media using Disk Utility ought to answer that question. It's really unusual (i.e., bad) when a disk drive reports such an error to Retrospect. Retrospect believes the files are in the backup set because the write phase was successful. Try a verification of the backup set using Retrospect. That will answer your question as to whether the data is good.

 

I might well be having terminology trouble with the word 'snapshot.' What I'm meaning by that word (and Retrospect might use a different word) is the x-thousand files that were backed up during that incremental backup session.

Yea, Retrospect uses the word "snapshot" to mean something different. Your usage is more of the "session" files, and you can use Retrospect to list / browse the files backed up in each session (Reports).

 

It seems from the log file that they were backed up w/o complaint, but each file when being compared, rendered in the log file the -206 error when they were in the compare phase.

Ok, understood.

 

So I'm worried that that session of x-thousand files in that one incremental backup session might be written to the destination file, but in a corrupt manner, as the power cord was loose on the hard drive during both the backup and compare phases. Also, worry is that the catalog might be bad, too (?)

The error being reported is a disk error, not a corruption error. There is nothing to indicate that the catalog is bad, simply that the backup set gave errors during the reading of the compare phase. It's possible that the drive simply went offline during the compare, causing errors, and you corrected all of that when you futzed with the power cord.

 

I think that your catalog is OK. Use the suggestions above (Disk Utility, Retrospect verification) to examine the disk and the backup set.

 

You should also find some errors in your console log (Mac OS X, not Retrospect).

 

Try some test restores of those files and Disk Utility verification. If they go OK, then I believe that your data is in the backup set.

 

Russ

[baweeks]

Dear Russ:

-I've been slow to respond to your suggestion (months). Beyond busy and not able to make the time. I just put aside the 6.1 backup set that is in question here, and have just began to use weekly the other hard drive in that was in my alternating A-B hard disk set (I had been rotating two hard drives A and B every week and sneakernetting them between home and work for safety against theft, fire, etc.).

-But recently came across some time to play with the hard disk with this error. Tried to mount the disk in the Finder. No go. Able to see the disk in Disk Utiity. DU said there were errors on the disk but could not fix them. Disk Warrior found some error code that was causing DW to slow, I wrote DW and their support said that this was an imminently failing disk not enclosure, and to back up the data ASAP Now. Little did the DW support tech know that the disk WAS one of my backups (lucky I have two dual rotating disks). The DW tech said just simply toss the drive into the trash, it's toast. Nothing but encrypted 6.1 data on it.

-While I'm foot-dragging on upgrading to Snow Leopard for other reasons, I've decided to get ready for Snow Leopard and put my eggs in the Retro 8.1 basket. (It is faster; the more I use the UI the more natural it becomes, even though there is no manual) --So I'll drop this thread. Thanks for your help.

-baweeks

[rhwalker]

Well, there is one more approach that might save the data. Pull the drive from the enclosure, attach it directly to a Windows machine, run SpinRite, which can often recover the data through its heroics, and which operates at a much lower level than does Disk Warrior. It's a Windows program that talks intimately to the drive's native interface. Here is the link:

SpinRite

 

But that's pretty much your only hope with a drive like this.

 

Russ