Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About urza311

  • Rank
    Occasional Forum Poster
  1. urza311

    Lost all configuration

    I also ran into this problem recently on one station I manage. It's an iMac 3.06 GHz Core i3 running Mac OS X 10.6.5 (just updated today to 10.6.6, so I know 10.6.6 is not the cause of this issue). I noticed a couple of days ago that I had not received an email confirmation from Retrospect in a while (the last one was 01/03/11 at 3:04 AM). So I got onto the station, launched Retrospect and was asked to enter my license number. I thought that was weird since Retrospect had been licensed on this station months ago, but I did it anyway. Once I did, I discovered all the scripting was blanked out! I saw the note about restoring those two files -- unfortunately, I don't have Retrospect configured to backup that folder (I really only backup the user home). I also have Time Machine configured on this system, but on that backup I also omit the root library and system folder -- have never seen any reason to backup system files. Now that I've discovered that Retrospect is storing its config files in the root library, I realize the flaw in that strategy. Gonna have to rewrite all my scripts again. If this had happened on the cusp between 2010 and 2011, I'd think it was some date-oriented issue. But I definitely did get some backups on the first 3 days of January. The only other significant change happened on 12/28/10. We'd been discussing security on this station, and it was decided that the user would log out of the computer at the end of the day (leaving the system at the login prompt). Retrospect is scripted to start its runs at 2 AM, which apparently it has been able to do while logged out (something I wasn't sure would happen, but it does work). However, letting Retrospect run while the user is logged out was a noteworthy change. So I've got two questions: 1. I've never seen this issue before -- anyone know what causes it? Can it be prevented? I don't look forward to the idea of having to rewrite my scripts on a recurring basis. Has anyone else experienced this problem and also had Retrospect scheduled to run automatically while the user is logged out? 2. Since I don't backup /Library/Application Support/Retrospect/ either with Retrospect or Time Machine, I should find a way to get that duplicated somehow. My choices would be to let Time Machine backup the entire /Library folder -- seems an awful waste of space for two tiny config files -- or possibly adding a script to Retrospect that duplicates these two files into another folder within the user's home every night. That way they would be rolled into the area that Time Machine backs up and therefore easily restored. Is it possible for me to script Retrospect to duplicate the /Library/Application Support/Retrospect folder into another folder? Or is that like trying to duplicate a file that's in use?
  2. urza311

    Windows 7 clients

    Yeah, I never backup more than some data files on the Windows machine... just accounting and timekeeping data, nothing system-wise. Thanks for the feedback. Quick follow-up: are you using the 7.7.106 or 7.6.107 client?
  3. Forgive me for posting this if it's already been answered, but I did try searching the forums for this information and have been unable to locate it. I have a Mac Mini running Mac OS X 10.6.2 and Retrospect Single Server 8.1.626. I also have a single Windows XP Pro station that has Retrospect Client installed, and I backup three folders from the Windows system to individual file archives on the Mac every night (which are then in turn copied onto a tape by Retrospect Single Server later in the evening). The Windows station is being replaced by a totally new computer running Windows 7 Professional. Can I use the Retrospect 7.7 Client on this new system and backup these same folders on my Single Server 8 station?
  4. urza311

    MD5 digest mismatch errors

    Hello? I posted this several days ago. Anyone care to tell me what an MD5 digest mismatch is? I'm still getting these nightly.
  5. SETUP: Windows Server 2003 R2 SP2, Xeon 3GHz, 3G RAM. Backing up to removable external hard drives via FireWire connection. Three-drive rotation, changed weekly. PROBLEM: We've been recently getting a glut of these MD5 digest mismatch errors during verification. It's not always the same files every night, and some of the files that do come up have been unchanged for years. It flags a mismatch one night, then the next night -- even though the original file hasn't changed and we're still using the same removable drive -- the file backs up fine. Each nightly backup is done to an individual file on the removable drive, so each night is running to its own storage file... I guess that makes each run unique in its own way. Below is a small section of the errors we've been getting. What is an MD5 digest mismatch, and does this point to any specific problem? I think one of our removable drives may be going bad, but I think the odds of two of them going bad at the same time are a bit high. 4/2/2009 4:43:44 AM: Copying Mimics on DATA (E:) 4/2/2009 4:55:39 AM: Snapshot stored, 6,950 KB 4/2/2009 4:55:42 AM: Comparing Mimics on DATA (E:) File "E:\Mimics\Ballard-A\Local Settings\Application Data\Microsoft\Outlook\ab.pst": didn't compare An error occurred during the verification step. The MD5 digest for the file "E:\Mimics\Ballard-A\Local Settings\Application Data\Microsoft\Outlook\ab.pst" did not match, error -1129 (MD5 digest mismatch) File "E:\Mimics\Burch\Local Settings\Application Data\Microsoft\Outlook\burch.pst": didn't compare An error occurred during the verification step. The MD5 digest for the file "E:\Mimics\Burch\Local Settings\Application Data\Microsoft\Outlook\burch.pst" did not match, error -1129 (MD5 digest mismatch) File "E:\Mimics\Holt\Local Settings\Application Data\Microsoft\Outlook\edave.pst": didn't compare An error occurred during the verification step. The MD5 digest for the file "E:\Mimics\Holt\Local Settings\Application Data\Microsoft\Outlook\edave.pst" did not match, error -1129 (MD5 digest mismatch) File "E:\Mimics\Holtdata\agent_cd_minus\agentPPT-3.ppt": didn't compare An error occurred during the verification step. The MD5 digest for the file "E:\Mimics\Holtdata\agent_cd_minus\agentPPT-3.ppt" did not match, error -1129 (MD5 digest mismatch) 4/2/2009 5:03:28 AM: 8 execution errors Completed: 20586 files, 9.9 GB Performance: 1095.6 MB/minute (944.8 copy, 1303.7 compare) Duration: 00:19:43 (00:01:13 idle/loading/preparing)
  6. Okay, fine... I just decided to try getting an answer here first before going elsewhere. Anyone got one?
  7. Umm... sorry, not clear. I mean to say I should start with support in this forum before I go to LaCie. That's what I meant by EMC support.
  8. Got a curious issue here. I have an older Mac (PowerMac G4 1.4GHz, 1.5G RAM) that I just did a complete overhaul on -- erased the hard drive, reinstalled Mac OS X 10.5.6 from scratch, etc. This Mac also runs Retrospect 6.1.230 (driver and has a LaCie-brand LightScribe internal drive (TSST SH-W162L fw version LC03). When this Mac was running OS X 10.4, I used LaCie Lightscribe Labeler 1.2 to burn disc labels, and it worked fine. But now if I have Retrospect running, anytime I try to launch the Labeler program, I get the message "LaCie LightScribe Labeler is already running; this application will now quit." If I close Retrospect, the Labeler launches fine. I have already gone into Retrospect's Device Status window and told it to ignore the optical drive (Retrospect on this station backs up only to a Sony SDX-420C AIT drive). So that's not the answer. I know this is LaCie's program that is giving me the error, but since it only does it when Retrospect is running, I figured I'd better start with EMC's support before going over to LaCie. FYI, version 1.2 is the latest version of the Labeler software, and I have Lightscribe host from the official LightScribe site installed (that too is the latest version). Any ideas?
  9. Hello? As I've said above, this is a supported mechanism. Any other ideas?
  10. urza311

    error -1017 (insufficient permissions)

    The share requires NO access rights, as I mentioned in my email. The script runs fine manually; it does not execute under automatic execution. If it did not work manually AND automatically, then I'd say you're right and there was a NAS configuration situation here. But that is not the case. If it works one way, it should work the other.
  11. I've run into the error message mentioned into this subject line, and I have a theory as to why it happens, but am looking for confirmation. I have one machine on my network that is primarily responsible for doing network backups of several stations. This station has been upgraded to Vista... but I do not think this is the source of the problem. Here's how my system was setup previously. BACKUP SERVER * Windows XP Pro * Retrospect 7.6.111 * has licenses to backup up to 18 clients * has internal tape drive * runs backups on desktop clients between 12 AM and 3 AM DESKTOP CLIENTS * Windows XP Pro * Retrospect Client 7.6.106 LAPTOP CLIENTS * Retrospect 7.6.111 * duplicates user folder to target folder on backup server sometime between 11 AM and 2 PM (staggered so two laptops don't access the backup server simultaneously) Here's the deal... I have three laptops that are all running Outlook 2003. Since these laptops leave at the end of the day, I can't run backups on them in the middle of the night (if I could, I'd use the Retrospect Client instead). If I try to use the server to remotely backup a laptop using the client software while Outlook is running, it can never get the Outlook .PST file because it's in use. So I bought full versions of Retrospect for these laptops, and they do their own backups to shared folders on the backup server. The desktop clients, since they never leave the building, are easier to deal with. Retrospect backs them up as remotes in the wee hours, and people just leave their computers on with all applications closed down, so it can access the Outlook .PST file without a problem. The laptops duplicate their user folder to shared folders on the backup server (these are stored on a second internal SATA drive). When the backup server backs up a desktop client, it does a duplication of the user folder on their station to an unshared folder on this same SATA drive. At 3 AM, the backup server backs up all the local clone folders to an internal AIT drive. The reason I do duplicates with all the clients instead of backing them up to files is because the vast majority of data never changes. So if a given client has 3G of storage in their user directory, of which 1G is the Outlook .PST file and 2G is pictures, documents, etc., then the duplicate only ever really has to nab the .PST file and maybe an odd document or two here. Then the clones on the local drive have very little changed, so when the tape drive backup kicks in later in the evening, it doesn't have to backup 3G of data for this client, but rather just 1G or so. This way, I can get all stations backed up every night onto a single tape every week. Regardless of whether it's a laptop running its own copy of Retrospect, or the backup server duplicating a remote client, all duplication scripts are set to make duplicates without any rights (don't duplicate Window system state, don't duplicate Windows file security, etc.) -- I don't want folder permissions to become a snag. For the three laptops backing up to shares on the backup server, each of these shares is setup as an open share (no username or password required to access or write files in the folder). Again, I don't want to deal with any permission rights issues. So, in both cases, I get a permission-less clone of a station's user directory on the internal hard drive of the backup server, and that folder gets backed up to tape at night. THE PROBLEM I'm only running into this -1017 error with my laptop stations, and my testing has shown me it *only* happens if the execution is automatic. If I go to that laptop, launch Retrospect and manually run the script, it works fine every time. I have a suspicion as to why this is happening with my new Vista-based backup server, and why it might happen to other people (I've seen some other notes about this problem in the forum). Under my original XP-based backup server, Retrospect on the laptops was set to copy files to a UNC-based destination, such as: \\majordomo\targetbb I named my backup server Major Domo, so it shares on the network as "majordomo". Each laptop station has its own target folder, so in this case it is "targetbb" for a laptop user who's initials are BB. However, I found I ran into problems pointing to a UNC-based path on Vista from an XP client... most of the time, it would be unable to find the share and eventually timeout. So I changed the target on the laptop to be: \\\targetbb Major Domo has a fixed IP address on my network, so that will never change. I can connect to this path using the RUN command on the laptop, or use it as a target in Retrospect for it to back up to. Works fine, and with no hesitation... immediately pulls up the share every time. If I run the script manually, here's a rundown of what I see in the execution window. * preparing for Open File Backup * scans local folder * scans remote folder * preparing to execute * runs the copy * runs the comparison * execution completes successfully If I set the script to run, then exit Retrospect and sit there to watch it go, here's what I see: * preparing to execute * some text messages that flash by so fast I can't read them * backup fails even before it scans the local folder! Here's the log entry for the successful manual backup and the unsuccessful scripted backup. MY THEORY IS THE BACKUP FAILS BECAUSE I'M USING AN IP ADDRESS AS THE TARGET INSTEAD OF A UNC PATH. The laptop stations had been running Retrospect 7.6.111 just fine prior to me upgrading the backup server to Vista, so the only thing that's changed for them is really the target path. Can anyone corroborate this or counter it? + Duplicate using mimic-BB at 8/6/2008 3:57 PM To volume targetbb on - 8/6/2008 3:57:14 PM: Copying becky on Boes (C:) 8/6/2008 3:58:08 PM: Comparing targetbb on 8/6/2008 3:58:08 PM: Execution completed successfully Completed: 1 files, 1 KB Performance: 0.1 MB/minute (0.1 copy, 0.1 compare) Duration: 00:00:54 Exit at 8/6/2008 3:58 PM + Retrospect version 7.6.111 Automatically launched at 8/6/2008 4:00 PM + Duplicate using mimic-BB at 8/6/2008 4:00 PM Can't access volume targetbb on, error -1017 (insufficient permissions) 8/6/2008 4:00:41 PM: Execution incomplete Exit at 8/6/2008 4:00 PM + Retrospect version 7.6.111 Launched at 8/6/2008 4:00 PM
  12. Yes. The Sony AIT-i200ST is a SDX-570V mechanism. That is the way it shows up in device manager. I think AIT-i200ST is simply the kit number, including the SDX-570V drive, software, mounting brackets, etc. So this is a Sony SDX-570V with firmware 0101. Sorry... probably should have identified it as such before, but it's listed on my inventory under the kit number, which is why I listed it that way in my posting.
  13. Not sure what's going on here. I moved the device to a different SATA port; that did not help. I then tried to remove the tape drive from the device manager and also checked the box to delete the device driver from Windows when doing so. When the system restarted, it found the device and asked me what to do about it; I told it to ignore it and not attempt installing a driver in the future. It now shows up in the device manager as an unrecognized device with no known driver. None of these changes has made Retrospect see it other than a series of bullets. With the Sony driver installed, Windows saw the drive just fine. The Sony Tape Tool diagnostic was able to write and read 1G of data to a blank tape without a problem. Yet, with or without the device driver installed, Retrospect refuses to see the drive correctly. And the drive worked fine under XP. Is there anything else you can recommend I try? I'm not sure why a supported device like this that used to work is now impossible for Retrospect to use.
  14. Disabled the drive within Windows' device manager and launched Retrospect; still shows the same. Restarted just to be sure -- checked to make sure it was still disabled, which it was -- then launched Retrospect. Still shows up just as bullets.
  15. I have a station (Asus P5GD2-X mobo, 4G RAM, Sony AIT-i200ST tape drive, Retrospect 7.6.111) that had previously been running Windows XP Pro, and the tape drive worked fine under that OS. I've done a clean install of Windows Vista Business and now the tape drive is not visible to Retrospect. If I go into Retrospect's device management section (environment tab), it will show me the two internal SATA drives, the internal DVD-RW drive, the internal DVD-ROM drive and where it should list the tape drive it shows me nothing but bullets. I've seen this "bullet" phenomena mentioned in a few other places in the forum, but they're always in conjunction with an optical drive. My Sony drive had firmware 0100, and I found out there was a 0101 update, so I tried that but it hasn't changed anything. The tape drive shows up in Windows' device manager... it was not recognized initially, and I understand I shouldn't load a Windows tape driver for this drive unless required by the backup software, but since it wasn't working without it, I tried the latest driver from Sony's site and that also has not helped. Any suggestions?