x509 Posted August 13, 2019 Report Share Posted August 13, 2019 (edited) 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. 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 August 13, 2019 by x509 typos and additional information Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted August 13, 2019 Report Share Posted August 13, 2019 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" Quote Link to comment Share on other sites More sharing options...
x509 Posted August 13, 2019 Author Report Share Posted August 13, 2019 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. Quote Link to comment Share on other sites More sharing options...
x509 Posted August 13, 2019 Author Report Share Posted August 13, 2019 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: 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. Quote Link to comment Share on other sites More sharing options...
Nigel Smith Posted August 15, 2019 Report Share Posted August 15, 2019 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. Quote Link to comment Share on other sites More sharing options...
x509 Posted August 16, 2019 Author Report Share Posted August 16, 2019 I am out of town for a week so I will check Smart status when I return x509 Quote Link to comment Share on other sites More sharing options...
x509 Posted August 22, 2019 Author Report Share Posted August 22, 2019 I'm home again, so I just had a chance to check SMART status on my backup drive. Clean. Quote Link to comment Share on other sites More sharing options...
Nigel Smith Posted August 23, 2019 Report Share Posted August 23, 2019 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... Quote Link to comment Share on other sites More sharing options...
x509 Posted August 23, 2019 Author Report Share Posted August 23, 2019 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. Quote Link to comment Share on other sites More sharing options...
x509 Posted August 23, 2019 Author Report Share Posted August 23, 2019 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: 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. 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 Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted August 23, 2019 Report Share Posted August 23, 2019 5 minutes ago, x509 said: Should I be filing a bug report? I say "YES". A proper "verify media" should detect such errors. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.