Jump to content

Gerk

Members
  • Content count

    46
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Gerk

  • Rank
    Occasional Forum Poster
  1. Ooops sorry nate, didn't see this reply until now (I didn't get an email notification on it). What do you mean by proactive script? Do you mean all the backup server scripts? I have over 50 of them currently that were just all redone less than a month ago from scratch and still have the same problems as before.
  2. Ok, back to the by hand methods. I still have this problem so I have to manually remove all the non current backup sets by hand from the scripts or it prompts me for various tapes from those sets. Back to the drawing board. If anyone else has advice I'd love to hear it. In the words of Neville Longbottom (Harry Potter Character) "Why is it always me?" LOL
  3. bump. No other ideas from anyone? Is anyone else having problems similar to this or am I just extra lucky LOL?
  4. As a temporary workaround the only solution I've found to date is to manually disable ALL backup sets that I am not currently running in each script. It's a long process but it seems to work. If anyone can offer any further suggestions I'm all ears.
  5. Ok, nope that didn't help at all. Spent 4 days rebuilding the catalog (which seemed to get stuck in an endless loop as when I stopped it it said it was at 8TB -- and my backup sets can't hold anywhere neat that amount). I deleted the backup sets (all of them), and recreated. Started a brand new backup set this weekend to let it run. When I got in this morning it was asking for a tape from a different backup setup (it was asking for set C) ... set A was fully loaded, all 8 members where in the tape library and accounted for. It backed up a single script in the backup server to Set A (which is fully loaded and waiting) and stopped dead asking for a member of set C. I'm really stumped here and again running without proper backups. Am I the only one that has all these endless problems? I spent more hours with retrospect weekly just making sure it actually does what it's supposed to than any other single piece of software we own.
  6. That might be what's going on, I'll try that when I get back to set D (it's offsite for another 2 weeks). I'll report back here if it works (or not hehe).
  7. Hmm I just checked and I already had that option off. Assuming it's the one in Preferences->Media handling ... Is there somewhere else that has this option?
  8. Ahhh ok I will give that a shot. I've been running most of the last week with no blanks loaded which is less than optimal! Thanks.
  9. Oh forgot to mention it's running on OSX server 10.3.9
  10. Hi All I had been having this problem for a while now with 6.0.x and I just updated to the latest 6.1 release from the web and still having the same issues. I have tape sets A, C and D that rotate. Right now I have all the tapes from set A loaded in the library, retrospect knows they are there. 7 tapes are in use, 8th is freshly formatted. When backup server runs it is almost always choosing set C or set D even though a member of set A is currently in drive. The scripts are set to use A,C and D. It then ejects the current tape, loads the blank one and formats it to be a member of the set that it has chosen (C or D). I can't seem to figure out a way of working around this aside from manually modifying each backup script to only use the one tape set that's current, which is a large task and hopefully not what I have to do. Can anyone else offer up other suggestions? Is this a known issue? hardware: quantum valueloader (8 * SDLT320) software: retrospect for macintosh 6.1.126 device access version: 1.0.107 drive update version: (it's blank! huh?)
  11. Hi John It was a selected volume done through a client backup. It disappeared (in that when the volume was renamed retrospect seemed to behave the same way it would have if I had have told it to "forget" the volume). Because of this it no longer shows up in the originating script or in the report window at all. Also it was done through backup server. HTH Mark
  12. Due to a drive name change (done by someone who was not a backup administrator). Retrospect gave no warnings or showed anything in logs that this drive was 'missing' or not backed up. It dissappeared from the backup scripts altogether. Moral of the story? trust NOTHING. Triple check your backups daily, make sure that each and every backup happens. This makes 4 major data losses my company has had in the last 1.5 years in retrospect, and I felt the need to share this with the community so that it doesn't happen to you as well. Dantz doesn't publicly post any bugs/eratta/known issues with their software that I've been able to find yet, so we are left to fend for ourselves on these matters. In the interest of sharing with the community I would urge others who are experiencing anomolies to share them with us here so that we have enough tools to fend for ourselves and avoid this sort of critical data loss.
  13. Hi Dave Had you asked I would have gladly posted it! sigh. "Gave up" is about where I'm at with retrospect if I can't get this issue resolved Is Eric still around after the EMC changeover? Maybe he can better advise me on this... It's a Lacie branded Quantum SDLT-320, 6-7 months old (it was replaced the last time we ran into retrospect problems and it turned out to be retrospect's fault and not the tape drive's after some deliberation between Eric and myself). It works fine accessing directly from command line on the same box, and it also has no issues when attached to a linux server running Storix backup. Any help you can offfer would be appreciated.
  14. The driver update didn't help, it seems to be worse now, instead of losing communication I go straight to kernel panic, in this case I didn't even cancel but it was a script running (about to start verification). Here's a stack trace from the logs if it's helpful: ***** Fri Feb 4 15:19:22 2005 panic(cpu 0): IOGMD: not wired for getPhysicalSegment() Latest stack backtrace for cpu 0: Backtrace: 0x000836E4 0x00083BC8 0x0001EDA4 0x0026C62C 0x0026C848 0x0026C4A4 0x00717D38 0x0071813C 0x003AB768 0x003B70A8 0x003BB17C 0x003ADEE0 0x006C5D38 0x003ADA28 0x003AE000 0x0071548C 0x00280648 0x0007B8AC 0x00021668 0x0001BCE8 0x0001C0F0 0x000943B8 0x00000000 Kernel loadable modules in backtrace (with dependencies): com.apple.iokit.SCSITaskUserClient(1.3.8)@0x713000 dependency: com.apple.iokit.IOStorageFamily(1.3.4)@0x5f2000 dependency: com.apple.iokit.IOSCSIArchitectureModelFamily(1.3.8)@0x3a6000 com.apple.iokit.IOSCSIParallelFamily(1.3.7)@0x6c1000 dependency: com.apple.iokit.IOSCSIArchitectureModelFamily(1.3.8)@0x3a6000 com.apple.iokit.IOSCSIArchitectureModelFamily(1.3.8)@0x3a6000 Proceeding back via exception chain: Exception state (sv=0x2EED5000) PC=0x900074C8; MSR=0x0200F030; DAR=0x09160000; DSISR=0x42000000; LR=0x90007018; R1=0xBFFF9570; XCP=0x00000030 (0xC00 - System call) Kernel version: Darwin Kernel Version 7.7.0: Sun Nov 7 16:06:51 PST 2004; root:xnu/xnu-517.9.5.obj~1/RELEASE_PPC
×