Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by bvaandr

  1. Snap shot building has always been slow for Windows clients. I am not very convinced that this is an issue that Support has a good answer for; probably the only way to improve performance is to reduce the amount of metadata (e,g, uncheck save system state). Even Mac version 6 was pokey with WIndows clients - this goes all the way back to G3 and G5 iMacs and continues with the Intel Mini. The likelyhood of these snapshots getting hung by system sleeps, network glitches, client computers walking off with their owners, and so forth increases greatly when the process takes too long. The results are unpredictable and Derek's report that things run OK for months and then get hung again for no apparent reason appears to support this. I too have had ones hang to the point where the job cannot be stopped from the console and either the Retrospect engine has to be stopped or the host machine restarted. The engine is an all or nothing affair, to answer Derek's question - everything stops and affected backup sets catalog rebuilds will then be required. I share his pain (and OS). Often the client is also left in a state that makes it better to restart it also; occasionally a reinstall of the client and re-pointing the host at what is then a new client also becomes necessary. So anyway, to respond to Derek's BTW, perhaps slow snapshots and the never-ending ones are related sufficiently that this thread might benefit from discussing both.
  2. Thelander - what you say is absolutely correct - it does have to get metadata from every file. Total disk space used on the client is 45 GB or so and it has typical number of files - maybe 600K or so. The disk is an SSD - very fast - fast enough for a full Symantec SEP antivirus scan to run in less than an hour. The metadata for the Windows machines seems to be much harder for the Mac version of Retrospect to gather than what it it has to do for a much larger number of files on a much slower Powerbook G4 client; the whole backup and snapshot is done in 15 minutes, which is the kind of performance you might hope for. I do not have a good comparison for the Windows version - it takes a fair amount of time building snapshots for its Windows clients also, although it is not as long. My Windows setup is on a stronger machine than the dual core Mini. But despite the host machine's performance power differing, my observation appear to indicate something about the nature of Windows metadata when you are trying to save system state etc. - it seems to be harder to do with Windows clients than with Mac clients. This is also borne out when looking at what it takes to service an older Gen 2 Power Mac client with the Windows v 8.x multi server host - snapshots happen very quickly - much faster than for Windows 7 clients.
  3. This happens every time. Client is awake and has been up all night prior to the backup running at 4:30 am. No Windows updates are running, since those are set to notify and require me to start their installation by hand - just precisely because I do not want that going on when other things are supposed to be happening. Client is running on an SSD, though that probably has not much to do with it. It appears to be a known issue for clients with EFI motherboards. like this Lenovo T530 with the latest BIOS update installed. See http://kb.retrospect.com/articles/en_US/Retrospect_Article/ASR-Writer
  4. Interesting verification of something I just noticed on the Windows multi-server version. When running just one backup set verification job on a 1.8 TB compressed backup set, the first core is maxed out at 100% usage while the other ones are barely ticking over. Even the 8.2 beta offers no apparent improvement, so far as multi-threading goes. This may be a big reason for slow backups, verifications, and so on. Zip files that are being backed up are especially slow, since the Retrospect compression routine apparently still tries to compress them. I have noted in many different scenarios and operating systems that any algorithm that tries to compress already compressed files seem to try to do a lot of work for nothing. So, just as an example, verification rates for zips are 3 GB/min on my system, whereas binaries go 6 to 8 times as fast. The 8.2 beta seems to have significantly improved speed over its predecessor, but it still appears that hardware level or OS level compression may be the answer, if time and patience are lacking.
  5. The pre-release version appears to resolve the problem so far - no more -2241 and -1101 errors, once you rebuild your catalog with the 8.2 beta. So you have 3 choices - wait, downgrade to 7.7, or write a script to rebuild your catalog early and often. The update can't happen fast enough! And while they are at it, perhaps the Mac version can be cured of this disease as well.
  6. This issue continues to confound with the Mac version 10.1 running under Snow Leopard trying to back up a brand new windows 7 x64 client with a snappy Core i5 using 8 GB ram and with the latest Windows client install available. A 5 GB backup for 1415 files copies in ~15 minutes over a wireless n - which is slow but tolerable. But the snapshot build takes another 40 minutes - and I have seen it take twice as long. Media verification takes about 60 seconds. Total time for the 5 GB is 60 minutes (and sometimes as long as 100 minutes). That is an effective transfer rate of 1.4 MB/sec at best. That is 83 MB/min, compared to the performance metric Retrospect proudly shows for the job, which is a confabulated 458 MB/min that neglects the time for the snapshot build entirely. I have a 22 year old Mac IIci that has a 2 MB/sec scsi port that is faster than that. If Retrospect really is not capable of anything better, perhaps the company might consider relaxing the number of threads that the normal desktop versions can run at once, so that it can concurrently wait on the 5 Windozer laptops I am servicing and the poor Mini does not spend 5 hours+ per day running these backups. The official concurrent thread limit for the Retrospec program is only one. On the Retrospect for windows (v7) that I also have, that cannot be changed. On the Mac you can increase it, but next time Retrospect launches it is back to one thread. Keeping the Retrospect program running after increasing the number of threads to the number you need to run all your backups concurrently seems to be the only available workaround for the abysmal snapshot build performance I see. Another possibility is that antivirus software is somehow running interference. Symantec End Point Protection and the like can slow network transfers from WIndows down to a crawl. Has anyone else tried any experiments with and without AV enabled?
  7. Despite the fact that this thread is 5 years old, the multiserver v 8.1 for Windows that I have still gets the catalog corruption after grooming in exactly the same manner as described above. My catalog files are not on the backup set volume and a Windows defrag is scheduled weekly on the C drive where the catalogs are sitting - so I do not think fragmentation is the issue. Still, catalog files are hosed for backup sets with amazing regularity, especially when the backup sets get to the ~300 GB size range or larger. In fact, it is not so much the size of the backup set that matters as it is the size of the catalog file itself. The sets that I have the most trouble with are also the ones with the largest catalog files; the largest one has 1 GB+ file size. Even small amounts of backed up data (e.g. 45 GB) gives trouble if the file count is so high (I have a bazillion 500 byte data files) that the catalog file easily gets to the 400 MB or larger size range. This behaviour almost suggests that Retrospect is running out of memory or just not getting itself enough of it to write large catalog files that are valid after grooming. The catalog files often still point to rdb files that have been removed in the grooming. SO subsequent attempts to groom or even verify fail miserably. So then the catalog file has to be rebuilt yet again. This is an issue not only with the Windows version but with the Mac version as well.
  8. It is it slow. 10 GB of data from a WIndows client can take 90 minutes, most of it spent building the snapshot - ridiculous. Version 8 was even worse. The grooming is so seriously messed up, that feature is almost useless. Endless problems with corrupt catalogs, failed verifications, lost data, failed copies, cryptic error messages, and no rhyme or reason to it. Automatic scripts refuse to run under an assigned user name - support has no answers and the documentation just says it should work - dream on. I have used Retrospect faithfully for over 20 years - I think I may still have a version 2 lying around somewhere. I have spent thousands of dollars on this software, but my backup drives and I can't take any more of this abuse. The Windows Multiserver version has the same problems - possibly worse. My support ticket has been escalated to engineering. I am not holding my breath. This has been going on for months and months. So much for the maintenance agreement. Good old Mac version 6 ran for years and years with not a care or an error - I know - it didn't even do grooming on compressed sets - life was good. The Mac OS (or Windows) has not gotten any simpler - but if anyone thinks Retrospect 10 is supposed to improve our digital life and painlessly help guard against loss of ever increasing amounts of data, think again. It really is a heartbreak. The company is finally in the hands of the employees, some of whom have worked on this product for longer than I have been a user, and the software I used to swear by is now more often than not the object of a different kind of swearing. What a bummer.
  9. This mystery message also shows up for certain backuo sets I have for the Windows multiserver version. I found an ancient post, dated 1999 and harking back to the days of yore and Retros[pec 6.x that found that file names ending in _1 on the source would trip this error. It's a really slow link: http://archive.macfixitforums.com/ubbthreads.php/topics/331814 So it may be a nothing error message and probably a consistency checking error. I guess one way to find out iits true effect is to attempt a recovery, since there has been no other response.
  10. Mac Version (266) Errror occurs backing up a Windows 8 (64-Pro) client - version 8.1.0 (266) From Log: Normal backup using Lenovo_bv_bu_scr at 5/6/13 (Activity Thread 1) To Backup Set LenovoBLV_bu... T-7: MapError: unknown Windows error -1,017 T-7: VssWAddComponentToSnapshot: UGetComponentInfo failed., osErr -1017, error -1001 - 5/6/13 4:30:00 AM: Copying Windows8_OS (C:) on BLVLenovo Writer "ASR Writer" backup failed, error -1001 ( unknown Windows OS error). 5/6/13 5:16:55 AM: Snapshot stored, 230.1 MB 5/6/13 5:17:14 AM: Execution completed successfully Completed: 3644 files, 4.2 GB, with 42% compression Performance: 416.8 MB/minute Duration: 00:47:14 (00:36:52 idle/loading/preparing) Retrospect CLient Control Panel on the windows laptop shows no events - i.e. it falsely indicates no backups occurred. Laptop was plugged in and does not go to sleep or hibernate while that is the case. On the Mac Retrospect program's SOurces panel, the client still showed to be busy and the client preferences could not be opened, even after refresh. Once Retrospect was closed and restarted, then client showed up correctly. The only other place on the forums that I have found anything like this error posted is for the Windows MultiServer version.
  11. If the snap shot is really building on the client, then it is a client issue and most likely how it is being controlled by the Mac host, which seems to be different from when it is being controlled by a Windows host. I have problem with a smallish XP SP3 client (30-40 GB) that also takes a whole hour to build a snap shot, even when the copy is only a few GB. The client machine (old Pentium M) never really gets a kick during snap shot building; its CPU is lumping along at its slowest speed under Speedstep (monitored by CPUZ) and the task manager shows 0% of the CPU allocated to the retroclient. In other words, the client program never makes sufficient demand for CPU cycles to speed this up. Another thing that makes me wonder if the speed limitation comes from the snap shot really being built on the client and not something to do with the Mac is the curious fact that much larger backups I run with Retrospect for Windows at work get the WIndows client (same version) snap shots built in 10-15 minutes. Note all of my scripts are set to save permissions, which wll definitely slow down the snapshot process, but is needed if you ever need to do a bare metal recovery. This again points to the Mac host as the problem. So maybe the client is trying to build the snap shot, but has trouble communicating with a MAc host during the process.
  12. Well - it appears I am not the only one and this is not just a Mac issue (Google grooming misery). My Retrospect for Windows Pro also has the -1101 error (file directory not found) after the backup set filled up and it tried to use the Retrospect defined policy for grooming. This particular backup set is for a single machine (Dell Win 7 64 with 8 GB Ram), single user with a local Firewire drive (MyBook). Catalog file is on the backup disk with the backup set, but there is plenty of room there - I have set the backup set size to leave at least 200 GB free on the drive. Rebuilding (recreating) catalog file took 4 hours for a 300 GB backup set , but was successful, according to log. However, subsequent groom ran all 931 segments - almost to completion, but then logged as failed (error -2242 (catalog file duplicated or ambiguous). So Retrospect cannot back up to it and asks me to rebuild it again. I have not had this issue with smaller backup sets when they fill up - perhaps it is a memory issue.
  13. The new version scripts are running on Windows 7 machines, but still appear to fail on Windows Vista 32. On Vista 32 machines the initial file copy works, but now I am getting error -519 (network error) when it tries to verify. Windows application logs on the Windows 7 machine and on the Vista machines now list application error 1, for which the description is: The description for Event ID 1 from source Retrospect cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. My guess is all is still not well with the new version. And no - I am not a Newbie - I have used Retrospect since the early nineties.
  14. I have had a host of these problems (-557 error, T36, T44, map error, WMI repository, unknown windows error, etc) on the Vista 32 bit box. With Vista 32 clients, nothing works using Retrospect 7.7.533. But with a Win 7 64 client, it's fine. Version 7.7.533 also seems to run fine on my Win 7-64 box with win 7-64 clients. But I have to agree with some of the other posts - the .533 version is seriously flawed and the older .341 version should be left on the update server for now. $70 for a download, really now! Sounds about as reasonable Continuous Backup Professional, announced May 2008, bought for $89 in June 2009, and discontinued within a year with Retrospect's sale to Roxio. So why is it that I can download umpteen versions of NVIDIA drivers for my graphics card and we can't download older versions of a supposedly "Professional" product from Roxio? I guess we can only be grateful for Robin Mayoff's heads up. I just wonder how the next 17 years are going to play out.
  15. I have been running Retrospect for WIndows 7.7.208 from an XP SP2 host, backing up several file share directories on a Vista SP1 64 bit client v 7.7.106. I have 4 scripts directed at 4 different directories on the same client's drive. The client system WIndows Application logs consistently show 4 VSS (ID 8194) errors within about 1 minute of the scheduled starting times for each script. The Retrospect log shows no errors and the 4 errors in the client system log are always followed by a event ID 8224 showing VSS service shutting down due to idle time out. The same pattern of VSS errors (but five of them instead of four) also shows up on another Vista 32 bit client on completely different network and being backed up by a completely different copy of Retrospect 7.7.208 running on a Vista 32 bit host. Script is running with admin privileges on the host and with a user ID that has admin privileges on the client machine also. Again, no Retrospect errors are generated. It looks like last post by Mayoff saying a fix was on the way for the Active Directory bug presumably responsible was last August. Seems like that most likely predates the 7.7.208 version, although update history information not easy to find on EMC site. SO question is - was it fixed or are my VSS errors evidence of a new bug? Timing of errors are definitely associated with Retrospect backing up clients. There are no VSS errors showing up on the host machine when running its own local backup. I have just updated to 7.7.235. Will see if errors continue. B
  16. I have similar issue: error -505 on one networked client out of 4. Attempts to run the script using this client as a source manually give same error. Deletion of client and attempt to add in the same client gives same error: "Sorry, couldn't add backup client, error -505 (backup client reserved)" Can still access client with windows explorer using normal administrator's default share. Host and client OS: Win XP SP2 Host Retrospect 7.6 for Windows Professional v 7.6.123 Host driver/hotfix v Client v I have not had chance yet to try locally uninstalling and reinstalling client software on remote computer
  17. Retrospect Version 7.6.123 running on Dell XP Pro with a third party eSATA RAID card (Silicon Image SATARAID5 driver - WD drive is a passthrough device - RAID functionality not active). A local, scripted backup from an auxiliary SATA internal drive to an eSATA drive hangs right at completion of verification. The Activity window indicates "disconnecting", but Retrospect never completes the operation. The result is that other backups queed can not run. Only a user termination will stop the hang and resume automated backups. There are no error messages. Other backups, both local and network clients writing to the same eSATA drive, complete normally.
  18. The dreaded assertion check at "elem16.c-687" error is back again, after a 20 month absence. Maybe a clue or just a coincidence: an XP SP2 windozer on my network was updated to .Net 3.0, patched, and got a new, active share on the network yesterday. Maybe it's just a coincidence, but the assertion check failure occurred this morning, while trying to back the another XP on the same network. Maybe the updated computer thinks it needs to horn in on the discussion between the mac server and the other XP client. Those backups had been running every other night - no problem.
  19. The C drive on the backup computer has 101 GB free. The external firewire backup drive has 38 GB free. The client computer only has about 60 GB free out of an 80 GB C drive that is being backed up. So there appears to be room for everything. Attempts to repair the catalog for this backup also fail on the same error -808 message, with the system stating that the catalog could not be compressed. Apparently the catalog was corrupted beyond help. Attempt to rebuild the catalog file (replacing the old one) from the backup files was successful, all prior snapshots were recovered, and subsequent backups run OK (after the script was redirected to what became an effectively new backup set).
  20. A WIn XP SP2 machine retrospect v 7.6.11 pro attempting to make Client backups of a Win XP SP2 machine running latest client software is reporting the following error. Error - 808 (key/refnum search failed) This appears on two lines -one saying "Trouble matching [machine and disk names]" and the second one saying "Cannot compress Catalog file for back up set [back up set name]". Haven't tried rebuilding catalog file yet, but will unless maybe somebody else has any other ideas.
  21. The encrypted grooming feature is a plus - I gotta say. A lot of the improvements , however, make more of a difference for larger scale users then myself - that and the poor speed performance of the earlier version contribute to the perception of a "bug fix." The automatic updates remains a no go - however the rdu e-mail newsletter does help for those of us stuck behind highly secure firewalls. So far as rhwalker's unkind comment goes - that is why I invest in other backup methods, along with the considerable number of licenses I hold for Retrospect - some of them from well before he made his first post here. Support costs indeed - so do critical software features that do not work.
  22. More information on the "Assertion check at "elem16.c-687" failure error: 1. After updating the Retrospect software to the current v. 6.1.138 (and also the client application on the WIndows computer to v. 7.5.116 - which was on the .dmg along with the update), the error and failure to back up still presented itself upon trying to back up a Windows XP client computer over the wirelesss network. 2. The same error also came up when "visiting Configure->Clients->YourClient->Configure(button)->Configure(tab)" as noted in earlier posts. 3. The error was avoided by using the work around put up by the original poster (four years ago!), which is to "forget" the client and then reconnect. After that I had to respecify the source drive on the client computer before the backup would run. All this still allowed using the current back up set. 4. The root\Library\Preferences\Retrospect\Retro.Config (6.0) file modification date was updated after the now successful incremental backup completed. So the upshot is that the Retrospect version, current as recently as December 2006 (according to its post date on the Retrospect update page), had not resolved my getting this error, which was reported back in 2003. That appears to be supported in earlier posts in March 2007 by rhwalker, who also kindly responded to my earlier post. All the behaviour I see matches earlier posts. All this does not suggest much about whether the new version has fixed the error so it does not come up again- but time will tell. One other question does come up - why does the Retrospect 6.138.1 update for Macintosh include the Windows client 7.5.116 (the same version number as is listed under clients for the Windows Retrospect Professional application) when the Retrospect update page Macintosh offerings still only lists separately the Client version 7.0.112? Doesn't make a whole lot of sense.
  23. Greetings Dave - thanks for responses. 1. Retrospect update 6.1.138 has been found. Thanks for the heads up. Note Mac v 6.1 does not support automatic updates (unlike Windows version - although I haven't gotten it to actually work - work place firewall issues, I think). I guess I need to check into getting to alert me when Mac version updates are available. 2. Apparently bits do change by themselves, especially when they are in preference files - I saw the post you mention and several other that suggest replacing the Retrospect preference file - including the very first one in this thread (effectively). Question is - if this is the problem, why is the preference file getting messed up? 3. The Retrospect version info (complete - for when this problem presented) is vers. 6.1.126, device access vers. 1.0.107, driver update ver. 4. My error comes up when I try to run a backup of a Windows client. That's why I mentioned that the backups fail. If I get any more info, I'll post it. Best regards.
  24. Hosed again - rebuilding catalogue file does not help Get Trouble in Retrospect Internal consistency check failed: Assertion check at "elem16.c-687" same as before. Any ideas?
  • Create New...