Jump to content

billraab

Members
  • Content count

    15
  • Joined

  • Last visited

Community Reputation

1 Neutral

About billraab

  • Rank
    Occasional forum poster

Profile Information

  • Gender
    Male
  • Location
    Minneapolis, Minnesota
  1. billraab

    SCSI through thunderbolt?

    When I retired our DLT (and prior to that DAT) system I retired it along with the Mac host, fully intact. I have very rarely had to return to these machines but they are there if I need to recover something. It seemed the most efficient and economical thing to do. Futzing around with seldom used hardware in a modern system, if there was a problem, would be more painful than the space surrendered to keep these old machines in house. If I need something I just bring it up from storage. Plug it in, it boots and into Retrospect 6 I go for recovery.
  2. billraab

    Mac client won't run

    My suggestion would be to run the un-installer from the client installer DMG. Then navigate to Macintosh HD/Library/Preferences/ and delete the "retroclient.state" file. Then re-install the client. That has solved similar issues for myself. Good luck.
  3. I had a similar issue but I allow backing up over wireless as well as ethernet. The problem being I wanted ethernet to have the priority if both were active. What worked for me was to make all ethernet connections have a static IP (eg 192.168.1.111) and not use DHCP. Wireless can still use DHCP but not ethernet. From what I have seen Retrospect chooses to use the ethernet if this is how things are set up here. However when I was using DHCP on the ethernet connections it was a cr@pshoot as to what Retrospect would use for backing up. More often than not it chose the wireless connection. That is until I had static IPs implemented on the ethernet connection. I hope that helps.
  4. Just saw this last post David... my apology in delay of response. It is backing up the server via the Retrospect Client software.
  5. Yes, it had happened in one of my two scripts for Retrospect 9. I started a new script with my update to 10. All I know is that in version 9 it works fine... albeit slower... but speed is not as important as getting complete and consistent backups. My upgrade to 10 was without cost so I am out nothing. The server (File server) is running 10.4.7, not the Retrospect Server which is on 10.7.5. The XServe RAID is connected to the Apple File Server locally. The Retrospect system backs it up just as any other client... at least in Retrospect 9 anyways. I'd love to return to 10 but at this point things will stay as they are on 9.
  6. Thanks David... can you explain why retrospect 9 performs backups without my issue and why 10 does not? I guess that would be a better clue to defining the problem. What I am asking is what does 10 do that 9 does not in respect to file modification determination (sans attribute modification date as it was disabled)... or what does 9 do better than 10? Either works for me. Thanks
  7. CallmeDave: This is a Mac Server version 10.4.7. The source is an X Serve RAID. Retrospect 10. I backup many different machines... this one is the only problem. DavidWLee: I have disabled the script's Use Attribute Modification date = no difference. I have disabled RetroISA to no avail. I have since reverted to Retrospect 9 and it looks like things are falling back into place. I need a bit more time to make sure operation is consistent. I changed nothing but the Retrospect versions. Same scripts, same catalogs... only the version has changed to protect the frustrated. :-)
  8. I have been experiencing the same nagging issue of Retrospect 10 continuing to backup files that have already been backed up. I am about to throw in the towel on 10 and move back to 9. I sat on version 6 for years... I can do the same for 9 if I can bring everything back to correct operations.
  9. I am not 100% but I believe it is stored in the catalog file on the server.
  10. In fact disabling that option has made things worse for my other set that had been fine. I will re-enable it. <edited>
  11. Unfortunately it seems to have made no difference. I wish I could figure this out... I have another set running parallel to the problematic one and it does not exhibit the same issue. I love a challenge but this one is driving me nuts. I may just try the new set option which stinks as it sets me back... and then if it does not help I will be setback even further.
  12. Thank you Lennart and why I have not seen that is beyond me. I have been searching and trying to figure this out since January. Just when I think I got it licked it happens again. I am confused though as now I feel like I am taking a chance on some data not being backed up. I will run things with this setting disabled and see how things work out for me... and report back. Again, thank you. You are a huge help to these forums.
  13. I am in danger of being driven insane by Retrospect. Our main file server which has several TB of data needing backed up has been backed up, in its entirety, by two of two scripts. One of which seems to forget what has already been backed up and backs up the whole darn thing again. This happened in version 9 as well and with a different script. I am happy to provide any further details if someone has some ideas. I don't want to keep burning through tapes for no reason. This machine has been backed up in completion on more than one occasion and I have watched as the snaphot is created as well so I know the process is completing properly. This does not happen with the other three dozen or so machines backed up on the same script it is just this one machine.
  14. billraab

    Wow. Pretty fast!

    That is awesome. I would be happy with oh say.... 20% of that speed.
  15. billraab

    Looking for users' opinions of Retrospect 9

    I find it to be more reliable and stable than any other version I have used. I have had no problems. I skipped over 8... my momma didn't raise no dummies. I am happy to have upgraded... seriously.
×