Jump to content

Consistent, bogus verify problems


Recommended Posts

I have recently noticed that I am unable to use the post-backup verify tool. It seems that every backup set we create is copied to tape and passes the backup verify. If I then run the verify tool, it fails within the first 2 GB and gives up. However I have no problem subsequently performing a restore. It compares bit-for-bit with the original. The particulars:

 

Retrospect backup server 6.1.138, MDD G4 2x1.25 GHz, 2 GB RAM, VXA-320 via ATTO UL3D

 

I have an example that is typical of this problem. Note that the bad backup set headers are always at the same locations, regardless of the backup set or tape used:

 

! 2/20/2008 11:09 AM: Manual Recycle of backup set VXA3 Backup C

 

+ Executing Immediate Backup at 2/20/2008 11:09 AM

To backup set VXA3 Backup C…

 

- 2/20/2008 11:09:51 AM: Copying ServerWin (C:) on Server-Win…

2/20/2008 11:09:51 AM: Connected to Server-Win

2/20/2008 11:18:53 AM: Comparing ServerWin (C:) on Server-Win…

(a series of messages for dynamic files that have changed since the backup copied them; all hand-verified)

2/20/2008 11:26:08 AM: 50 execution errors.

Completed: 23952 files, 3.8 GB

Performance: 505.0 MB/minute (460.2 copy, 559.4 compare)

Duration: 00:16:17 (00:01:02 idle/loading/preparing)

 

+ Executing Verify at 2/20/2008 11:26 AM

To backup set VXA3 Backup C…

Bad backup set header found (0x4b4c1ff8 at 1,024,001).

Backup set format inconsistency (5 at 1024079)

Bad backup set header found (0xcccccc78 at 2,048,000).

Backup set format inconsistency (5 at 2048190)

Trouble positioning: “1-VXA3 Backup C” (16003), error 109 (unexpected filemark or FTP end of file).

4851 files were not verified.

2/20/2008 11:31:25 AM: Execution incomplete.

Remaining: 4851 files, 868.1 MB

Completed: 19101 files, 3.0 GB

Performance: 669.1 MB/minute

Duration: 00:04:49 (00:00:20 idle/loading/preparing)

 

+ Executing Restore from Backup at 2/20/2008 11:33 AM

To volume Tiger…

 

- 2/20/2008 11:33:41 AM: Restoring from VXA3 Backup C…

2/20/2008 11:39:30 AM: Execution completed successfully.

Completed: 23952 files, 3.8 GB

Performance: 704.4 MB/minute

Duration: 00:05:49 (00:00:21 idle/loading/preparing)

Link to comment
Share on other sites

The Bad Backup Set Header error, Format Inconsistency errors and error 109 are all indications that the verify is failing in some way. It could be a failure in how the drive is reading back data.

 

A tools>verify on the macintosh does NOT do a byte for byte verify. It just checks the file headers to make sure they are readable. It does not compare the file against the original.

 

Does the verify report identical file positions each time 0xcccccc78 at 2,048,000 or (5 at 2048190)?

 

Random errors would be communication issues with the hardware. Identical errors would be bad spots on the media.

Link to comment
Share on other sites

I understand. By the attached log I:

 

1. Recycled a backup set

2. Backed-up a single client with verify (this is byte-for-byte, right?)

3. Ran the verify tool (header check only)

4. Restored the backup to the server's drive

 

As you can seee, the backup/verify in step #2 worked fine. The verify tool in step #3 detected bad headers. The restore in #4 worked fine. I have done this with six different brand new tapes on a cleaned drive. I also tested all dozen of our backup sets. The errors are ALWAYS exactly in the same place, regardless of the backup set, tape or the client I am backing up. I think it's rather interesting the header errors are ALWAYS on nice round number boundaries: 1,024,000 and 2,048,000. Every time. But the verify run during the backup and the restore always work perfectly. I think I can pretty much rule out the hardware: I did a 1.4 TB backup to a dozen X23 tapes with the built-in verify. That backup and comparison was perfect. But when I ran the verify tool, I got header errors at the same two places. I restored the files off the first two tapes and did a bit-for-bit diff on the filesystem. Perfect. Why does only the verify tool fail?

Link to comment
Share on other sites

Yes, I'm sure the backups are fine. Restores always work perfectly in spite of verify tool errors. I have tested both RDU 6.1.11.101 and 6.1.13.101 on 6.1.138 with the VXA-320. They get the same verify tool errors. While I was trying to figure this out I pulled out an old VXA-2 drive last week. It seemed to have the same kind of problems with the verify tool.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...