Jump to content


  • Posts

  • Joined

  • Last visited

c3768c36-bf22-4c6d-bc39-cdddd3062225's Achievements


Newbie (1/14)



  1. The UL5D is in the G5 (PCIe) - a version prior to the UL4D is in the G4 (PCI-X). Everything is terminated, the UL5D has been updated and I have been able to access it via the ATTO Config tool without any problems. I have yet to switch cables - only because I am running another backup currently on the G4 using the first batch of files - so far, no errors, this is on a tape that the previous batch had given me an error on the same file twice. Next I'll add the second batch back into the mix minus the files that appear to be giving me trouble. I just can't believe that a couple of files would cripple the whole backup like this. I've been running Retrospect since the 4.0 days and have never had a single file or batch of tapes give me so much trouble. Thanks for the input though. If I hadn't experienced issues on two different SCSI cards I would've thought it was the card as well.
  2. Here's the set up: G4 867, OS X 10.4.11, VXA 320 via SCSI, Retrospect 6.1 This exact set up was in use for a couple of years prior to the issues described below. We attempted to upgrade to Retrospect 8 on a G5 with a brand new ATTO SCSI card. Of course, we weren't able to see clients because we were running V.8 on a G5 with 10.5.8 - at least that seems to be the consensus from the forums. So, we're patiently waiting for an update to address this issue. In the meantime I tackled two possible solutions. Moving V.8 with the ATTO card to a Mac Pro, or breaking out the old G4 setup. The Mac Pro was a bust - the V.8 Engine would quit unexpectedly during any backup. So back to the G5 we go while I contemplate using the G4. At this point the common denominator between the Mac Pro and the G5 is the SCSI card - which had initially given me problems even showing up in the PCI bus, until I switched to a different cable (the previous cable and VXA show no problems when on the G4). So I'm crossing my fingers that this a problem with the card. The G4 had been wiped to be put on Craigslist. I reinstalled Retrospect 6.1 on a clean system, brought over the catalogs that we had started at the first of the year - which had not been successfully updated in months due to troubleshooting these issues. Rebuilt my scripts, etc. My main priority is to clean off our Completed RAID - this drive stores all of our completed projects, when it starts to fill up we dump the older or less accessed files to tape - twice. One version stays here for our use, one goes offsite. The RAID is connected via Firewire to the aforementioned G5. A completed folder on the RAID is shared allowing all the artists to dump completed projects to the RAID. Our drives are getting full - we need to move stuff off that RAID to tape so we can clear off completed work from our drives. The set up is simple - backup the entire Completed shared folder. We're up to about 350GB that needs to be on tape at this point. Here is where the Error 203 began to occur. About 50 or 60GB in it would stall on a large file - my r/w time would drop from 800mb/min to less than a hundred. And then I'd get the error. Of course this makes the catalog out of sync. Attempting to repair the catalog never finishes. It rewinds the tape, reads about 5 files, sets on "resyncing (slow)" … for hours. I've even let it set an entire weekend. And it will not sync. Fortunately we're only 2 tapes into this particular set. And I have a backup of the previous version of the catalog file - so I revert back, like nothing ever happened. Try it again. Different tape 3 (clean, straight out of the cellophane). Error 203. Frustrated, I move the tape drive back to the G5 with 10.5 installed. This machine has both Retrospect V.6.1 and V.8 - not running concurrently of course. So I go through the same motions using V.6 - same error. And it happens on the same file as before. So I check the files - nothing seems to be up - they're not corrupt, I can copy them to another machine, open them up. So I think maybe this tape went bad during the previous attempt on the G4 - if it's writing to the same piece of tape that it was on during the previous error maybe it messed up the tape. So I try again - keep in mind this means reverting back to a previous version of the catalog and waiting for it to get through 60 GB data, I have real work to do and we need access to the tape drive to pull jobs, so I'm only able to do this troubleshooting sporadically. The second attempt on the G5 fails with Error 203. In desperation I fire up the Retrospect Engine and try V.8 - keep in mind, this is a local share, we're not even accessing a client here, so I had hoped that V.8 would at least let me accomplish this. It gets to about 120GB - then Error 203. This was also on a clean tape - at this point I'm convinced that I either have a bad batch of tapes or that Error 203 is corrupting the tape I'm trying to write to. I'm sitting on 3-4 possible bad tapes. So, I'm getting the same error on two different macs, the common denominators are (1. tape drive (2. scsi cable (3. files. I run the Exabyte tools on the VXA - Full Tape r/w test. It doesn't even hiccup. Double-check the tape drives firmware is up to date. Order more tapes. Rinse and repeat on the G4 as well - no problems from Exabyte tools. At this point I'm at a loss - I've moved the VXA back to the G4 - this is the set up that had worked for years prior. Except the cable is different, and of course the files. This time I get through the same 130+ GB as I did using V.8 back on the G5, it doesn't crap out around 60GB. I'm on about 30GB of tape 4 and Error 203. With the catalog out of sync, tape 3 is now crap. So decide to split the files up. If I can get half of the data backed up (which I now know I obviously can) then I won't lose as much ground when I get the inevitable error. It worked - sort of. I got through tape 3 - over 160GB of data - I move this stuff out of the Completed Folder and move the remaining 160+ into the folder for back up. Error 203. Twice. On the same file, on two different tapes. I'm down 6 tapes now. The boss is not happy, this is getting expensive and very time consuming. If this is file related, why did it get past the previous file it was stumbling on before I tried V.8. Is it even possible that a file can cause the 203 error? Can that error corrupt my tapes? I'm going to move the four instances of the "bad" file out of the backup and try again - but any other suggestions and/or recommendations are welcome. Sheesh.
  3. I'll try that the next time I set up V. 8 on the MacPro - I've gone back to just trying to get V. 6 running on a G5.
  4. Any new status on this issue? I too was running 8 on a MacPro, backing up to a VXA 320 via ATTO SCSI, the Engine was always quitting by itself. Time Machine is not enabled on this machine, accessing only 1 client via a test script backing up only one folder with about 50GB of data. Though the data could be the problem, it never appeared to happen at the same time or on a certain file. I'd check the console and it would show that it has lost connection to the backup server. I'd check the engine and it would be off.
  5. I second this - Kernel Panics are almost always hardware related. Can be quite the pain to track down. RAM is the usual culprit, could also be the logic board, power supply or hard drive.
  6. Ugh - I'm at my wit's end now. Set up v.8 on our MacPro - set up clients, set up a script, sources, etc., etc., - we have about 360 GB of data that needs to be archived. Everything seemed to be working (gasp) - I had over 150 GB written to tape, was running at about 800mb/min. I added the second tape, assuming that by the next morning we'd be verifying and everything would be fine. Sometime that evening the Retrospect Engine quit. Upon restarting the Engine the app re-established its connection. There's no indication in the app that the script finished or failed. Upon running the script again, it appears to start over disregarding the previous 150 GB of data, but asking for a new member (ala tape 2). So I assume that because the data wasn't verified that it never actually added it to the catalog - but it wants to start with a new member? So whatever, I decide to go with the flow - hoping that Retrospect knows best. So tape 2 starts to back up. Getting horrible r/w speeds. Around the 60mb/min range. Frustrated, I just let it go. By late afternoon it wants new media. But has only backed up 20GB! So start over. From scratch. Erase the tapes, delete and redo the script, everything. This was Friday afternoon at this point. I set everything to go again and by the time I leave we're running a bit slower than before (200/300mb/min) but it seems to be going. I leave, fingers crossed, hoping to come in over the weekend and just switch tapes. Sunday - the Engine has quit again. I restart the engine, only 2GB are confirmed to be backed up. I run the script again, tape 1 is still in the drive. It asks for another tape. So something is obviously screwy here. But I oblige - insert a new blank tape, it starts to run. All I can do is leave. This morning the engine has quit again. I'm at a loss now. There seems to be nothing in place from a software standpoint to deal with a quitting engine. I've review the logs in the Console and plainly see where the engine quits, but there's not much more to it. Anyone who thinks they may get some valuable info from the logs, let me know and I'll post it. I think at this point I'm going to roll all the way back to the G4 that worked with v. 6 - albeit extremely slowly. And research alternative software compatible with our VXA moving forward. This is ridiculous.
  7. I haven't been messing with R v.8 for a while. We're back to 6 - but even that is giving us issues. The same setup that was pretty solid, albeit extremely slow on a G4, is now unusable on our G5. In desperation I've moved our SCSI card along with our VXA drive to a MacPro. Since then I've only managed to get between 100 MB and around 30 GB on a tape before I get a 204 error. This is typically a device busy/device in use type of error and I cannot for the life of me determine why this is happening. The terminal tools for the VXA allow me to run a r/w test to the device, which I previously did while on the G5 with no issues. So I have apparent hardware issues now in 6 and software issues with 8. I have 360 GB of completed projects that need to be moved to tape so we can move the 100s of GB from our local machines to our completed "drive" (a shared folder on a 500GB RAID). Today I will fire up v.8 again from the MacPro and see if I can at least get our completed projects moved. This is ridiculous from a hardware/software standpoint. If someone would step up with a great piece of Mac software for tape I'd be all over it.
  8. Since CallMeDave is having a similar issue, I don't think this is isolated to PPC. Though if I get a chance this week I'll see what I can do. Ultimately though the G5 with SCSI card and the tape drive is our archive box, the worker bees get the Intels - so getting the engine to run on x86 and see the clients won't help much
  9. No change after renaming the volume. The icon in the status column (far left of client name in the Sources view) has always been gray (clear) - I've never seen any of the other status colors as indicated in the manual. Running the Desktop version of OS X. This machine is also running Studiometry which we use for job tickets, project coordination and billing. Studiometry and Retrospect are all this machine does. It is the last G5 model prior to the Intel boxes - 8 GB RAM. I believe that topic is regarding Firewall settings. All of our clients have their Firewall turned off.
  10. Here's what I get… Davids-Mac:~ dburney$ ls -la /Volumes total 16 drwxrwxrwt@ 6 root admin 204 Jun 20 08:20 . drwxrwxr-t@ 40 root admin 1428 Jun 20 08:21 .. -rw-r--r-- 1 dburney admin 82 Apr 26 08:28 ._iTunesFS drwxrwxr-t@ 41 root admin 1462 Jun 15 17:50 MacClone lrwxr-xr-x 1 root admin 1 Jun 20 08:20 Nacho -> / drwxr-xr-x@ 47 dburney staff 1666 May 19 16:58 Pustulio Does not look out of the ordinary. Nacho is the volume that want. None of our machines are using FileVault. On a side note, I assume that this version of the client won't work with Retrospect 6? I need to move back to 6 until this is resolved and am guessing I'll need to uninstall V. 6.3 and reinstall 6.2.
  11. 1. Removing and re-adding clients doesn't appear to make a difference and the user is always logged in. The SL client has a static IP manually entered. 2. I've ran the port scan on both clients (static IP added and auto-added with public key) and they both have the appropriate port open and neither have the firewall running.
  12. Unfortunately the users are indeed logged in and the machines are awake, not even running a screen saver. I've tried turning the client app off/on and immediately rebooting as well. I could see something hokey happening with one client. But two leads me to believe that I'm missing something, but I don't know what it could be. Both machines are running the latest version of the client, are wired (not wireless), able to share files/folders with other machine, even show up in Retrospect 6. I've added one machine manually with a static IP, the other using "Automatically Add Clients" - nothing works.
  13. I wish it were that easy. I think we've established that the problem is Volumes on the Clients are not visible for some reason. Regardless of the option (All, Selected or Startup), no Volumes will show up.
  14. Volume names are at least 5 characters and of the two I'm testing, one is just Macintosh HD. I did go ahead and set up a script for one client to see if I could get anything to back up at all and the log shows "Container David's Mac was empty (had no volumes)." One machine is running Leopard, the other Snow Leopard (David's Mac). I've also reinstalled both clients from scratch after what I think is a complete uninstall (per these instructions). The Leopard Mac is using a public key, the Snow Leopard Mac is using a custom password. I haven't managed to discover the culprit - but it appears that for some reason the Client's volumes are no showing up. Incidentally, firewall is turned off, file sharing is on sharing one folder on each Mac.
  15. I'm attempting to set up a new install of Retrospect 8 and I can't seem to get to any of the folders on the client machine(s). I've uninstalled and re-installed the client. I've restarted the Retrospect engine. The client(s) are currently set up using a keypair and add clients automatically is turned on in the Preferences. I've deleted the client and re-added it using both Multicasting and directly via IP address. All to no avail. I've followed the instructions in the manual to a "t" - I think. Very disconcerting for someone who's been using Retrospect since the Dantz days (v. 4/5). For what it's worth we are (maybe) moving up from Retro 6. I ran the new client installer without disabling or deleting the previous client, but have since deleted the Client.app and reinstalled it again. Surely this is a result of ignorance - what use would a client be if I can't specify what I want to back up from that client. I've included two screenshots - one of the source screen as I added the client, the second of the Sources pane as it appears once the client has been added. I was under the assumption that at this point I could browse the Client and/or add Favorites of folders, volumes, etc. Any help is appreciated.
  • Create New...