Jump to content

Don Lee

  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by Don Lee

  1. When doing a restore, there is an option to "Update modify dates", which one might guess would set the modify dates on restored files to that of the file backed up. Not so. From the documentation: Update modify dates: This option is only available for restore operations. It causes Retrospect to set the modification date and time of restored files to the current date and time. By default, this option is off. I think this option needs a tooltip explaining that leaving it OFF produces a more faithful restore, and turning it "on" is essentially a command to "touch" all the restored files.
  2. It happened several days ago, and I'm not certain about the sequence any more, but I think the story was like this. I was doing something with the tape, and Retrospect 9.0.2 requested another tape. I took the opportunity to clean the tape ddrive, but Retro didn't "see" the cleaning tape. When the cleaning was done, I put in the tape it was asking for, and the display persisted as "empty" (no media). I futzed with "scan" and "scan all" and waited a bit, but nothing changed. Thinking this might be an issue with the drive, I power cycled the drive. Mistake. As I recall, when I powered up the drive, and tried o operate on it, the console hung. Then I tried cycling the engine, and the engine hung. It was a busy hang, as I recall. I could not get the console to connect at all, nor get the control panel to stop the engine. I ended up killing the engine (kill <pid>) The attached file is a sample of the engine from Activity Monitor. Lesson: don't take devices away when Retro need them, or it gets unhappy. Sample of RetroEngine.txt.zip
  3. Don Lee

    Shutdown/Start engine via Terminal

    I think that should be updated. It's /Library/LaunchDaemons/com.retrospect.retroengine.plist now. Roxio is no longer involved.
  4. Having no direct knowledge of my drive and how it works internally, I hesitate to comment, but the relative speeds of USB2 (60 MBytes/sec), the top speed of the tape (6.4 MBytes/sec), and what I know of the size of the buffers in the tape drive (in this case, 8 MBytes - about 1.2 seconds worth of data), I have my doubts about this. In other words, I find it hard to believe that an 800 Mhz PowerPC can't drive 6.4 MB/s (max speed of the drive). That's pretty unimpressive. Maybe Retrospect 6, processing, and lord knows what is burning all the cycles, but it's still unimpressive if true. I *have* noticed that when writing a tape on retro 6.1, the CPU is very busy, which I would not expect if all it was doing is pushing data to the tape drive. For that matter, the CPU is pretty busy when writing tape with Retro 9, too. Even if you assume that the checksums and MD5 hash calculations are burning some of the cycles, it's hard to see that being hard to do at 6.4 MBytes/second. In any case, it's much better with Retro 9.
  5. I confirmed my theory today. I went back to a media set (backup set - 6.1) that I had tried to rebuild several times, and given up. When I waited for the tape to fully load, and come up with a name, the rebuild worked fine. Race.....
  6. This has been a real frustration to me. I now know how to work around it, and describe how to reproduce it. I have tracked down the trigger for a problem where I rebuild my v6.1 tapes, and Retrospect 9 happily reads the entire tape set, but comes out with a catalog showing zero files. I have documented several similar cases of this here. I have not tried to explore all the combinations of conditions on this, just the ones that were relevant to me. My tape drive is a USB HP DAT72 tape drive (Storage Works). Retro, Mac OS X 10.6 One procedure for reproducing this bug is as follows: 1. Ensure that the tape you want to rebuild does not have a v9 catalog. Tape drive should be empty. 2. Go to the "Media Sets" display, and click on "rebuild". The first dialog selects the type of rebuild. Choose "tape". Click "next". 3. Next dialog selects the device. Choose the (empty) tape drive. Click "next..." 4. Next dialog chooses the location of the catalog. Wait here. Timing is important. Select your catalog location, but DON'T click "rebuild". 5. Insert the tape in the drive. 6. Immediately hit "rebuild" in the dialog. You will get an error. Keep clicking "rebuild" until the dialog is dismissed. Watch the activity, and watch Retro read the tape, without effect - note in the summary window in the activity that no files are counted, and no MB/s rate is displayed. It will read the entire tape, and do nothing. On the other hand, If you wait until Retro has recognized the tape before you click "rebuild", it will work fine. I smell a race, and user frustration for the impatient. (like me. ;->)
  7. I have identified one cause for different results on different operations, the apparent race condition when loading the tape drive, as documented here.
  8. I have identified one cause for different results on different operations, the apparent race condition when loading the tape drive, as documented here.
  9. I rebuilt 4 retro 6.1 "quarterly" sets from tape, and copied the data to a single disk set. The fourth set suffered from the problem above, with the zillions of "inconsistency (2 at ....)" errors, and then the resultant rebuilt catalog was empty. (see here ) I just upgraded to Retro 9.0.2, and re-did the catalog rebuild. To my surprise, the catalog is being built *cleanly* - no errors. Is this a fix in 9.0.2? Is this an intermittent bug in 9.0.1? Is the process of reading the tape unreliable? What's up with this?
  10. I'm not certain about this, but it appears that having more than one entry in a schedule for a "proactive backup" does not work. I stumbled on this today when I wanted one of my proactive backups to run *now* and the scipt was "inactive". I thought I could simply add another entry to the schedule, saying that on Sunday, all day, it could run. I was unable to get this to work, and I don't know why. It *appeared* that the second schedule entry was simply ignored, but I did not experiment enough with it to be sure. The reaction time of the engine was also a frustration. Sometimes the engine would start up the activity IMMEDIATELY when I changed it in the script. Other times, it would not respond for some time. Again, I did not experiment enough to figure out what was happening, but there is clearly something there that is unexpected, even if it is intended. Retro, Mac OS X 10.6
  11. Another example of the file dialog being funky - Retro, Mac OS X 10.6.8 Picture enclosed. Note the yellow icons for firewire disks, the blue ones with the squiggles for network disks. They should all be at "top level", but in this case, some are down a couple of levels in the hierarchy.
  12. When Retro presents me with a dialog of volumes, I have noticed that sometimes the display is wrong. It also changes in the way it is wrong. The picture enclosed shows one way it messes up. Note that this machine has an internal disk, and 3 external FireWire drives. One of the FW drives shows up as a subdirectory under "Macintosh HD" rather than at the top level. I have also seen volumes show up in ".Trashes". Unfortunately, this is not stable. It only happens sometimes, and I don't know what triggers it.
  13. Earlier today, I had my backup storage (firewire disks) configured from the Retro engine ( as AFP shares, with the backup sets (files) on the share. I had a 6.1 set that I had rebuilt partially - because I had to interrupt it. The set was about 100 GB, and I wanted it to "finish". Just for grins, I decided to try "rebuild on the set without removing/forggetting the partially rebuilt v9 media set. When I navigated the "rebuild" dialog, selected the 100 GB 6.1 set, and clicked on "rebuild", the dialog did not go away. I waited several minutes, and it still did not go away. Thinking this a bug in the GUI, I did force quit on the GUI, only to find that I could not re-connect to the engine. I checked on the engine. It was clearly still running, but it's hard to tell what it's doing without the console. I let it run a while, thinking that a little patience was appropriate. I was insufficiently patient, tho, and tried to stop the engine. The retro preference panel would not do it. I could click, and the button would not change. Checking on ps -ax, I found that several "launchctl unload" commands were pending on RetroEngine. I killed Retrospect Engine, (kill pid) and restarted it. To my chagrin, whatever it had been doing it started doing again as soon as I restarted the engine, becasue the engine was clearly busy, but the console would not connect. I freed up the console/engine by causing the AFP share with the set being rebuilt to be unavailable. (I killed the engine again, unmounted it on the server, and restarted the engine) Clearly there is some long-running operation that happens when you click "rebuild" that happens *before* it gets spawned off to a thread, and made async. I think that is suboptimal.
  14. Don Lee

    Noon crash

    I know very little about this crash, but I thought I'd pass it along. nooncrash.txt.zip noon-crash-log.txt.zip
  15. Don Lee

    8 AM assert for you

    I set up my production backups on Retro (engine on Mac OS X 10.6) yesterday, and put my backup sets on an AFP volume (shared storage with the old backup server. Old server exporting the disk via AFP) I watched retro run until bedtime. It was pretty busy. The console response was sluggish and slow, but working. When I got up this morning, Retro had clearly crashed at 8 AM, judging from the "startup" in the Retro log, but some operations that had clearly happened (files in media sets, but nothing in the log about the script(s) that put them there) There was a retro 6.1 rebuild active, and a list of backups that ran overnight. Judging again from the log, it looks like the backups were so sluggish that they did not finish, by 6 am, triggering the "stop" time to terminate the scripts (?) I don't know what happened in detail. I am only judging from the logs. The log and the assert log (attached) are included below. 8AMcrash.txt.zip log-8am-crash.zip
  16. Follow up on this: As detailed here, I have found that different runs behave differently. There is clearly some state either in the drive or in the retrospect engine that will cause different behaviors when the drive is power cycled. I do not have enough data points to say anything conclusive, but evidence suggests that the state is in the HP tape *drive*, because my last success after a zero-length-rebuild was to power cycle the drive and re-scan for it without restarting the engine. I still got some errors (out of memory on third tape, and a few "inconsistency " errors), but most of the files were found in the rebuilt catalog.
  17. I got 3 sets in a row that started out with no files "counted' in the summary, and some with "inconsistency" errors in the logs. I decided to see if this is a problem with the engine or tape drive, so I power cycled the drive, and re-read the tape. The second rebuild - same tape - worked. (!) (sort-of... see below) This tells me that power cycling the drive either produced different data afterwards, or something about the power cycling whacked the Retro engine up-side the head and made it happier. In any case, the set is rebuilding, and not showing the inconsistency errors now. I'm going to back up and re-do the other two to see if they now produce different data, too. I'm still wondering what this message means..... !Backup Set format inconsistency (2 at 316745216) I note that the end of the re-build is showing the "out of memory" problem. Here is the tail of the log: ... ... !Backup Set format inconsistency (4 at 315909536) !Backup Set format inconsistency (4 at 315905136) !Backup Set format inconsistency (4 at 315911616) SixOneTree:TAddAbstractFile failed mca_ns_replica.la !Not enough application memory 5/4/12 11:30:21 AM: Execution incomplete Completed: 529856 files, 43.9 GB Performance: 202.5 MB/minute Duration: 09:45:19 (06:03:40 idle/loading/preparing) This does not appear to be a "bad spot" on the tape. I was sitting here, and did not hear the tape drive repositioning, which would be expected if it were having trouble with the media.
  18. I have found that with patience, and if you push the "scan" button (in top toolbar), the tape drive will, at least sometimes, re-appear. I have not tried hot-plugging a tape drive in a "cold" engine, but I can power cycle the tape drive, and the device will be automatically removed from the Retro device list. When powered back on, it will re-appear, after pressing "scan". It may also reappear without the button, but I have not tried waiting that long. ;->
  19. I got the following just now: + Executing Rebuild at 4/28/12 (Activity Thread 2) To Backup Set iCompute11 [001]... SixOneTree:TAddAbstractFile failed objects.nib !Not enough application memory 4/28/12 3:08:39 PM: Execution incomplete Completed: 326998 files, 19.9 GB Performance: 233.3 MB/minute Duration: 01:26:27 This is an 8 GB machine. I have 2 VMs running, and another catalog rebuild running at the same time,and looking in Activity Monitor, there was almost no "free' memory at the time, but the rebuilds (one tape, one disk file set) were not that large - about 400-500K files, 70 GB data - each. (config: Retro, Mac Mini, 8 GB memory, VMware fusion on same machine with 2 VMs (one 1 GB and one 2GB config) Mac OS X 10.6.8.) Is this normal? I'll try again. Maybe doing one at a time is a better bet.
  20. I have a script that copies data, and I don't want the "cache" files. In my copy script, I select the "all files Except cache files". I then click on the "summary" tab, and see that "rule" shows "all files Except cache files". Wait ...... A few seconds later, the "rule" in the "summary" tab says "all files". Clicking on the "rules" tab again, I find that the radio button for "all files" is selected again. I can do this several times. I click on a rule. Go back to the "summary" tab, and a few seconds later the "rule" selection has been switched back. Oops..... Sometimes it will "stick" for a while, but selecting a different script, and looking at the rules will pretty reliably change the target script back to "all files".
  21. Don Lee

    Cosmetic bug: media request window

    I concur. I find that the dialog offers options that should not be offered, too. When you press the (tiny!) "select media" button, you get two choices. One is to "finish", and the other is to "choose...". Inside the "choose..." you get a bunch of choices. The innocent user might think that "stop" means the same as "finish", but that is apparently not so. Even if the operation is complete, pressing "stop" causes the operation to have "failed", which to me is unexpected. I also find the "OK" and "done" buttons to be ambiguous and unclear.
  22. Don Lee

    Tape stops responding after error

    I have learned from experience that my "poisoned" tape causes the tape drive to go "deaf" for several minutes after it his the "rough patch" near the end of the tape. After that, Retro no longer recognizes the tape in the drive, and when I put in a cleaning tape, Retro device status still shows "empty". After some minutes, it works again.
  23. Not much info on this one. I was rebuilding a 6.1 tape set, and it hit an error. The tape drive "clean" light came on after this happened. The log looks like this: + Executing Rebuild at 4/28/12 (Activity Thread 2) To Backup Set iCompute11 [001]... !Trouble reading: "1-iCompute11 [001]" (649462), error -206 ( drive reported a failure: dirty heads, bad media, etc.) !Trouble reading: "1-iCompute11 [001]" (649462), error -206 ( drive reported a failure: dirty heads, bad media, etc.) !Trouble reading: "1-iCompute11 [001]" (649462), error -206 ( drive reported a failure: dirty heads, bad media, etc.) !Trouble positioning: "1-iCompute11 [001]" (649462), error -206 ( drive reported a failure: dirty heads, bad media, etc.) !Trouble reading: "1-iCompute11 [001]" (649462), error -206 ( drive reported a failure: dirty heads, bad media, etc.) !Trouble positioning: "1-iCompute11 [001]" (649462), error -206 ( drive reported a failure: dirty heads, bad media, etc.) !Trouble reading: "1-iCompute11 [001]" (649462), error -206 ( drive reported a failure: dirty heads, bad media, etc.) !Trouble positioning: "1-iCompute11 [001]" (649462), error -206 ( drive reported a failure: dirty heads, bad media, etc.) !Trouble reading: "1-iCompute11 [001]" (649462), error -206 ( drive reported a failure: dirty heads, bad media, etc.) !Trouble positioning: "1-iCompute11 [001]" (649462), error -206 ( drive reported a failure: dirty heads, bad media, etc.) Additional error information for device "HP DAT DDS-DC" [0:0], Sense > f0 00 03 00 00 00 04 0e 00 00 00 00 11 00 00 00 00 8d (぀灒翿 |぀灒翿 |぀灒翿 ) 4/28/12 7:46:45 PM: Execution stopped by operator Completed: 157495 files, 18.6 GB Performance: 164.4 MB/minute Duration: 04:25:21 (02:29:38 idle/loading/preparing) The interesting thing is that the last 3 lines in the log above did not show up, and the tape drive stopped responding. The engine was clearly "stuck", thinking the drive had nothing in it. I manually ejected and re-inserted the tape, and the console did not "see" it. I restarted the engine, and the last 3 ines showed up in the log and the tape drive started responding again. Mac OS X 10.6.8, 8 GB mem, mini. Retro
  24. Don Lee

    Forum Feedback

    I like it. ;->