Jump to content

x509

Members
  • Content count

    160
  • Joined

  • Last visited

  • Days Won

    8

x509 last won the day on July 3

x509 had the most liked content!

Community Reputation

21 Excellent

About x509

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'm home again, so I just had a chance to check SMART status on my backup drive. Clean.
  2. Mr. Pete, Until I read your guide, I thought I now know everything to do a Windows partition recovery. Now I realize that crucial pieces exist only in my mind, and that approach doesn't scale well with multiple systems or across time. I've printed out a copy (PDF)of your post, which I'm saving in the same folder as my Retrospect user guide. I'm sure that your post is still valuable, even though I am now on R 16. x509
  3. I am out of town for a week so I will check Smart status when I return x509
  4. 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.
  5. So following Lennart's suggestion in message #2 of this thread Massive number of "bad backup set header" messages I started to verify all the datasets on my 2019 backup volume. Retrospect could not find any of them. 😱 But that was because I was trying to verify 2019 datasets on my 2018 backup volume. Here is what happened. I always use Drive G for the Retrospect backup volume. If I need to retrieve files from a different year, I install that drive into my system (via docking station), and then use Minitool Partition Wizard to change Drive G to that other year's backup volume. Works very well, but this time I forgot to switch Drive G back to my 2019 backup volume before doing the dataset verification. Ooops. 😅 x509
  6. 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.
  7. 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.
  8. Earlier this year, I tried to restore my "production" system, following the directions in the V15 manual. That system is Windows 10 Pro 64. The V15 manual states on p. 99 (my highlights) So I blithely assumed that I could do a Restore of my C : partition, after it somehow got hosed. Wrong!! I ended up reformatting that partition, doing a fresh install of Windows, and then re-installing all the programs and doing all the config settings. So I was pretty frustrated about the experience. When I wrote a letter a few months ago to Retrospect management about a bunch of issues, I included this issue. I got a detailed response to all my issues from Robin Mayoff, which I do appreciate. However, it was very frustrating to read the following. When you perform a restore of a Windows operating system with Retrospect, it is very important to perform this restore while booted from a Retrospect Disaster Recovery disk. It is not possible to restore a modern version of the Windows registry or Windows system while booted from the C disk. This is probably why you got some errors and ended up needing to reinstall programs. Had I known this point, I could have saved myself several days of work. Why am I posting this now, months after the fact? I can't fully explain why, but "stuff" happened. Still I thought this point is important enough so that the next person with this problem might find this post and save themselves a lot of trouble. As the expression goes, I am "paying it forward" in appreciation for all the help I get in this forum.
  9. Replying months later to Lennart_T's post, I finally (never mind why!) got around to doing a grooming operation. It was a success. Here is the selector I used in the groom job: Note that the S-1 ... folder never should have been backed up. The System Volume folder was explicit.y excluded in my universal "Always Exclude" selector. Just in case the System Volume exclusion didn't work, I also excluded files matching pattern 32{* and *{380* that are either 12 GB or 50 GB in size. Before the groom operation I did a Find Files operation on the Media dataset, to identify files and folder to groom out. AFter the groom operation, I did another Find Files operation to confirm that all those files were in fact groomed out, except for an S-1* folder inside the $RecycleBin, which should never have been backed up. (But I'll clean that up.) The groom operation recovered 345 GB and 15479 files. After I get some more experience with this grooming selector, I will incorporate it into the backup script. x509
  10. I just changed the various Windows date values for a range of photo files, to correct for the camera clock being set for the wrong time zone. Retrospect did not back up the actual files again, since the contents (photo RAW files) were not changed. But did Retrospect back up the new Windows file date values? x509
  11. That's what I had to do. x509
  12. Nigel, Thank you for doing all these tests. I got dragged into this morass only when scripts that apparently had been working, stopped working. So I was in "break-fix" mode, or just trying to solve the problems of broken scripts, so I could move things along. I appreciate all your testing here. I'm going to download this thread so I can save it in my folder of "informal" Retrospect documentation. x509
  13. Nigel, Why you say that drive letter will be mandatory? So far it isn't. I'm running Retrospect 15.61. Now that I think about it, the way Windows networking works, Windows Explorer doesn't actually know about drive letters on networked systems. Or, maybe I should say, drive letters on networked systems aren't exposed in Explorer. I sure hope that Retrospect isn't going to screw all this up in a future release. What I do compulsively, you might say, is that I have a uniform usage of drive letters, as I explained in an earlier post, plus the use of Storage Groups. In my DATA storage group, I have the D drives from all systems. About your comment about total lack of consistency in Windows itself, I agree. Compared to the dark old days of DOS, Windows has enforced a lot of uniformity in the interface, even though there are many annoying inconsistencies. There is no question that Apple does a better job in the interface area. However, for my iPhone/iPad, Apple makes these strange changes from one iOS release to the next, and I'm forced to do Google searches. x509
  14. Nigel, Thanks for this reply. I can only comment that it's not exactly great software design to vary from standard Windows practice in specifying a path. There are several different SAVE AS dialogs in Windows, I'm not sure why, but the key point is that none of them require a trailing backslash. In my scripts, I have not found it necessary to include a drive letter, but maybe that's because I use Source Groups in Volumes. I have four systems, and another being added next week, and it would greatly complicate matters if I had to specify fully qualified paths in the scripts, e.g. \\APOLLO\DATA or \\DELOS\DEL-DATA or \\APHRODITE\APH-DATA. (APOLLO is the Retrospect host system.) All my systems are organized the same way: C - Windows and Programs, related settings. NO user data. D - User data, other than music, photos, videos. E - Music, photos, videos F - software downloads (only two systems) x509
  15. I made some mistakes in setting up a grooming job, and Retrospect can't find the dataset member in question (my fault, apparently), so I tried to cancel the job from the window below, but the job isn't cancelled. Even if I shut down and restart Retrospect, the job remains active. I seem to be unable to locate the missing member, even when I click through to the location of that member. Is there anything I can do to make Retrospect forget about this job. Is there a file that I can delete, that Retrospect will then regenerate? EDIT: I sort of killed the job by clicking on the Choices option to indicate a missing member. That solved the immediate issue, but I will have to try again, when I have time, to see if I can still groom this dataset. x509
×