Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by jhg

  1. It appears from my experimentation that Retrospect does not follow junction points and backup the files from the junction's target. Is there a way to control this behavior (i.e. a "follow links" option)?
  2. You were, and somehow I missed your original post. Thanks! This looks like a trivial bug that should be fixed -- at least I hope so.
  3. After a couple of posts in the bug report, here is a workaround, and my assessment (as a 40-year career developer) of where the bug is. Retrospect support suggested that I could try to open the moved catalog file by double clicking on it (the catalog file) to launch Retrospect. Here is my latest response on the bug ticket:
  4. Understood; the support case is number 73057. I've been a user of Retrospect since one of the earliest versions on a Mac SE30 (backing up to 1.44MB floppies) and generally been satisfied, but I agree that bugs linger for ages before being addressed. But glacial bug resolution pace seems to be the norm -- see Apple, Microsoft, Quicken, etc.
  5. I have opened a support case. https://www.retrospect.com/en/support/case?case_id=5000P00000q2rrJQAQ
  6. OK, there is definitely something very broken in how Retrospect locates the catalog. I rearranged the drive letters to make the image backup disk E: again, and it has no trouble, just opens the backup set and does not prompt for the catalog location. This indicates to me that Retrospect is storing the catalog drive and path in its metadata. If it's not possible to read a catalog from a different location than what is saved in Retrospect's metadata, then it shouldn't be presented as an option. Clearly that is not what is intended, so Retrospect should be able to update its metadata to read the catalog from a different location.
  7. None of this makes any intuitive sense. I created a backup set on a hard disk, and placed the catalog (from the start) on the same disk. At the time, the backup set was in E:\Retrospect, and the catalog ("DRImage.rbc") was in e:\catalog. Now I'm trying to restore a file from that image. The disk is now H: after a reinstall of Windows 10. When trying to open the backup set it asks "Where is the Catalog File for DRImage". When I navigate to H:\catalog, no matter what I do it says it cannot find the file. This seems awfully broken to me. If I point it to the catalog, it should find the catalog. The catalog was updated just yesterday, the only thing that has changed is that the drive letter has changed.
  8. The Properties dialog for a backup set does not allow changes to the catalog file location:
  9. OK, so I moved the catalog file to the desired location, then ran the backup script. It asked me "Where is the Catalog File for " the backup set. When I navigated to the new location and selected the catalog file it says "File Not Found" If I select the parent directory of the catalog file instead it says "The name is not valid" I see other messages in the forum about this problem in the context of attempting a disaster recovery restore... this does not inspire confidence that DR will actually work. Why does it not accept the new location of the catalog file?
  10. Retrospect Given an existing backup set, is it possible to change the location where the catalog file is written? I have a Disaster Recovery backup for my C:\ drive that writes its catalog into a directory on D:\ and I'd like to change it to put the catalog on the same disk as the backup set itself. Can I alter the backup set? I don't see a way to do this from the "Properties" dialog.
  11. @DavidHertzberg no, I never alter the settings, this is from a standard archive script I run regularly. @x509 no, I don't run the archive while Lightroom is running... although it's conceivable I accidentally left Lightroom in the background during an archive run. Since the file on disk compares correctly with the restored copy, and chkdsk /r on the drive turns up no errors, I'm not going to worry about this one.
  12. The disk is USB3 and normally has worked flawlessly. I ran the verify again on one of the archives and it flagged the same file again. Is there a way to make Retrospect archive that one file again?
  13. I have a large (2.5TB) library of images on disk, for which I keep two separate Retrospect disk archives. Occasionally (once or twice per year) run a Retrospect media verify on both archive drives. This time around I got a single verify error on each drive, flagging a different file on each drive. Here's one of them Here's the same file in Windows Explorer And in the Backup Set The only difference is that Retrospect seems to think that the file in the backup set is newer than the one on disk. I restored that single file to a temporary location and compared it to the original (still on disk at its original location) with WinMerge and the Windows "comp" command. Both WinMerge and "comp" report that the files are identical. Then I ran "chkdsk /r" on both drives, neither of which flagged any bad sectors or other filesystem errors. So I have 2 questions: What exactly does the error message mean? When was the "Generated MD5 digest" calculated (at backup time or during the verify)? Where is the "stored MD5 digest" actually stored? Since the original and restored copy of the file compare equal, I assume this is a problem in the backup set and/or catalog. How do I get Retrospect to "fix" this error and get itself back in sync?
  14. I configured a daily email report to be sent at 7:00 AM, as shown in the attached screenshot. However, it appears that the email is sent only if the full Retrospect application is open at the requested time. I would have expected that the email would be generated by a small background process, such as retrorun.exe instead of the full app. If this it is intended that the email status requires the full app to be running, then I would like to submit a feature request that the task of sending the status email be moved to retrorun so that the main app does not have to be running.
  15. jhg

    Forum login uses HTTP, not HTTPS?

    On signing in, even though I used an HTTPS url for forums.retrospect.com, I get a security warning from Firefox saying the login will occur over HTTP, and the forum site indeed uses HTTP.


  16. If I start Job A which uses BackupSet-1 and then attempt to start Job B, which also writes to BackupSet-1, Retrospect complains that the backup set is in use and refuses to queue the job to wait for the backup set to become available. However, if I edit Job B and add a one-time schedule entry to start 1 minute from now, while Job A is still running, Retrospect dutifully queues Job B and runs it when Job A finishes. This is probably a feature request. In the first situation, where I attempt to run a job for which a resource is currently in use, I would like for Retrospect to queue the job just the way it does when the job is started by the scheduler instead of manually.
  17. What I want to do is run 3 backup scripts one after the other. Can a script execute other scripts?
  18. If I try to manually initiate a job while another job is running to the same backup set, Retrospect rejects the attempt. I would expect that it would just add the job to the "Waiting" queue instead. Is there a way to explicitly add a job to the "Waiting" queue?
  19. Windows 10 Pro x64 build 1803 with all current updates applied, Retrospect Every time Retrospect starts based on a schedule task it produces the following Windows Event Log entries: 1/3/2019 2:00:04 AM Retrospect version - Automatically launched at 1/3/2019 2:00 AM 1/3/2019 2:00:16 AM Execution terminated unexpectedly, possibly due to a power failure or system crash. 1/3/2019 2:07:06 AM Script "JHG" completed successfully 1/3/2019 2:07:06 AM Normal backup using JHG at 1/3/2019 2:00 AM (Execution unit 1) 1/3/2019 2:00:16 AM: Finished scanning backup set data files To Backup Set HD Set 012... ... [uninteresting message content deleted] 1/3/2019 2:01:08 AM: Comparing Backups on STORAGE (D:) 1/3/2019 2:01:27 AM: Execution completed successfully I believe that Retrospect logs the error (2nd message) because it believes a previous invocation of the script failed, which did happen over a week ago. I think Retrospect is failing to clear some indicator of a previous failure when a backup is successful.
  20. I have some fairly complex selectors, and editing these via the UI is somewhat cumbersome. Is there a way to export the selectors in a text format that can be edited and rearranged in a simple text editor, and then reimported? I tried the "export" function, which produces a .rxx (Retrospect Exported Selectors) file. The format is binary and doesn't start with a known file type signature.
  21. Retrospect on Windows 7x64 Pro When displaying a backed up file's properties I noticed that the Created/Modified/Accessed times are all UTC but the BackedUp time is local, with no indication that different timezones are being used. The file is on a local disk, no NAS or other systems involved. See attached screenshot.
  22. That would just add a second volume, which I want to avoid.
  23. I have an archive backupset on an HD, and the HD has filled up. The HD contains only the Retrospect backupset and nothing else. I'd rather not add a second disk so I copied the contents of the full disk to a new, larger disk and then set the volume name and volume serial number on the new disk to match the old one. However, Retrospect does not recognize the hard disk as belonging to that backup set. What else do I need to change on the new drive so Retrospect will recognize it?
  24. I'm not sure I understand why this would slow things down. As it currently operates, Retrospect has to scan the source directory and build a in-memory representation of the state of each file. That model is then matched to the catalog to see which files have changed and need to be backed up. All the verify has to do is set a flag on the file in the catalog so that next time a backup is run that file is considered "changed".
  • Create New...