Jump to content

bdefx

Members
  • Content count

    3
  • Joined

  • Last visited

Community Reputation

0 Neutral

About bdefx

  • Rank
    Newbie
  1. Hopefully this post will help others with this problem. I have run into groom scripts that won't finish and can't be stopped manually. I'm running Retrospect 9 on Mac OS, but I expect this will apply to v8 and likely others. Delete the .log file for your catalog. See the details below. After the script had been running for several days with no apparent progress, I was confident that it was hung. I tried stopping it in the Retrospect UI. It popped up the 'are you sure' dialogue and I clicked stop a second time. I waited several hours and nothing changed, the script was still 'running'. I tried re-booting the system, which took a long time because it had to wait for Retrospect Engine to shut down. Once it restarted, the grooming script continued doing nothing just as before. Next, I stopped the Retrospect Backup Engine in System Preferences. I waited several minutes until it said it was 'stopped'. I unchecked the 'Launch Retrospect Engine on system startup'. and re-booted. Then I went into Library - Application Support - Retrospect - Catalogs. In that folder I deleted the .log file for the backup set that it was trying to groom. Then I started the Retrospect Engine as well as the UI and the grooming script was gone! I immediately started rebuilding the backup set's catalog. I assume the grooming failed because of an error in the catalog, but YMMV. I suspect that the .log file represents the progress made by the grooming script. When Retrospect starts it sees the log file and tries to continue where it left off. By deleting the log file, Retrospect doesn't see that a groom was in progress so it doesn't try to continue doing nothing. In general I find myself having to rebuild catalogs fairly often (several times per year). I haven't seen any recommendation or standard practice suggesting how often this should be done. Should I have a re-build script before and after each groom? Retrospect works great until it doesn't . . .
  2. I'm having the same problem. Avid makes video editing systems (Media Composer). The Avid ISIS shared storage is high performance storage optimized for video and audio production. The ISIS client manager application manages the mounting and unmounting of drives (which Avid calls workspaces). Once mounted, they appear on the Mac desktop with a network share icon. In the Finder they work just like any other drive or network share. If you do a get info on the drive, it says format : unknown (AvidUnityISIS). The ISIS connects to clients through one or more gigabit ethernet connections. It also supports 10 gig. I'm currently trying to backup Avid ISIS volumes with Retrospect 9 on Mac OS 10.7 Lion. The ISIS volumes don't appear in the sources window. They aren't SMB or AFP so they can't be added as a network share. If Retrospect can't see it, I can't start a backup. Page 37 of the Retrospect 9 Guide says: "Retrospect has the ability to use any kind of media that can be mounted on the Mac desktop as a source." How can I make this work? In the past we used Retrospect 6 Mac with our older Avid Unity Media Network. The volumes appeared as soon as the Avid client mounted them. We could backup and restore eaisly. Now I've got several terabytes waiting to be backed up and I'm starting to think I'll need to buy something other than Retrospect.
  3. bdefx

    Time zone handling wrong in email

    Why wasn't this fixed 2 years ago? I use the email feature to monitor my server. I expect that lots of other admins do this as well. I have several other network devices and services that send me regular emails. This is the only one that has a problem with the timestamp. Messages sent at 9 AM show up as 10 AM in most (but not all) email clients. I can't imagine why this hasn't been fixed. Once the correct piece of code is found, it should only require altering a single character to fix it. We're considering upgrading to Retrospect 10, but I think we'll hold off until this is fixed.
×