Jump to content

Gerk

Members
  • Content count

    46
  • Joined

  • Last visited

Everything posted by Gerk

  1. Hi Folks Ran into this problem yet again ... it seems that about 3/4 times I have to recatalog a tape I run into this problem. If for any reason during a backup something fails it ends up hanging. When cancelling that particular script from the backup server, the next time I try and run a backup script with that same tape set it tells me I have to recatalog, so I do. I let the recatalog run for about 6 hours (it still showed it was cataloging files) but it looked like the same ones over and over again. I finally stopped the recatalog (scheduled building wide power outage over the weekend). Today when I try and use any scripts the run from this backup set I find that it's hosed once again. It tells me that tape has 600G of data (whgich considering it's a 110G SDLT is impossible). This not only causes a problem for the tape in particular, but it also renders the backup set mostly unusable due to the 100G limitation. This is getting extremely frustrating here, haven't had a suggestion or resolution to date. Anyone have any ideas?
  2. 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?)
  3. 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.
  4. 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
  5. bump. No other ideas from anyone? Is anyone else having problems similar to this or am I just extra lucky LOL?
  6. 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.
  7. 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.
  8. 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).
  9. 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?
  10. 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.
  11. Oh forgot to mention it's running on OSX server 10.3.9
  12. 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
  13. 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.
  14. 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.
  15. This happens now 4 out of 5 times that I try and cancel a running script, in Backup Server 6.0. Steps to reproduce: Hit cancel during a script running from Backup Server Expected Results: Script cancels and returns control to user Actual Results: Retrospect hangs after about 5 minutes of the spinning beachball All access to SCSI SDLT320 drive is locked out until server reboot Pushing eject button on tape drive causes hard lock/kernel panic on server (even after retrospect is no longer running) Machine/Software Specs: OSX Server 10.3.7 (with all but today's security patches) Permissions repaired nightly (cron'ed) Retrospect 6.0, running Backup Server If anyone has any suggestions it would be great and if there's any other info that would be helpful please let me know. This used to happen on occasion, but now happens regularly, even after clean install of OS. Hardware disagnostics show no problems with SCSI card or tape drive.
  16. 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
  17. I have just updated to the latest driver update and will see what happens
  18. Retrospect 6.0.204 SCSI adapter is an Atto Express PCI Pro (UL366) with latest firmware Device Access Version: 1.0.106 Driver Update Version: 5.9.104
  19. I wish more companies would realize that RedHat is not the only Linux out there ... saying that you support "RedHat EOL on x86 only" is not saying that you support Linux. In the windows world it's like saying "We support windows" when in fact the application is only supported on the OEM version of Windows 98SE that comes with "such and such" a model of machines. Actually on second thought I think that is giving credit for too much market share as Dell sold a LOT more machines with win98SE than there are redhat EOL servers on the entire planet. Not trying to complain, just trying to inform. Advertising that "Linux" is supported are very misleading so hopefully this thread heads off a lot of other user's questions when they ask "is ____ Linux supported?" The short answer seems to be that if you are not running the commercial RedHat EOL on x86 hardware then the answer is "No."
  20. Gerk

    PPC Linux Clients

    I will forth (heh, sorry for the pun but other ppc linux peeps might get it -- it's not a typo -- really) the nomination for a PPC backup client. There is a lot of PPC hardware out there running linux, and not all small potato workstations either . . . IBM pSeries comes to mind off the top of my head. The i386 clients ones wont work for many reasons ... they are binaries compiled for a different architecture, there will be endiness issues (byte swap order) as x86 is little endian, where most other linux compatible processors (PPC, Sparc, ARM) are big endian. You _might_ be able to get it work with something like qemu on ppc, but it's not a good solution and chances are it wouldn't work as expected For proper PPC support this would require dantz to recompile clients specifically on ppc (and likely make a lot of code changes to support the endianess stuff, etc). I use PPC linux boxen exclusively and right now the only real backup software option I have is Storix, but I would _love_ to have all my machines running retrospect and backing up to the same hardware.
  21. I do this with some small trickery ... I format the tape with the appropriate naming convention ... i.e. 8 - Onsite Set A (or whatever your setup is) to what the next member name would be, then I run a local script that backs up the config files of retrospect to that backup set. If it's the only tape available and has the right naming conventions it seems to work here for me in that it backs up the tiny little files to the tape, and includes it as a set member without further trouble.
  22. Good question, I'd like to know too as I have the same problems here.
  23. Ooo fun fun fun. netatalk can cause any number of problems, and I suspect this is what the SNAP server is running if it's BSD based. In the past I had to do a lot of jumping through hoops with netatalk in day to day operations, let alone trying to run backups from it. In fact if you find the netatalk-dev list (think it's on umich somewhere) you will see the chaos that often ensues with it! I stopped using it a while back sadly, I lost too many files to it over the couple of years I ran netatalk based stuff.
×