Jump to content

XOR42

Members
  • Content count

    41
  • Joined

  • Last visited

Community Reputation

0 Neutral

About XOR42

  • Rank
    Occasional Forum Poster
  1. Quote: Vista introduced Service Hardening. The Retrospect Launcher Service cannot run as a specific user any longer. The Retrospect UI and Engine will need to be separated, and this is a major project. We do plan on making these changes in a future release. In the meantime, you can put a shortcut to Retrospect.exe in your 'Startup Items' folder which will launch Retrospect on boot. That will allow Retrospect to run in your user session when scripts run. Thanks for the response and suggestion. 1. As knoweldge of the Ring 0 issue is well over 1 year old and that you intimate it will be at least another 6+ months to recode, this suggests EMC is having trouble coding it and will have taken at least 18 months! I can only surmise there are internal staffing problems or there are project mangement resource issues with all their acquisitions. RP is small potatos in their product suite. They need a strong arm to get this problem resolved and on track. By any meaure, 18 months is unacceptable and a very serious faux pas. 2. RP will NOT auto-run in Start up - it requires user intervention. You have to be at the keyboard to approve the UAC prompt about running low level service. Thus, auto-boot systems will fail to load RP. If Windows autoupdate is enabled, then RP will fail to re-start every time there is an update. 3. EMC needs to freak out yesterday, jump up and down, give this a priority 1, create a task force, apologize to us masochistic loyalists, and issue a high level sincere statement about their remediation plans. Thanks.
  2. This situation is becoming insulting to some of us Retro users. EMC needs to acknowledge that either Retro does not adequately work under Vista or that they intend to kill the product from Vista onwards. It's been about a full year since EMC has the necessary info to recode the product. We pay a premium for Retro to ensure that they do - and, well, they haven't! As of the latest 379 release - which had no visible improvement over 370 and seems to run even worse for me - Retro has the following severe problems (among others). 1. When run as designed, by schedule a. It runs invisibly so it cannot be monitored. b. Operator cannot access the product c. Any operational error dialogs are HIDDEN! d. Program can sit for days, locked up, without us knowing 2. Attempting to run manually: a. As Retro is silent and runs 24/7, we cannot start manually because Retro will forcibly crash the BG process. b. Any crash or hiccup of a Retro run destroys the backup integrity. c. You cannot automate manual operation via on Start Up as it fails with Access Security Prompt 3. "Assert Failure" - When 379 runs in BG and wants to pop an error or warning dialog, nothing happens, it sits and hangs in silence. So, after 2-3 days or suspicious silence, you run it manually. It says running already so you are forced to terminate the BG process. It then starts in FG but we get a weird "Assert Failure" messages from Vista. After several confirmations Vista switches to lower res mode and shows the original Retro warning, which was something simple like "drive out of space". But, since this occurred 3 days ago and we just axed its execution to get to interface, we just trashed the back up. Upon re-running Retro, adding salt to the wound, we get another Assert Failure messages that eventually leads us to a Retro error that tells us Retro crashed. Yeah, right, because it just forced us to crash it. Not nice. 4. Help system unstable! The critically important Retro help system has been broken for years and seemed so in the last 379 version. HOWEVER, it miraculously started working again. Hitherto, Help would fail to start saying it can't find the help (older versions) or it would show the index but fail to find the text content (latest version). Only when you started Retro from the system tray icon did it show the help - or vice versa? It now seems to be working when running from Windows icon but only after multiple crashes as per above. EMC needs to acknowledge this long time bug and explain if, when, and how it is was fixed -- if at all. To wit: Issue with help when Retro is run from system tray icon versus Window icon. There are many other usability issues and operational deficiencies but there's no sense getting into them until the above major issues are dealt with. Here's a few summarized: 1. Auto-groom has never worked for us. Retro ALWAYS runs out of space because it seems to need a LOT of extra space to groom. So it ALWAYS underestimates the space needed to groom then runs our of it. Our backup source has only 300 Gb. Our back up drive 500 GB. Yet with groom sets=1, it still run sout of space. We've added 5, 10, 20, and 40 extra GB but it just keeps running short. 2. Retro backup sets cannot be trimmed, matched, rebuilt, or otherwise checked for 100% integrity. 3. Reto back up sets continue to grow in size because Retro does not seem to eliminate some files that are no longer on the source. Our current backup of our 300 GB artea is now 450 GB though we only asked to keep 1 generation. 4. Catalog rebuild does not rebuild catalog. Long-known and well-documented issue. ... Ad nauseum ... If EMC continues to remain silent on all these major issues and the lack of acceptable Vista support, it cannot be said that there is a Vista version nor can Retro be recommended as the professional back up solution it claims to be. This is not shareware nor a game. It is a product that is critical to daily operations of a computing environment - regardless of whether it is for SMB, SOHO, or Home. I've never tried so hard to be loyal and gotten so little in return. After having successfully led countless s/w projects, I am aghast over how the current product has been allowed to break so badly and, beyond that, has had so little functional improvement. I'm only a few miles from their HQ if they need help. Parting suggestions: 1. Review Retro operation closely and collect ALL known issues. 2. Publish a bug list ASAP. It show responsibility, ethics, and build loyalty. 3. Accept and acknowledge bugs ASAP from customers. 4. Affirm that Retro is Pro product designed for utmost reliability and auto operation. 5. Read point 3 then add all problems to bug list that prevent Retro living up to that. 6. Make sincere statement about their design and support directions for Retro. Thank you.
  3. Quote: On Vista, Retrospect can only run as the currently logged in user (Vista is all about security ;} ) Anyone who really needs to run Retrospect under a specific user account should not be running Retrospect on Vista. We note this in the Read Me With all due respect for your valued participation, that does not answer the siginificant problem that makes RP effectively incompatible with Vista. We do not care what account RP runs under. We need to see Retrospect when it runs a scheduled operation. As it stands, it runs invisibly if triggered by schedule and remains in backgrourd invisibly. This is completely unaccaptable. As we users all know, RP requires constant hand holding, supervision, tons of head scratching, and tweaking to make it work. It is impossible to support its operation without having access to the GUI during its execution. We HAVE to be able to see it work to check on it and look out for the many problems that routinely occur with all but the simplest backups. Furthermore, complex backups can take many hours. Since it runs invisibly, it forces us to cancel the current execution to bring up a visible GUI to see what is going on. However, if it is still running a backup, we will essentially DESTROY the backup since it would be a forced termination. And we all know that RP blows its backups when you do that. As it stands, we cannot run the RP GUI unless we wait many hours after what we think was the last execution, praying to God, it is really finished before we have to force the exit of the invisible current execution. Such behavior cannot be considered Vista compatible. At best, it is "functionally limited" or "partially usable". Ergo, we can no longer safely use RP for our Vista backups with any certainty or control. That is not what this customer expects and paid for. Lastly, since RP requires so much of our time, energy, and money to keep it running, I think it behooves EMS to be much more forthcoming with acknoweldgement of these major problems and a sincere response as to their plans and timetable to address them. If this is not in their plans they need to tell us so we can start seeking alternative solutions. Backups are mission critical and sensitive issues. Granted, the interaction and answers we seek may occur with expensive support packages. If that is, indeed, the case, then it seems unethical to not publish and share such findings when they have been paid for by those with a budget. Q1: Does EMC plan to contunue the RP line and fully support Vista? They certainly had enough time. Decent Vista betas have been available for 2 years! Q2: When will RP be as functional with Vista as with XP and what steps is EMC taking? Q3: When is the FREE update planned to be available with those fixes? Thank you for your time.
  4. As previously noted, I am using Retro 7-5-320 with password but no encryption. My backup last night just failed on the 3rd (and by far the largest partition) of the three that I back up. It hung hard while about 50% through verifying the 3rd partition. After 8 hours of no activity, I axed the process. Is this the problem for which 320 was pulled? If so ... 1. It looks like passwords w/o explicit encryption are, indeed, subject to the bug. 2. When the 320 bug arises, does that mean the entire backup needs to be trashed? 3. If 1 is true, the do I need to recycle (ie, delete) and recreate my shole backup scratch? It contains a backup of my laptop's business files that is in repair and there is no other copy of the data!!!!!! Argh!
  5. Thanks. Bbut I was more specifically asking: Is a Backup Set set with a Password but without specific Encryption, also considered "encrypted" and subject to this bug? I ask this because since you cannot access a passworded back up set without a password, it could be viewed by some as "encrypted". This is very important since it determines if our entire back up is now trash! This encryption issue needs to be emailed IMMEDIATELY to all Retro owners since the problem destroys all their backups!!!!!! I did not see such a bulletin! Thanks.
  6. So, if there are backup & encryption bugs with update 7.5.320, what are those of us to do who promptly upgraded to 320 and who also rely on encrypted backup sets? Do the 320 problems affect passworded sets that are not specifically encrypted? Will the 320 problems corrupt our current backups made with 320 so that they will NOT be correctly read by earlier (or later) versions should we be able to regress to an earlier version or use a later one in the future? Pulling a bugged version is a major action that requires immediate bulletins and advice from the vendor as to what to do with the damage they can create - especially when dealing with a security product!!! I have not received any! Has anyone else?
  7. XOR42

    I'm not having much luck here...

    Quote: I installed the latest version of the server I had (6.5.350) on A, and then installed the latest client I had on B. When I attempted to add A) as a source, Retrospect gave me an error -530, something about not finding the client I'm just another user who doesn't drop by too often but let me at least commisserate that Retrospect is confusing, difficult to use, and far from perfected - so don't feel too bad. Also, if you know well the following, then just ignore it. You were a little unclear as to exactly where you had your problem. During installation, you install the server and client s/w on the server and client machines, respectively. You then use the main Retrospect program's Clients tab to find and define your client. You then create a backup "set" whose "Source" field specifies volumes/folders to backup from the local machine or on a client you previously set up with the Clients tabs. So, where in the above process did you get the client error and had you successfully completed all the previous steps. Re your versions, some here would not recommend upgrading a registered version to the trial. I suggest a complete uninstall of all versions and reinstall just the version (older registered or newer trial) that you want to use or test. Don't forget to note your legal copy's license number, ha! Hope that helps.
  8. I must be looking in all the wrong places. I have yet to find a common repository of all product patches and updates with a comprehen list of revisions. I did see this only for a major update at EMC but, even then, it only new features with the "bugs fixed" list being all of one line! Eg, I don't see any list of all the fixes in the recent 7.5 Client patch. It was only via messages form others in this conference that it was "suggested" that it might fix the problem. I cannot find any detailed official bug fix list at the EMC site for example. I find this to be a very serious omission since the client speed problem effectively disabled client backups. Retro software maintenance is much more difficult than it needs to be. EMC needs to have a comprehensive update/patch info library at their download location. Each and every patch or update needs to the following items fully explained in clear and a consistent manner: - applicable product line / OS - applicable product version - short summary description of update/patch - severity of need to implement (optional, suggested, critical) - update/fix file name - update/fix type (upgrade, patch, plugon in, etc) - update/fix revision - update/fix release date - very detailed list of all feature and ALL bug fixs - detailed installation instructions and implications for each item Heck, we do this for freeware. I'd expect far more for a professional product from a great company that has the foresight to be located near me <laugh>.
  9. Quote: Next time Retro unexpectedly quits and forgets a new member, run a catalog update by going to Tools>Repair>Update existing catalog file. That would be great if it worked. However, several of us have found that if Retro crashes (as it always does if it has any problem accessing a backup set such as when a USB drive is offline and requires a Task Manager hard termination), it often leaves partial or zero length files in the backup set which then causes successive back ups to fail with a file access error. But it's certainly worth a try. Just don't expect much since recatalog doesn't do much with the back up set. We're still waiting for a backup set verification program with a true backup rebuild which would also include a proper recatalog. Don't hold you breath!
  10. XOR42

    Error 106- can't overwrite

    Had same problem. See my thread: http://forums.dantz.com/ubbthreads/showflat.php?Cat=&Board=professional&Number=70756&Forum=f24&Words=can%27t%20overwrite&Searchpage=0&Limit=25&Main=70493&Search=true&where=bodysub&Name=&daterange=1&newerval=1&newertype=y&olderval=&oldertype=&bodyprev=#Post70756 Bottom Line: Retro is a little sloppy when it crashes. It may leave behind an empty or partial RDB file that was not yet cataloged prior to the crash so it barfs when it goes to use the same numbered file again on a subsequent backup run. Since the Catalog Rebuild doesn't recatalog, let alone clean backups, it won't remove the trashed RDB files. In my case it was the highest numbered RDB file in the back up directory. It was zero length so I deleted it and backups then proceeded. Checck your logs and you will see the exact file name that could not be overwritten. However, this also means you can no longer rely on the integrity of the backup since Retro does not have a back up verification function. If possible, you should trash your backup and create a whole new one. If you can't get the above URL to work, search for "Can't Overwrite". Be sure to use the quotes and set the max time frame (1 year). My thread is the one previous to yours. Good luck.
  11. Saga Continues, Part III, Cause of Problem Found! After copious head scratching, log peering, and directory snooping, we discovered what was causing the -106 error discussed in this thread. It turns out that when Retro hangs, as it can easily do, the last RDB file it might have been creating at the time of the crash may be left as an incomplete or zero-length file that was not yet added to the catalog. As such, each subsequent run of Retro attempts to use this next sequentially numbered file but freaks out when it finds it already exists and issues an "cannot overwrite error". Making matters worse is that neither a catalog rebuild, a catalog rebuild-from-scratch, nor a forced or scheduled groom will eleviate the condition thus making it impossible to recover without file fondling. Our clue to the above was that one of the logs mentioned the file that could not be overwritten, that is was zero-length, and that is was the highest sequential number in the RDB file sequence. So, with breath held, we deleted said file and, voila, backups resumed without "further" errors. However, since Retro lacks a way to verify a back up set, we will soon have to trash the back up we have and start over. But we can at least run for the moment. Suggestion to EMC Design Team: You desperately need a back up integrity checker. Replace the current Catalog Rebuild with a complete Integrity Check Function that would literally walk through each and every RDB file, verify it checksums, eliminate corrupt segments, report on its findings in an easy to read report, produce an updated catalog, and leave the back up set directory in a clean state ready to add any missing files to it on the next run. One should be able to schedule this function as it would naturally take a lengthy time to execute. It could thus run every so often to produce a report the user could review the morning after. This integrity function might have 2 or more levels of depth and varying levels of capability based on the type of back up set. For example, based on the capablities of the media, a disk based backup would have the most rebuild capability whilst a tape library might have the least. The simplest level would be a check of RDB file presence and structure; the next might be a catalog review and rebuild; and the deepest level would be a complete back up set verification. The report might also include: Options used for this integrity run. RDB files expected but not found in back up set. RDB files found but NOT expected in back up set. Source files found in unexpected RDB files (above). Source files expected but not found in RDB files. Files in backup set not in source [optional] Files in source not in backup set [optional] Actions performed by checker (such as rebuilds). Summary of integrity after the run. Now that would be solid, cool, and, most importantly, would allow Retro to rebuild after almost any error, allowing it to provide and sustain a continuous and robust backup function.
  12. Quote: I have had Retrospect automatically backing up my system volume for over a year now (still running 7.0) to another internal drive with no errors, no new backup sets, no intervention on my part at all. That's very good to here. But what are your metrics? They define the issues. I am backing up about 350 GB (1+ million files) to a 500 GB Maxtor drive. As such, default backup set parms cannot be used. Instead, grooming has to be forced to "at most 1 generation". More importantly, how often does your setup seem to force an auto-groom? My setup runs out of space about every 8 weeks, thus forcing an auto-groom which always failed. With v7.5, I have managed to get a manually scheduled groom to work which I set for 1/week. It always failed in v7.0 Quote: what exactly do you think Retrospect is doing when it is rebuilding the catalog? I can assure you that it is nowhere implied that Retrospect can fix damaged data. Oh no! I never thought that. I was only referring to that fact that any interpretation of a catalog rebuild would assume that it rebuilds the catalog. By rebuild, that means, of course, to fix or literally rebuild! To perform a catalog rebuild, any decent software design would scan the back up data set, look for what is there, skip what is not or what is damaged, and build a completely new catalog that will not generate an further errors. As part of that process, it would naturally also have to retire, eliminate, and/or delete missing or damaged items within the back up. When the rebuld is done, the catalog reflects ONLY what is valid and available and references nothing else since all else was skipped or removed. This is software 101. However, as far as we can tell, Retro does not implement much of that logic. It seems to leave references to bad or missing data and, thus, propogates and amplifies error conditions upon subsequent backups. That was my point. A Retro catalog rebuild does NOT completely rebuild the catalog. Stranger, it is not complete even when there is no original catalog. This further suggests that the catalog is not as independent as it might be. That is, it seems like the back up set data structure contains self-referential information (for example, a linked list -- which is not that uncommon). Thats fine, however, where the existing logic seems to fail is that any catalog type information embedded within the back up set files (like linked lists) does not seem to be updated during a catalog rebuild and thus seems to propogate a data synchronization problem. That's all I meant. The bottom line remains the same. Once there is a catalog (or most any other) error, there seems to be no recourse other than to trash and redo the entire back up to ensure you have a valid copy. And since I was frequently experiencing such problems due to the aforementioned grooming, catalog rebuild, and other errors, I would have to trash and redo my back up every 8 weeks or so. Perhaps my biggest disappointment is that many of these fatal errors go unnoticed and require the end-user to religiously investigate their logs every day or week. It is definitely not the set-and-forget product it is suggested to be. Lastly, the lack of a back set verification and/or rebuild function is surprising. One would think it was elementary to have an integrity function in a product designed to ensure data integrity. We'd be happy to provide some design pointers, but I'm sure EMC has suitable nerds on their staff. It's basic logic that, though timeless, we coded at least 30 years ago. See my next message about latest on my saga which notes another pesky error.
  13. Saga Continues, Part II It's now my 4th day without a backup. Same as before. Error pop up reads: | Trouble Writing Media | Error -106 (Data Overwrite Attempt) Clicking OK just re-pops the errors. Main display shows: | Backing Up (backup set name): Updating Catalog File | Source: (drive name), 1 of 3 | Destination (back up set name) | (long hex name).sdf As noted previously, the catalog was recataloged twice (the last after renaming the old one to force a complete rebuild) without any disk errors. Only the erroneous warning that I chose to skip a series of backup segment files (I did not). Each time Retro stops at the same point with the same progress indication. So, is it failing trying to update the catalog or writing to the backup set? I've also checked the ownership of the catalog and back set files. they are all owned by me or Administrators just as they all were in previously successful runs. There are 2 different owers based on whether Retro starts in scheduled mode (Administrators) or is manually invoked (me). Both are admin and caused no previous problems. I am getting desparate: Do I have to destroy my 300 GB of backup for the 5th time? It seems I average about 1 backup corruption/loss every 2 months. Is there anyone backing up 300+ GB to a single 500 GB drive on a daily basis who has a clean back up with these problems? That is, one who's checked their back to be sure it's valid and whose backup has survived the occasional system glitch or hang up whilst using their workstation for 8-16 hours per day? Are we to assume by the lack of response that Retro has no way to "really" rebuild catalogs and to fix backups that are broken when such errors are encountered and, when they do, you have to trash your entire backup?
  14. Quote: Is anyone with this problem using the Encrypting File System (EFS)? Followup: Re bad comparescomment being long standing bug through v7.5 I am only using plain NTFS, my backupss are set to use a password, but NO extra option of encryption is specified. In many places, Retro refers to a backup with a just a password as encrypted but in others, refers to separately specified encryption as "encrypted". So, regardless of Retro's confusion over terminlolgy, I also get the false compare errors on media files. I back up about 600,000 files. Of those, 5,000 are audio (mp3, wma, etc) files and about 250,000 (jpg, gif, etc) are images. With that complement, I get 0-5 compare errors, averaging about 3. So, that equates to about 1 per 100,000 media files. Note that media files usually have extensive EXIF or other forms of header information like music info tags, camera settings, etc. Office documents like Word and Excel can also have extended info but I have yet to notice a compare error on them.
  15. The Saga Continues Summary: Retro crashed. Subsequent runs yield -106 error. Recatalogs failed to recatalog All further backups fail with same error. Details: After 3 days of fiddling and two recatalogs attempts (the latter of which was from scratch), it seems I have again reached an impasse that will require trashing my entire backup. Today, when attempting the 1st backup after the aforementioned catalog rebuilds (both of which where not errorless (none has ever been), I ended up in a continuous loop of pop ups reported the following error (like the 1st time that started this problem report): Type/Source: Error / Retrospect Category / ID: None / 1 Date/Time: 4/9/2006 / 10:33:48 AM User/Computer: MYCPU\Trxie / MYCPU Description: Trouble writing: "1-MYCPU, All (A)" (2907914240), error -106 (data overwrite attempt) Clicking [OK], simply retries and repeats the error - ad nauseum. Retro began running again and, voila, generated the above error all over again and is in its never ending pop up error loop again ..... I was able to stop it this time by madly trying to hit the [Cancel] button in between pop ups, rather than the tiny red "X" (Not Red X). After about 3 tries it worked. So, as it stands, I can no longer back up and assume I may have to trash my back up and lose precious data for at least the 5th time. Any thoughts on how to move forward?
×