Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


kswisher last won the day on April 15 2014

kswisher had the most liked content!

Recent Profile Visitors

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

kswisher's Achievements


Newbie (1/14)

  • One Month Later Rare
  • One Year In Rare
  • Week One Done Rare

Recent Badges



  1. I also encountered this copy backup bug v11.5.3.103. Reading the release notes for v12.x, are these the fixes? Fix for Copy Backup script's transfer mode not being saved in certain workflows (#5037). Copy Backup script's transfer mode now included in "Summary" tab
  2. Thanks for the response. It appears I have a corrupted media set that is causing issues. The corruption is not noticed during catalog rebuild or copy media set operations. The auto verification after copy does not detect the issue either. The only real clues are the the log which shows the data copied or processed during rebuild is much less than the size of the source media set. Running a verify media set on either the source or copy will show the Media Set format inconsistency error. In the process of troubleshooting, I also encountered the copy backup bug (http://forums.retrospect.com/index.php?/topic/151506-retrospect-1152-wont-properly-accept-source-options-in-copy-backup-scripts/), so this bug was not fixed in v11.5.3.103. Reading the release notes for v12.x, it is not clear if copy backup has been fixed in v12.
  3. It's been awhile since the last post on this bug in Version I am running Version 11.5.3 (103) and am seeing similar issues as described above for some of my disk media sets. So I was wondering if this problem was ever fixed in version 11? If not, was it resolved in v12?
  4. Interesting... I don't know the answer, but have a theory. In the past, I had problems with Retrospect 8 crashing every few days If I had Time Machine running on the host machine running the engine and backing up to a time capsule. Very repeatable crash for me, happening every 1-7 days if TIme Machine was enabled, but RS would go for weeks if TM was disabled. This does not seem to be an issue with RS 10. So I would guess the Retrospect folks may have hard coded an exclusion for certain TM related data or temp files. If this is the case, you might have somehow created a TM " Backups.backupdb" file on your boot disk. Turning off TM would not delete the file.
  5. Morrie, I don't see anything in the Retrospect log that even indicates that I started the grooming activity that dissapeared from the activities list. No other log entries until I stopped and re-started the engine. But I do have a number of system diagnostic reports shown in console from that time period. They have names like RetroEngine_2013-03-17-233052_MyName-iMac.cpu_resources.spin. One of them is time stamped a few minutes after I started the grooming process that hung. I have 21 of these reports generated in the last 30 days. The last four of these .ispin reports have been since upgrading to 10.1.0 (221) on March 21. On the positive side, 10.1.0 (221) may have fixed the bug that caused the hang in the first place.
  6. Replying to my own post... I still don't know if the selection rules work when doing a copy media set. WIll have to do some more testing. On my problem with grooming hanging.... I tried to groom the new copied media set, and it hung after a few hours, but did not list any file in the status window in the GUI when it hung. I did note that it had updated scores of .rdb files in the media set directory for the first 2 hours of the grooming process. After three days, I stopped the hung engine and deleted the catalog file. At this point, I upgraded to the just released 10.1.0 (221) version of the GUI and engine. Verified all my regular backups were still working. I then re-built the catalog file of the copied media set and tried to groom again. This time success! Whether I just needed to groom one more time or Retrospect fixed something in 10.1.0 (221), I'll never know. Just glad it has been resolved.
  7. I had a positive experience with grooming with Version 10.1.0 (221) and grooming. I have been fighting with a media set that keeps hanging retrospect when groomed (defined policy), After the latest of many attempts to groom/hang/stop engine/delete catalog/re-build catalog episode using 10.0, I upgraded to 10.1.0 (221), re-built the catalog then performed groom. For the first time in months, the groom completed succesfully.
  8. I to am seeing the threads preference re-set to 1 after a re-start of the server machine. Version 10.1.0 (221) desktop version, both the engine and GUI running on the same machine.
  9. I have had similar problems where a hung activity dissapears from the activity list after re-boot. I assumed it had something to do with deleting the catalog file after stopping the engine. Apparently not. (I delete the catalog as otherwise the hung grooming process would re-start and hang again when re-starting the engine.)
  10. I have a Disk Media Set that causes Retrospect 10 to get stuck when it attempts to groom the set (411.5 Gb, 1,314,824 files). The media set is the one dedicated for the local server machine backup. It always gets stuck on the same file (happens to be a Retrospect catalog file for another media set). Verification of the Media Set shows no problem and I have done numerous Catalog rebuilds cause I have to kill the server to get un-stuck. So this weekend I used "Copy Media Set" to a new media set, using a rule that selected all files except the RS catalog files. I tested this rule first on a regular backup, and confirmed it was indeed working to exclude the catalog files. Problem is, the catalog files still got copied over to the new media set. So my questions to the forum is: Do rules work when doing a "Copy Media Set"? Is there a way to expunge the problem file from the existing media set while saving all the past backup history? Or do I just archive the Media Set and start over with a new one?
  11. I also had a problem where Verify would run forever and never complete. Backups using the same disk media set, which have only one member, would still work. Retrospect 8 and 9 both had problem. The hang consists of an endless loop, with error like that shown below repeated over and over in the log file. + Executing Verify at 1/19/12 (Activity Thread 2) To Media Set RS8 iDad Backup... Additional error information for Disk Media Set member "1-RS8 iDad Backup", Can't read to file /Volumes/Backup2/Retrospect/RS8 iDad Backup/1-RS8 iDad Backup/AH001160.rdb, error -1101 ( file/directory not found) > !Trouble reading: "1-RS8 iDad Backup" (104090091), error -102 ( trouble communicating) In the Console window, it says "Verify summary window: File Resynchronizing (this may take a while)..." If I stop the verify, the console would show the media set was busy even after the verify stopped. Only solution I found to make the media set available again was to re-boot the computer. I verified the file it is looking for, /Volumes/Backup2/Retrospect/RS8 iDad Backup/1-RS8 iDad Backup/AH001160.rdb is indeed missing. Had same problem with Verify never completing, due to missing (different) .rdb files, on two other disk media sets as well. Tried re-building the catalog files on the three problem media sets. All three re-builds were successful. All three media sets now pass verification. IMHO, Retrospect 8 and 9 should handle this type of error more gracefully. -> Kent
  12. This may not be your problem but... I have had similar problems several times over the last few years with both RS 8 and 9 due to bad disk or disk controller. My latest instance was due to a bad disk controller card in the external HD case. Retrospect logs are useless to troubleshoot as there is no or unhelpful information. In the latest instance, I was able to confirm I had a bad disk controller in the external HD case by using SuperDuper to clone from one large disk to the suspect disk. SuperDuper copy would also fail after 10 to 40 minutes of copying. Replacing the disk in the case did not fix. But the nice thing about SuperDuper is the logs indicated what was happening. Don't remember the exact error, but the gist of it is file system reference ID for the mount stopped working and the MacOS created a new reference ID. From the finder, nothing appears to change and the failed disk continues to work under normal usage. IMHO, Retrospect handles this type of failure poorly in general, failing to recognize the mount has disappeared or changed ID and gracefully exit with log entry that would tell us what happened. I would be happy to give the faulty disk case/controller to Retrospect if they were interested in improving the robustness of failure handling for this type of problem. -> Kent
  13. I am getting the following error in my system.log about two to four times a day. Feb 20 03:10:12 iDad com.retrospect.retroengine[70]: #2> MapError: unknown Mac error 22 Feb 20 03:10:12 iDad com.retrospect.retroengine[70]: #2> TVol::GetInfo: UGetVolumeInformation failed, /Volumes/Time Machine Backups/, oserr 22, error -1002 I am guessing retrospect noticed my TimeCapsule sparse disk image was mounted and then disappeared during a Time Machine backup. Is there some way to get retrospect to ignore /Volumes/Time Machine Backups? -> Kent
  14. Dhoh! My mistake. I only see the DVD drive in the Storage Devices. I was thinking of the external drives as storage devices (what I use them for), not sources. In sources, I see all the internal and external hard drives, as well as the remote clients and their drives. When the failure occurs, the sources window shows the AWOL drive with a ~ in front of it's name instead of a radio button.
  15. I tried an experiment and disconnected all but the one external drive that tends to exhibit the problem most often. Did a simultaneous verify of the 5 media sets that had members that reside on this one external drive. It took longer than normal, but still failed. All 5 media set verifications failed with the "Media request for timed out after waiting" error.
  • Create New...