Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About kevinf94

  • Rank
    Occasional Forum Poster
  1. yeah, some of them are Intel. i've seen the Net Retry errors before on laptops that were set-up with Portable Home Directories. some of our PHD laptop would have their auto-sync stall and that seemed to affect Retro where Net Retry errors would spring up. but Retro seemed to kick out of the client and give a "network communication error" in the log. now it seems to just keep trying and trying and trying. and, you're right, these seem to be on the Intel machines that Retro won't let go. hope it doesn't happen this weekend.
  2. Sorry for not stating what equipment/version I'm running. Got Retro Workgroup 6.1.126 running on a PowerMac G5 Dual 2GHz with 5GB of RAM. Majority of client workstations are running Retro Client 6.1.130.
  3. OK, here's the deal. I run incremental back-ups Mon - Thu on a 2 week rotation. I have several Selectors in place on my scripts to weed out unwanted info. One of those selectors is to not back up any files created prior to 1/1/07. So, with this selector in place you know that the amount of data is going to be small and the logs have reflected that. Typical user has about 100MB of data being backed up right now. Can someone please explain why it takes 15 min for Retro to do this per user? At the end of one of my incremental logs this week it stated that the entire back-up process took 9 hours & 29 min (for roughly 60 clients) with 8 HOURS & 44 MINUTES SPENT IN THE IDLE/LOADING/PREPARING STAGES!!!!! Can someone please explain this to me? Why is Retro taking so long to back-up these clients? I don't mean the actual back-up time b/c according to the log, it was about 45 total minutes of actual back-up time. What is the deal with 8+ hours of loading/preparing? I've watched these back-ups in process. Retro scans the client (2 min or so), then it matches against the set (another min), then it goes to "Continuing execution" and literally takes 10+ minutes to finally start backing up files. What is happening in all that time? Is there something wrong with my scripts? How can I get Retro to kick in faster so I can get more than 4 or 5 clients/hour backed up? There have beens some clients who only get 40MB backed up on one of the incrementals, yet the entire process to back-up this client is 15+ minutes. Does that make sense? It doesn't to me, so can someone enlighten me please.
  4. I have been getting some user's showing up with Net Retry errors during a backup. What pisses me off about Retrospect is the software doesn't move on from the affected client to the next one on the script. Last weekend Retrospect continued to try to connect to a user for 12+ hours which completely screwed up my Recycled weekend back-up. Does Retro have a built-in time-out where if it can't connect to a certain client, it gives up and moves on when it comes to Net Retry issues?
  5. Dantz told me that these errors are caused by not having enough memory in the machine. I run Retro 6.1.126 on a Dual-1Ghz G4/2GB RAM and constantly get this error when doing a Recycle back-up over the weekend. The reason I'm not sure about it being a file number limitation is b/c while I might have one client in my script give the -108 error, the next client then gets backed up, then the next 4 or 5 clients get the -108, then another client might get backed, and so on. I also tried splitting my script into 2 scripts, but backing up to the same set. I get 10 or 15 clients on the end of the first script giving me the -108 errors, then the 2nd script kicks in and 50 - 60 clients get backed up with no problem! I've been meaning to upgrade our backup server to a G5 with 5GB of RAM, but haven't had the chance yet. Btw, when you mention file limitation, do you mean file limitation to the entire backup set?
  6. I have a Windows client attempting to be backed up to a OSX back-up machine. All the other Windows clients backup successfully. This client machine is seen by Retrospect and can initiate the scanning of the client before backing it up. But, it stalls in the same location during the scan, then says it's attempting a NET RETRY, then gives the Error 519 (network communication failed) dialog box. All the while the machine is at NET RETRY, I can successfully ping the client's IP address. Any ideas as to what's wrong?
  7. Can someone please explain this to me? I have received multiple error -108 messages during my full weekend back-up on many clients towards the end of one of my scripts. Funny thing is there are clients that are getting backed up in between clients that aren't b/c of the error -108 message. How is this possible? How can several clients not get backed up b/c of the error, then another client have 5 or 6GB backed up before the next set of clients aren't? So frustrating to see this happen.......
  8. I'm looking to add some back-up drives to two OSX servers very shortly. I'm backing up one server to an external Firewire drive and the other to two AIT-2 tape drives. Can someone please list the pros & cons for adding an AIT-4 drive to each or a LTO-3 drive to each. Thanks!
  9. Can someone please explain how to speed up individual client processes? A typical scan through one of my clients takes about 2 or 3 minutes, but then Retro WrkGroup 6 goes into the back-up window and sits with the "Continuing Execution" message for a very long time. Sometimes it's 10 - 15 minutes before Retro actually begins backing up data. That is entirely too long to wait. What is going on when Retro says "Continuing Execution"? Please help!!!!!
  10. Here's what I'm running: Retrospect Workgroup Server 6.0.204 OSX Server 10.3.4 4-tape AIT-1 library I am trying to back up files that are local to the OSX Server. They're actually RAID volumes set-up on an XRAID. I have pretty much the same set-up on another machine, except it's backing up to two daisy-chained AIT-2 drives. No problems running that back-up. This set-up has the library. Anyway, Retrospect sees the device OK, but after it does the scan of the volumes and gets to the "Continuing Execution" area, the OSX Server shuts down. I'm not sure if this is a Retrospect problem causing this or a problem on the OSX Server. Any ideas?
  11. here's the problem in detail: one of my scripts which runs twice/week/every other week sends data to a back-up set that now gives me this error (error -24205 (chunk file damaged during save)). i don't believe that this back-up set is usable anymore, so i wanted to rebuild the set (6.6GB in size, which is over 600GB of actual data spanning 7 tapes). this rebuild will take so many hours to do at once. i was hoping to start the rebuild from tape 1, then stop it and continue another day from tape 2 and so on, building the data to the new rebuilt script piece by piece. i'm trying your method now. wish me luck!
  12. I have to rebuild a catalog set set over 6 or 7 AIT-3 tapes. The rebuild process will take many hours since there is so much data to rebuild. Is it possible to rebuild a catalog one tape at a time. What I mean is, can I run a rebuild that gets through 2 tapes, then stop it, then add to the rebuilt catalog at a later date using the next progression of tapes?
  13. I am running Retro Workgroup Server 6 on a dual-1Ghz-G4 connected to a Sony StorStation AIT Library. I have noticed that after Retro does a scan of my networked clients, it takes forever (8 - 12min) before it starts backing up files. The back-up window sits on "Continuing execution" before it snaps into the actual back-up mode. There has to be a quicker way for Retro to start the actual back-up process once the scan of the machines are done. Please help!
  14. Quote: - What are the Operations Log entries for the error? Scanning incomplete, error -108 (not enough memory) Quote: - What exactly does your script look like? It is a recycled script with a custom Selector, Verification off, Data Compression, Matching off, Data Compression of files relevant to my Selector, Do not shut down client machines, Do not backup Filevault images. This same script run nightly to a smaller group with no problems. Maybe it is the large number of clients. I can test this weekend.