Jump to content

bvaandr

Members
  • Content count

    31
  • Joined

  • Last visited

Community Reputation

1 Neutral

About bvaandr

  • Rank
    Occasional forum poster
  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. bvaandr

    Windows 8 client error -1017

    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. bvaandr

    Retrospect 8 - Windows 7 (64-bit) error -1101

    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 10.1.0.1 (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. bvaandr

    Dealing With -1101 Groom Failures

    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. bvaandr

    Error -557 ( Transaction Already Complete)

    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. bvaandr

    Error -557 ( Transaction Already Complete)

    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.
×