Search the Community
Showing results for tags 'corrupt'.
Found 2 results
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!
midavis posted a topic in Retrospect 9 or higher for MacintoshMy most recent disk member of set "A" used for archiving finished projects has failed. I would like to reformat it and replace all the files from another archive set "B". Would the best way to handle this be to mark the corrupt member as missing, then use the Copy Media Set Script using set "B" as source and the reformatted disk (name same as old member) as destination? Note: The bad disk only contained about 30-40 projects (57GB), each in its own named folder, so if I had a way of knowing what projects were on that disk, I could instead restore these folders from disk "B" and just archive them again. Any input would be much appreciated.