Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Maser

  1. Are they previous volumes (ie, something reformated, but then given the same names?) I only see volumes in my "No Backups in 7 Days" for external drives connected to clients that I'm not backing up anything on, so maybe they were scanned at one point, but aren't there any more? Or were attached to a different client?
  2. If you use the uninstallers, that will remove the engine, etc. If you just have the older versions of the "Retrospect.app" on your system, you can just trash the app. I honestly don't remember about uninstalling the really old Retrospect any more, though...
  3. They are disposable if you want to do a *full* catalog rebuild (sorry -- been away from the board for a while while work got in the way).
  4. In order to do a full catalog rebuild (which I've done many times) -- make sure you remove all the .session files before you do the rebuild. It's also possible that after the groom, one of your .rdb files is hosed (I had that happen and had to go through a whole bunch of iterations to figure out which one was messed up -- and it ended up being some 11K .rdb file causing my rebuilds to fail...)
  5. FWIW -- I don't see this with 13.5. The console "syncs" my 5 active media sets, but the modify time stamp on the catalogs do not change until a script actually uses the media set.
  6. I run Proactive Backup scripts for 100% of my clients. Most of them are laptops so there is no possible way of knowing when they'll be on line. In general, though, you can try to schedule upcoming backups (in the Activities section of the Console) if you want to *try* to get them to back up at an approximate time. i've had zero downside to running Proactive backups and have been doing it that way ever since Retrospect introduced the concept.
  7. Free update to 13.0. New clients for Mac and Windows too...
  8. No -- it's not new with version 13. I've been doing this for years now.
  9. Yeah, I never manually groomed immediately after removing past backups. I have monthly groom scripts that run, so if I have a need to manually groom out a specific backup, then I just remove the backup and wait for the script to take care of the grooming. *Sometimes* (but usually not), there is an error in grooming that requires a catalog rebuild after the groom. That's fairly rare, though.
  10. Unlock your media set -- if it's locked. Then go to "Past Backups" in the console. You'll see all the backups for your media set (well, I guess it depends on your groom settings). You can select a past backup and click "Remove". Then when you groom the media set, it will groom out that specific backup. My media sets are configured to keep X backups (rather than the "Defined Policy"), so YMMV on what you see in "Past Backups", I guess...
  11. You can manually delete specific "Past Backups" and then run another Groom to get rid of them. I do this all the time. It would be faster (probably) than copying to a new Media Set, but YMMV depending on how much data you are talking about.
  12. I've reported this as well. I'm not sure if it's a glitch in the grooming log code or not. I still have one old set that is set for storage, but when I groom it is says optimizing for performance. I have not rebuilt that catalog as I'm phasing it out for a newer media set anyway.
  13. There is a new 13.0.1 update out today that fixes a grooming issue I've seen here. Just FWIW.
  14. Yeah, I've been told that if the groom log says "completed successfully" then not to worry about the errors, too.
  15. The "reported missing" file -- is the .rdb file actually gone? If so, don't worry about that from the rebuild. As far as the MD5 errors go -- I have nothing. I wouldn't necessarily worry the files in /private/var/run, but you might try restoring the .dv file to make sure the backup copy works.
  16. It's possible those .rdb files are messed up. I have -- on rare occasion -- had to remove specific .rdb files from the media set to successfully rebuild a catalog after a groom. You didn't post the log from the rebuild of the catalog -- does the rebuild complain about the same .rdb files? - Steve
  17. Yeah, I've now just resigned myself to remembering to do two reboots after any OS update.
  18. Yeah -- I saw this with the 10.11.3 delta upgrade as well (I reported this to Robin...) In my case, the proactive backup scripts never ran *until* a scheduled groom script ran a few days after the upgrade -- then everything started working again.
  19. So, FWIW, I had a similar (but not quite) problem after updating from 10.11.2 to 10.11.3. Normally, I stop the engine in the Sys Pref, but leave it checked to start at system startup. I did this as usual prior to updating to 10.11.3. I thought Retrospect was fine -- but it wasn't until a couple of days later that I noticed that none of my proactive backup scripts were working? Things only started working when a scheduled *groom* script ran -- then as soon as that finished, all the proactive scripts started working again. I've reported this, but I don't know how easy it is to reproduce... Bottom line -- it probably makes sense to reboot twice after any 10.11 OS upgrade these days...
  20. I asked about this one once and they said it's a known issue, but not to worry about it.
  21. Yeah, this was there in Retrospect 6 (or whenever it was last there), but not since the redesign. I'm not holding my breath for a "preview" scan at this point like there used to be, unfortunately...
  22. http://www.retrospect.com/en/documentation/user_guide/mac/release_notes
  23. I did an upgrade using the full Beta 7 installer over 10.10.5 and all is working well here -- icon is still in the menu bar. But that was not a clean-install, though...
  24. Instant Scan only reduces the amount of time needed to identify the files that need backing up -- nothing about the throughput.
  25. http://www.retrospect.com/en/support/downloads Nice to see a pretty aggressive schedule for bug-fix releases for version 12 (so far!)
  • Create New...