Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by derek500

  1. Just a final update to this issue. I opened a support case with Retrospect and they confirmed this as a disk/hardware issue. I discussed the problem at length with Lacie and they had me do a low level (zero all data) format on the volume. I had to start my entire backup set over, but since the low level format performance has been steady, and I haven't had one single error from grooming or transfer to tape scripts. I recommended to Retrospect that they add a note to their user guide that whenever setting up a volume for grooming/long term use that a low level format is an important step before starting. I learned it the hard way. Erase with zero all data on any disk volume before using it for backups!
  2. Hi all, My issue is not 'slow' but 'never finishes', even after 7-8 hours. Next backup with a similar number of changed files on the same client will complete including the snapshot in 20-25 minutes. Both the server and client show little to no CPU activity or network traffic during this period. I understand how some clients can be slow, based on total filecount, variations in the client, etc, but this is not a factor in my scenario. The only consitencies I've noticed are W7 and Proactive.
  3. But does the snapshot eventually complete? In my case it will not.
  4. Hmm. Okay, I would agree but here's the thing (besides also still looking for a good way to check registry consistency)- the problem does not persist. Most of the time the backups work fine. This seems to happen somewhat randomly and across any of our W7 clients. Next time this client backs up (based on past experience), it will plow through and finish normally, in a normal amount of time (~30 minutes). Next week (or maybe tomorrow) it will happen on a different client. If I am here watching the Activities on the server console, I can stop it. If nobody is watching it, no other clients in our Proactive script will get backed up until that client leaves the network.
  5. This particular machine is a Dell Latitude E6400 2.6 GHz Core2Duo, 4GB RAM. Not sure the exact filecount but based on the Past Backups it's about 100K files. A typical lightly used Windows 7 Pro laptop. Previously (and probably next time) this system backed up took about 25 minutes and backed up <1500 files. It was completely formatted and with a clean OS install was just given to this user about 3 months ago, so there is nothing large or unusual on it. Our computers are pretty simple, most of the files are IE temp files or a few office documents being updated. This also happens to us with newer, equally as simple, Core i5 and Core i7 systems, none with less than 4GB of RAM. It seems to be only the Windows 7 systems that do this. The older XP systems we have back up about the same amount of files and complete in 10-15 minutes, and I've never had an XP client stuck on Building Snapshot. I believe this is the step where the client creates a registry backup for Retrospect to take. That's a mildly educated guess on my part, but I am not sure about that at all.
  6. 8, 10 hours? How long is "long enough" when it usually takes 20-30 minutes? I have one right now (which prompted me writing this post), started at 8:20 this morning and has been "Building Snapshot" for over 5 hours after backing up about 800MB. I just stopped it a moment ago from the console as I know there are other laptops waiting to back up (it is Monday after all). If I hadn't stopped it it would have built it's snapshot until the guy closed his laptop and left at 5:00 tonight, at least that's what has happened in the past.
  7. I've seen the -519 errors for other appropriate reasons too - usually a machine with a bad hard drive, or legitimately was shut down or removed from the network during a backup. But these are specifically after the building snapshot sits there forever, the rest of the backup completed. I have no problem with the Building Snapshot phase sometimes taking 15-20 minutes, which seems long. It's the times when it has been Building Snapshot for more than an hour I know it's not going to end, and it won't end until we trigger something to happen.
  8. derek500

    Looking for users' opinions of Retrospect 9

    We also have a mixed environment, a few Mac servers, a few Windows servers and 40+ Windows desktops. I suppose we should be using the Windows version of Retrospect server but all our good available backup hardware was Mac so we went with 9. We are backing up many Windows XP, 7, 2003 and 2008 clients and not having the problems you describe, other than several -1020 and the much less frequent -1017 errors. When we were running the demo version with the 'open file backup' add on enabled we did not get these errors. 3 days to back up a client indicates some other issue going on. In general I find 9 to be stable and useful. When we demo'd 8.2 I was very worried about rolling it out as a production backup system. 9.x did not give me the same worries and has been reliable. I am impressed by 8/9's ability to do a full client restore on Windows, it's much more reliable than with 6 and I've tried a few hard drive replacements with great success.
  9. Thanks for all the feedback. I started getting errors like this: !Trouble positioning: "1-Retro Main 6TB Disk" (2154899937), error -102 ( trouble communicating) by the thousands. I tried changing my connection from the SATA/eSATA cable to using FW800 and still got the same errors, so it looks like I have a problem with the Lacie 4BIG unit that needs looking into.
  10. Have you ever used Retrospect to do this backup? Just curious what the performance is like. I don't have another drive of this size to play with, we just transfer to tape instead. When watching the process (via the "Summary" tab) while it's slow it seems to spend a lot of time comparing the catalog file, as if it's trying to decide what to transfer next. Is your backup volume/catalog the same since 2009? Thanks. Were you having performance trouble with the D2T part? Did you find anything that made it better? As we groom to keep 10 backups, and have offsite tapes for DR, I would think a worst case scenario of recycling the entire backup set and re-copying everything from the clients might take a few days, but overall really wouldn't be a giant impact. I could think of that as a twice-a-year task if it makes a big enough improvement. Also that would help me purge out some of the really old backups that I have to go seek and destroy manually (retired systems, etc
  11. I have been trying to figure out how to use Retrospect 9 exclusively for our offsite backups. I think I may have finally found a way. We use Retrospect 9 on a Mac Pro backing up to an external RAID array. This backs up almost all of our clients. We copy the backup disk media set to tape for offsite storage. We still have a Mac OS 9 system to back up. I have a G5 PowerMac still running OS X 10.5 with Retrospect 6.1 backing up to tape for this. (still disappointed Retro 8/9 can't back up OS 9/older clients but that's not for here...) I am trying to simplify our offsite media. I was thinking that instead of Retrospect 6 backing up the OS 9 client to tape I could back up the OS 9 system to a Retrospect File locally on the G5 (plenty of local hard drive space), then have Retrospect 9 back up the G5. Or for that matter, I could create a duplicate script to make a local copy of the OS 9 system on a partition or external drive attached to the G5, then use R9 to back up that volume. Would this work? Can I have a newer retrospect client running on the Retrospect 6.1 server? Would I capture all of the files properly? Is there another strategy I could use to back up the contents of this OS 9 system with Retrospect 9? Thanks -Derek
  12. Do we have to manually clean up the Past Backups page? In the Past Backups window I have a few clients listed that I stopped backing up months ago. (new computer/employee left/etc) I have removed the source. At what point does that old backup get groomed from the Disk media set? Isn't removing the Source enough to groom the past backup? (apparantly not?) Do I need to manually choose "Remove" from the Past Backups listing? I understand that as long as non-groomable media survives those backups will and should be listed. But for my Disk media set, I expected these forgotten sources to groom unless I specifically select "Lock from grooming" from the Options tab. I guess more specifically, my question is what happens to client data after you have removed the source?
  13. Thanks. What I wasn't sure of before trying this is having the 6.3 client on the same system as 6.1 server running at the same time.
  14. Thanks for the replies. We have a "5 backup" retention policy and groom once a week. We are only keeping disaster recovery backups, not a computing history for each client! It makes sense how you describe it, that I should manually select the old clients to delete. I will just have to remember to stay on top of this. I was thinking I should wipe and start over my main backup disk annually or so to prevent fragmentation of that groomed volume, and that would also get rid of the old clients, but I can wait until I see a performance hit. I'm curious how long it will take. I have a 6TB RAID and only 2.5 TB in use at this time, so I expect it will be a while before I see any performance issues.
  15. I am trying to figure out what's wrong with my backup performance. We just migrated from 6.1 to 8.2 (multi server) last week and nightly incremental backups don't complete in a reasonable amount of time. (I tried R9 but until the bug in using backup scripts is addressed I can't use it, and I can't report if performance is any better.) I have 40 backup clients, 4 Mac OS X (2 Server) the rest Windows (3 Server). On R6, 10.4, Dual G5 PowerMac 2GB RAM backing up to AIT-5 over Gb network, we could back up (incremental) all 40 clients in about 4 hours. With R8.2.399, Dual Core Mac Pro 2.66 GHz Xeon 6GB RAM backing up to RAID 5 eSATA hard drive (local transfer speeds are really fast), it takes 15 hours to back up (incremental) the same clients. I tried backing up to a file backup on the main HD of the mac pro and saw about the same performance on a single client, so I don't think the hard drive I'm doing the backups to is the issue. Plain file transfers are very fast on the Mac Pro, so I don't think it's network connection is the issue. It seems like the majority of the time is spent preparing/comparing. Clients that took 3-5 minutes on R6 take 20-30 minutes with R8. What do I try next? Thanks -Derek
  16. derek500

    backup performance?

    Thanks. I am trying to figure out how to show the total number of files on the client. This example is a Windows client, and has about 15 GB total in use on their system, so I can't imagine millions of files, and I don't picture any Apple Metadata being involved Hundreds of thousands sure, but it's a pretty typical and basic desktop system (XP). We keep the desktop systems very simply built and under pretty tight control. I have a new suspicion, that there is some unmentioned time preparing the registry backup - Retro 6 didn't do registry backups, 8/9 does. Also, FWIW I recently switched to Retro V9, but client performance seems about the same. -Derek
  17. For reference, I have a disk media set on an eSATA attached RAID (Lacie 4BIG) device with 4.5million files and ~2.5 TB in use. The server lives on a 2007 Xeon Mac Pro with 6GB of RAM. It took 8-1/2 hours to groom 423 GB from the disk. I run the groom weekly. edit - I am still using 8.2, about to upgrade to 9 and was browsing both forums.
  18. derek500

    backup performance?

    Here is a log excerpt from Retrospect 6 on 1/12 and Retrospect 8 on 1/20 of the same backup client. This is pretty typical for what I am seeing. I did obscure a few file names and the user's name. 1/12/2012 9:46:41 PM: Connected to user-10677 - 1/12/2012 9:46:42 PM: Copying DRIVE C (C:) on user-10677… Can't read file ... Can't read file ... Can't read file ... Can't read file ... Can't read file ... Can't read file ... 1/12/2012 9:49:46 PM: Comparing DRIVE C (C:) on user-10677… File “15A57D57.TMP”: different modification date/time (set: 1/12/2012 8:09:26 PM, vol: 1/12/2012 9:49:33 PM), path: “C:Documents and Settings:All Users:Application Data:Symantec:SRTSP:SrtETmp:15A57D57.TMP”. File “9469E6FC.TMP”: different modification date/time (set: 1/12/2012 2:37:49 PM, vol: 1/12/2012 9:49:32 PM), path: “C:Documents and Settings:All Users:Application Data:Symantec:SRTSP:SrtETmp:9469E6FC.TMP”. File “{8FD90AC7-BA15-4A8B-AAF7-900635F0C677}.FDB”: miscompare at data offset 0, path: “C:Documents and Settings:user:Local Settings:Application Data:... File “SerState.dat”: different data size (set: 53,344, vol: 53,376), path: “C:Program Files:Symantec:Symantec Endpoint Protection:SerState.dat”. File “SerState.dat.bak”: different modification date/time (set: 1/12/2012 9:41:05 PM, vol: 1/12/2012 9:45:21 PM), path: “C:Program Files:Symantec:Symantec Endpoint Protection:SerState.dat.bak”. 1/12/2012 9:50:34 PM: 11 execution errors. Completed: 3325 files, 387.4 MB Performance: 611.5 MB/minute (393.8 copy, 1367.0 compare) Duration: 00:03:52 (00:02:36 idle/loading/preparing) 1/20/12 2:08:54 AM: Connected to user-10677 * Resolved container user-10677 to 1 volumes: Local Disk (C:) on user-10677 - 1/20/12 2:08:53 AM: Copying Local Disk (C:) on user-10677 *File "C:\Documents and Settings\All Users\Application Data\firebird\fb_lock_ba93232c00000f0007ca0000": can't read, error -1101 ( file/directory not found) *File "C:\Documents and Settings\All Users\Application Data\firebird\fb_lock_ba93232c00002500c6c90000": can't read, error -1101 ( file/directory not found) necoIncoming: empty stream packet, tid 19 > *File "C:\WINDOWS\system32\config\systemprofile\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat.LOG": can't read, error -1020 ( sharing violation) 1/20/12 2:16:32 AM: Snapshot stored, 65.2 MB 1/20/12 2:23:26 AM: 1 execution errors Remaining: 10 files, 11.4 MB Completed: 3479 files, 1.1 GB Performance: 140.9 MB/minute Duration: 00:14:33 (00:06:44 idle/loading/preparing)
  19. Sorry for the delay, I didn't see your reply. I have scheduled scripts run every night, backing up servers with one script, desktop clients with a different script (and different rules. They are scheduled to start 1 hour apart, so even though it takes longer than 1 hours to back up all the servers, the desktop backups begin whenever the server script has finished. Then whenever those scripts have completed, I have a 24 hr proactive proactive script (backing up laptops) that stays active until the following night when the scheduled scripts begin again. I have a few jobs that run backups on the server clients, and I want to wait until they are complete before starting their backup. Could this be done with proactive scripts? I suppose so, but I would have to change the way I think about the scripts. What happens when a system gets more data than usual, and takes longer to back up? This would throw off the timing alloted for those scripts to run, wouldn't it? Can you have multiple proactive scripts running at the same time to make use of different rules?
  20. That's good to hear. I cannot use proactive scripts for all my clients. Since upgrading from 8.2 to 9 I've been having the same problem - many of my Windows clients do not back up _sometimes_, giving the -515 Piton protocol violation error within seconds of connecting, and are skipped. It's not consistent, my clients back up some nights but not others on the same script. I had no problems at all with 8.2. Fortunately I am still in testing mode - I was just about to go 'production' with my 8.2 install when 9 came out. Hoping they had addressed some of my complaints with 8.2 I pulled it up right away, but now I'm thinking I'll just go back to 8.2 again. We desperately need to start backing up Windows 7 and 2008 clients, so I am anxious to move from Retro 6. Also, I need stability to _improve_ from version to version, not the other way around!!! I opened a support ticket about this issue just before coming to find these forum posts. Hopefully the fix is released quickly. Thanks for your update.
  21. Does anyone else back up Windows 7 clients with Mac Server 6.1? Are you able to verify the backup? On our systems I have consistent issues where I cannot compare a backup made of Windows 7 or Windows Server 2008 using Client 7.6.106 and 7.6.107. The server is Mac OS X 10.4.11 (client) with Retrospect Server 6.1.230 RDU I have this issue whether backing up to SCSI/tape, external disk backup or file backup to local HD (as a test). It happens across all 3 of my test Windows 7 systems (one server 2008 client, two W7 SP1 clients). The backup server/client stops working during the compare phase. It is never consistent which file it stops on. It either spins the beach ball on the server, or drops the server into the Net Retry window, from which it never recovers. Either is just as likely to happen. If I shut the client off, the server eventually recovers and moves on to complete the backup. I'm open to any suggestions. Does 8.2 have this issue? Thanks, -Derek
  22. Hi, I have a Mac 10.4.x PPC running Retrospect Server 6.1.126 and I was trying to add a Windows XP client with the client 7.6.107. On the server when I tried to add the client from the Backup Clients on Network window (multicast) by double-clicking the name of the client, I get an error "Can't log in, error 524 (invalid activator code)." The first time I tried this the error number was 506, but I only get error 524 now when I retry. The client is a Dell Latitude D430 which does have two NICs, one ethernet, one wireless. I just had a hard drive failure on this laptop, so replaced the hard drive, built XP from scratch and just restored the users' files from the Retrospect server (not using the retro client to push them - just to a local external hard drive on the server, which I then brought to the client machine). This was an existing client before the hard drive failure and I did reuse the prior computer name at first. I found a few messages in mailing list archives and this forum about these error numbers where the fix was to command line bind the retro client to an IP, but I can't do that when the client uses DHCP, can I? I do have a firewall blocking TCP and UDP for retrospect's port over the wireless card, so there shouldn't be any duplicate broadcast going on. In the Advanced networking pane on XP, I have the ethernet NIC moved above the wireless NIC, so that should get priority. I also switched the wireless card to Off (these Dells have an on/off switch on the side of the machine for wireless devices) and tried unintsalling/reinstalling. It seems to me that the server is remembering the previous client's name or maybe the MAC address, even though I told it to 'forget' the client. How do I make it truly 'forget' the client? I did try changing the domain/network name of the client to something else, same error. All of my reinstalls have been to uninstall from Add/Remove programs, then delete C:\Documents and Settings\All Users\Application Data\Retrospect Client\ and then restart. Install again by running the 7.6 client installer's Setup.exe from a network folder. I have many many Dell XP laptops with dual NICs just like this machine, and I've never had this problem before. This is not the first time I've had to replace a hard drive in a machine. We always build XP from scratch and only restore user's files from Retrospect. This is the first time I've used Windows Client 7.6. I was previously using the 6.0 or 7.5 client and didn't have this problem. I sort of solved my own problem - I rolled back to using the 7.5.116 installer and had no problems with that client. I'd like to know if the 7.6.108 client resolves this issue or not? Do people still have to bind the client to an IP address? Can this be done to bind to an interface instead of an IP, so I can continue to use DHCP? Thanks, -Derek
  23. Hi Russ, Thanks for responding. Our network does pass multicast and broadcast packets for Retrospect. This is all taking place on a simple LAN. Yes you can by proper setup of your DHCP server. You haven't explained your network infrastructure or your DHCP server setup. The DHCP server with MacOS X Server, and the DHCP server with most network appliances (e.g., SonicWALL, etc.) have two ways to set up lease assignments. You can either assign DHCP leases from a dynamic pool (the historic way) or you can assign DHCP leases from a static map based upon the requestor's MAC address, such that the requestor always gets a lease for the same IP for its NIC because the request is made from the same MAC address. Such a setup makes it easy to set up logging, DNS, etc., for your LAN because every IP stays the same for each client, even though the client still makes standard DHCP requests, so you can set up appropriate forward and reverse DNS zone files. Whatever. All these computers, clients and servers, are on a switched LAN. DHCP setup is a dynamic pool. These should be non-issues. If they are causing problems, then you have bigger problems with your network infrastructure because you have a loop, which will cause routing confusion. This is not a Retrospect issue, really. Retrospect never sees the MAC address. That's a network layer 1 issue. Retrospect operates at the IP level. By telling it to forget the client (Configure > Clients). Again, your network may have a loop. Yes, I did forget the client that way at the server. Several times. And I tried changing the name on the client by uninstalling, renaming the Windows name, and reinstalling. Binding to an interface solves routing problems, so that Retrospect sees the same IP on its communications with the client. If you have multiple routes from the client to Retrospect, such as can happen if you have multiple NICs that sit on different LANs, Retrospect sees that as multiple clients trying to connect to it. I still don't see how to bind to an interface specifically. I only found how to bind to an IP address. How do you bind to a specific interface? Or does that happen when you enter that command line bind to IP address? Then what happens when DHCP changes the IP address? Well, mostly you confirmed for me that my network is not a problem. Plus, when I install the 7.5 client, I have none of these problems - it works perfectly. I had to roll the computer out to my user, so I left the 7.5 client installed which is where things were at before. I don't seem to have any problems with the 7.5 client these days, I had been using the 6.0 client exclusively until very recently because any client 6.5 or newer used to interittently lock up the servers when backing up the IE cache files, but something unmentioned along the way seems to have fixed it on the server side. I'd love to know when it was fixed.
  24. Anyone know if this is addressed in Retrospect 8? It's like a backup nightmare, twice a year.
  25. Well, thanks Lennart and all those who tried to help me. The problem wasn't any of the things that we were discussing, but a preliminary warning to a disk failure. A few days after my last post in this thread, we started seeing index corruption errors from our mail server logs. We ran a 'background conditioning' on the RAID array and sure enough one of the disks turned up bad. We replaced the disk and found that the directory was hosed, so we had to temporarily relocate our mail store to a different drive, replace bad drive, rebuild the RAID array and move things back home. It took a while to complete, but since then we haven't had any -519 errors from that client. Turns out Retrospect was warning us to imminent failure. I'm surprised the SMART hard drive controllers in the Xserve RAIDs didn't alert us to the problem until we ran the conditioning. I highly recommend if you have an XServe RAID to update to the latest firmware and run the background conditioning if you are having any issues, especially if the RAID is seeing severe duty like a mail server (many many read/writes etc). It can take a few days to complete, but we've decided to run it every 6 months from now on just to stay on top of it. The conditioning can mark out blocks as bad and avoid them, even if it doesn't register enough bad blocks to fail the disk. Hope all this helps someone else with a similar problem. -Derek