Jump to content
x509

Massive number of "bad backup set header" messages

Recommended Posts

I just tried to retrieve some files from my 2019 Media Library dataset and got all these error messages in the logfile.  The logfile was 1375 lines total, and the activity monitor shows 1358 errors, no warnings.

 

image.thumb.png.9173b4a190516f32a263d3766c36f761.png

I'm running Retrospect Pro 16.1.1.102 on Win 10 Pro 64.  My backup drive is internal SATA 6G.

What could have caused all these messages.  Just the other day, I ran the built-in Windows "defrag" command, and it ran normally. 

  • Could this operation have screwed up the dataset? 
  • How can I test my other datasets? 
  • Can this dataset be repaired, or do I need to create a new 2019 Media Library backup dataset?

Fortunately, I can retrieve the files I need from my 2018 backup volume, but these messages have really scared me.

Edited by x509
typos and additional information

Share this post


Link to post
Share on other sites
24 minutes ago, x509 said:

Could this operation have screwed up the dataset? 

Yes, it could but not likely by itself. It looks like you have a hard disk problem, since some files can't be read properly. Test the hard drive, including a surface scan.

29 minutes ago, x509 said:

How can I test my other datasets? 

Page 459, "Verifying Backup Set Media"

http://download.retrospect.com/docs/win/v16/user_guide/Retrospect_Win_User_Guide-EN.pdf

30 minutes ago, x509 said:

Can this dataset be repaired, or do I need to create a new 2019 Media Library backup dataset?

Maybe you can.

Page 454 in the above user guide: "Recreating a Catalog"

Share this post


Link to post
Share on other sites

Lennart,

Thanks.  I'm running a disk surface test right now.  My backup drive is 6 TB, and the test will need another 8+ hours to complete.  I'm going to let the computer run overnight.

Share this post


Link to post
Share on other sites

Update.  Surface test showed drive had zero surface defects.

The Verify Media operation on my 2019 Media Library dataset just completed, after almost 3 hours.  There were many errors.  Here is a sample:

image.png.552b5cb46453ddc8d2ab35031d6ca904.png

Next step is to recreate the dataset from files, and then verify again.  I also want to verify six other datasets, which I have started and then paused.  Those operations will take another five hours in total.  However, in about 15 minutes, we are leaving for a vacation, so I have to hibernate this system.  I'll complete all this week after we get back,and I'll post an update.

Again, appreciation to Lennart.

 

Share this post


Link to post
Share on other sites
On 8/13/2019 at 8:21 PM, x509 said:

Update.  Surface test showed drive had zero surface defects.

Surface test only checks "usable" disk space -- it doesn't include bad sectors that have already been mapped out. So it's probable that the "missing" files were on a bad sector that has already been "fixed" by Windows. Possibly, given the numbers involved, a problem in whatever is NTFS's equivalent of the file allocation table. You can check by viewing the SMART data for the drive, which will tell you how many sectors have already been re-allocated.

Share this post


Link to post
Share on other sites

The S.M.A.R.T. tab itself might give more information -- what's there depends on the software, but there should be a note of the number of unallocated blocks, how many have been mapped out, etc. See the wiki page for the amount of info potentially available.

Your disk is in perfect health -- what we can't see from that screenie is if it is in perfect health because nothing has ever gone wrong, or is it in perfect health *now* because previously found "problematic or weak sectors" have been mapped out.

Also, that's a very new disk. Only 13 days of being used, primarily (if not wholly) a backup disk, and you felt the need to defrag? That seems odd in itself.

Not that any of this really matters to the original problem, I just like to scratch an itch when I find it...

Share this post


Link to post
Share on other sites
10 hours ago, Nigel Smith said:

The S.M.A.R.T. tab itself might give more information -- what's there depends on the software, but there should be a note of the number of unallocated blocks, how many have been mapped out, etc. See the wiki page for the amount of info potentially available.

Your disk is in perfect health -- what we can't see from that screenie is if it is in perfect health because nothing has ever gone wrong, or is it in perfect health *now* because previously found "problematic or weak sectors" have been mapped out.

Also, that's a very new disk. Only 13 days of being used, primarily (if not wholly) a backup disk, and you felt the need to defrag? That seems odd in itself.

Not that any of this really matters to the original problem, I just like to scratch an itch when I find it...

Actually, this drive IS used only for backup, perhaps one hour a day.  I use a new drive each year for backups, and I started using this drive on January 1.  I was away for several weeks earlier this year, so backups weren't being done.

Share this post


Link to post
Share on other sites
On 8/13/2019 at 12:21 PM, x509 said:

Update.  Surface test showed drive had zero surface defects.

The Verify Media operation on my 2019 Media Library dataset just completed, after almost 3 hours.  There were many errors.  Here is a sample:

image.png.552b5cb46453ddc8d2ab35031d6ca904.png

Next step is to recreate the dataset from files, and then verify again.  I also want to verify six other datasets, which I have started and then paused.  Those operations will take another five hours in total.  However, in about 15 minutes, we are leaving for a vacation, so I have to hibernate this system.  I'll complete all this week after we get back,and I'll post an update.

Again, appreciation to Lennart.

 

Big update.  I recreated the catalog from files.  That backup set verified almost 100% clean.  Just a few isolated checksum errors on photo files that I've known about for along time.  So then I did a test restore, and I got all the same kind of errors that I got on the earlier Verify Media operation. 

All the 1352 errors were Bad Backup Set header.

image.png.0b73a6bfc109e347ca348151cb5175e3.png

So what does it mean that Verify Media didn't detect these errors?  Is this a bug?  Should I be filing a bug report?

Meanwhile, I have started an entire new MEDIA dataset backup, in progress right now as I write this post.  The files are over 1.2 TB, and the copy operation will take a bit over 5 hours.

x509

 

Share this post


Link to post
Share on other sites
5 minutes ago, x509 said:

Should I be filing a bug report?

I say "YES". A proper "verify media" should detect such errors.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×