"bad backup set header found"

[Ash7]

I wanted to take several older external USB hard drives, some of them containing non-Retrospect data folders, others containing Retrospect Backup Sets, and transfer all of them into a single backup set I named "Consolidation." I did this by using both Immediate backups to capture (backup) non-Retrospect data folders into the Consolidation set, and using Transfer Backup Set scripts to transfer any Retrospect backup sets on an older external USB drive to the newer Consolidation Backup Set.  

 

The process worked well and ended up spanning two new external 4TB drives (the 2nd drive is barely full yet so there's room for further growth/consolidation). I'd say it's about 5 or 6TB of data spanning two 4TB external USB drives. 

 

Then I wanted to create a duplicate or "backup" of that single Consolidation set... just in case the first one ever had issues, I would have at least two copies. To do this, I am using a Transfer Backup Set script to transfer from the original Consolidation backup set to a secondary newly created "Consolidation2" backup set (the number '2' appended to the name, a different backup set but ultimately a duplicate of Consolidation). 

 

During the Transfer from Consolidation to Consolidation2, I hit the dreaded "bad backup set header found" message... so far the Activity monitor shows about a 18000 count.

 

My system: MSI GT72S 6QD (a web search yields its specs and support page)... at first I had been using a powered USB hub without issue for most of my backups and stuff. Not sure if that's related, but based on a Retrospect KB article (https://www.retrospect.com/en/support/kb/troubleshooting_bad_backup_set_header_and_other_similar_errors) I decided to plug directly into my laptop's USB 3.0 ports, but I still see those errors. I also see them on another laptop as well.

 

Some questions...

 

1) I think my experience above indicates with relative certainty that the original Consolidation set has some corrupted files/backup data... correct?

 

Okay, so to assess the damage and move forward, I'm trying to gain insight into the following...

 

I'm currently letting the Transfer from Consolidation to Consolidation2 continue despite the 18000 errors because it seems to be continuing and transferring (copying) files. But I'm left with some important questions...

 

2) I see this error message "bad backup set header found", but Retrospect is showing me no feedback as to what files are affected. It's unclear what snapshots or backups were affected. This might help me understand the impact and how much effort I should take to resolve it... the corrupted files may not be that critical to me but I can't tell... Retrospect is only emitting the lower level error message. Is there a way to get Retrospect to give me a user-friendly set of information about what files were affected? ... and perhaps what snapshots, Sessions, etc. from the original Consolidation are not reliable or missing after the transfer to Consolidation2? Or, is there a way to diff Consolidation and Consoldation2's catalogs to see what made it successfully to Consolidation2? That information seems imperative to assess damage.

 

3) Given I see about 18000 "bad backup set header found" errors, but the Transfer operation is continuing, apparently continuing to copy good/accessible files, what will the new Consolidation2 Backup Set look like when complete? Will it contain only good data that could be retrieved? Will it include garbage data based on a best effort to copy from the partly corrupted source set? etc. While this question seems similar to #2 above, I'm asking something different here... I'm trying find out what data from the corrupted files in the source set, if any, make to the destination. I'm guessing none of the corrupted data makes it, that it is ignored, but I want to find out for certain.

 

4) What about backup sets in the partly corrupted source set... will the "good" not corrupted parts be copied, while ignoring the corrupted parts? Does this mean the snapshot is transferred to the new Consolidation2 without the corrupted files? Or are the corrupted file names still moved to the destination even if the destination data archive is missing or contains bogus data? I can't imagine Retrospect copying over garbage data... but I don't want to involve my personal assumptions here... want to get the facts. 

 

Basically, Retrospect is encountering errors during a transfer due to corruption in the source set but it's unclear how Retrospect is going to deal with those errors from a very specific concrete level... meaning what will the result of its work, the new destination Consolidation2 set, look like (assuming the destination drive is good and there is no new corruption)? 

 

Based on the answer to the above, my plan is to continue to let the transfer complete, and once completed, I want to go back over all the older external USB drives which were used to create the original Consoldation set, and re-back them up to Consolidation2. After all that, I'll erase Consolidation and recreate it using a Transfer from Consolidation2 (the new one and only "good" one) to a newer recreated Consolidation. My goal here is to salvage what was good about the first round of backups to create Consolidation in hopes that going back over all the older USB external drives will go quickly given files will already be in the Consolidation2 set. Keep in mind these Consolidation and Consolidation2 sets are essential archival in nature... I don't really need the structure as much as the file history... though I want to retain the snapshot data as best as possible. So far Retrospect seems to transfer that data just fine. 

 

Does the approach in the prior paragraph sound reasonable? 

 

My Transfer operation is vanilla except I checked "Transfer any needed intermediate database Snapshots." 

 

Thanks for any insight! 

[JohnW]

I thought you posted an excellent question and I have been waiting for someone to chime in. I don't know what problems Retrospect is having that they cannot pay any attention to their forums, but it is bad business to ignore their user base. 

[DavidHertzberg]

On 12/15/2017 at 11:05 AM, JohnW said:

I thought you posted an excellent question and I have been waiting for someone to chime in. I don't know what problems Retrospect is having that they cannot pay any attention to their forums, but it is bad business to ignore their user base. 

Perhaps the reason nobody chimed in is that Ash7 never said what version of Retrospect he/she was using.  In fact AFAICT he/she has not said that in any of his/her 11 posts on these Forums.  That is especially relevant because of "Fixed 'Bad Backup Set Header' errors during certain restores and transfers (#5662)", which is in the Release Notes for Retrospect Windows 11.0.0.252—released 1 March 2016.  I've used the Search capability of these Forums to find posts mentioning that "bad backup set header found" error message, and there are no other such posts later than 2015.

The likelihood that Ash7 was using an older version of Retrospect highlights a question: What is "their user base" that "it is bad business to ignore"?  The fact is that a lot of posters on these Forums are using an older version of Retrospect.  IMHO those posters are frequently either consultants or new administrators at their installations, and have been told "Get Retrospect working again to do ..., but don't ask us to spend the substantial amount of money a new version would cost."  It's a tribute to the old versions of Retrospect that they frequently still work well, but (to adapt an old Jewish joke) "Retrospect Inc. isn't in business for its health"—and users of old versions don't bring Retrospect Inc. any upgrade or ASM money.

I will also take this opportunity to caution JohnW and others about making remarks about Retrospect Inc. business matters on these forums.  My experience over the last 1.5 years is that the head of Retrospect Tech Support regards such remarks as violating the purposes of the Forums, and has told me "Please try to keep your forum posts on topic to solving Retrospect issues for other users."  Also, if you read earlier posts in that thread, you will find that the HRTS takes umbrage at fairly mild satiric gibes.

P.S.: To amplify the second paragraph in this post. when the HRTS did give advice in these Forums his post usually included a pitch for upgrading along with the advice.  I guess those pitches weren't proving too productive, but probably as important is that he doesn't have the time to post anymore.  The HRTS used to have an assistant named Alan who answered phone-call requests for assistance, but Alan is gone and there has been no replacement—so in my recent brief experience the HRTS answers the T.S. phones himself.  Given the third paragraph in this post, you'll have to figure out for yourselves why that is.

Edited December 22, 2017 by DavidHertzberg
Added P.S. amplifying the second paragraph; edited repeated "so" out of P.S.