Jump to content

kiddailey

Members
  • Content count

    19
  • Joined

  • Last visited

Community Reputation

3 Neutral

About kiddailey

  • Rank
    Occasional Forum Poster
  1. After chatting with support briefly, it seems I had to uninstall and reinstall. Note that it didn't work perfectly. After the reinstall, I had to remove, reboot, and re-add the local server before it finally connected.
  2. I just (finally) upgraded to OS X 10.7.5 (Lion) from 10.6.8 (Snow Leopard) and although the Retrospect Engine is running, I can't get the app to connect to the local server despite reboots and attempts to re-add it. I haven't tried is uninstalling and re-installing yet, but hoping I don't have to do that. Any help is appreciated. Sorry if this has been answered -- I couldn't find anything in the forums (wish there was a search feature). Edit: Forgot to mention, I'm running Retrospect 10.5.0 (145)
  3. Quick update. After the source had left the network yesterday and rejoined today, the proactive backup continued as normal and only one time. Must have been a strange fluke and hopefully I won't see it again.
  4. I recently upgraded to 10.5 and everything was going well until today. I have two scripts: a scheduled and a procative. The proactive has two sources in it, and is scheduled every 22 hours. Today, Retrospect sudenly decided to repeatedly backup one of the practive sources over and over, immediately starting the process again after completing one. I was forced to disable proactive in order to stop it. I suspect I could have also removed the source from the script to stop it, but I did not try removing and re-adding it for fear of making things worse After a quick scan of the forums, I haven't seen anyone else report this issue. Hoping that posting might yield some insight about what's going on and/or how to resolve the issue. Thanks in advance.
  5. kiddailey

    Grooming Clarification

    Thanks, Lennart. Much appreciated.
  6. Sorry if this has been answered before -- I can't seem to search the forums anymore to check first before posting and the documentation and additional information on the site seems vague. I'm looking for clarification on the grooming functionality. If I understand correctly, it will essentially scan through and remove old backups. The part that I'm confused about is what it leaves behind. Am I correct in that grooming will remove all but the most recent backup for each and every file? In other words, it removes "older versions" from the backup. Thanks in advance.
  7. I thought there was a discussion on CPU usage relating to RetroEngine but couldn't find it in the threads, so apologies in advance if this is a dupe topic (didn't the forums have a search feature at one time?). Recently I upgraded from 10.0 to 10.1 and I am seeing the RetroEngine using CPU cycles constantly when "idle." It typically fluctuates from 2-5% CPU and 20-22 threads constantly. Occasionally, I see CPU usage jump way up to double digits. This happens even when I have all activities paused (see attached screenshot) and whether the server console is running or not. I have Instance Scan disabled and the RetroISA process is not running. Does anyone have any insight into this and whether there is something I can do to lower it closer to 0% as it was before the upgrade?
  8. To also chime in with dsadams and robock -- since upgrading to 10.1.0 (221), I no longer receive email notifications and see the following error in my log files: "E-mail notification failed: error -597 ( mail server not found)" I am using a single email address. The information is correct and did not change from my 10.0 version, which worked correctly. When I do a DNS lookup with the mail server domain copy/pasted, I get the IP address as expected. I am also able to login with the same credentials supplied in Retrospect with my mail application. The odd part is that if I click the "Send Test E-mail" button in the preference, it works fine. It only fails with the error I mentioned during script execution.
  9. Mine was set to "every 1 days" but I'll switch it to 22 hours to see if that makes any difference. Thanks! Edit: Thanks again Twickland -- your solution definitely seems to have made an improvement.
  10. I've got a couple of machines that backup using proactive backup. The scheduling is set 12:00 A.M. - 12:00 A.M. Next Day. While it works, I'm noticing that it's resulting in backups being ran multiple times per day on these machines when they are available for long periods or available in the morning and again in the evening. Is there a way to limit the proactive backup to just once per day while keeping the schedule window as open as possible? Edit: I did search through the forums and documentation looking for an answer to this, so apologies beforehand if it's already been mentioned.
  11. FYI: Also see this thread: http://forums.retros...expensive-docs/ This post by SmokeAndMirrors may be particularly helpful. After recently upgrading to version 10, I noticed the RetroISA background app keeping my server stuck at a painful crawl, using hundreds of MB of RAM and 30-90% CPU constantly. I've got 7 machines that it backs up totaling about 1.5TB of data. Before I turned the scanning off, it was using up over 500MB of Real Memory and edging close to 1GB of virtual after just a half-hour or so of running. I'm really hoping there is going to be an option to simply turn the instant scanning off. I *much* preferred the old scanning process over the background app. It may have been slow, but as my backups run during lower usage periods, it wasn't an issue. The most important point though is that I had control of when the scanning occurred. Edit: Mac OS X 10.6.8 2x3Ghz Dual-Core Intel Xeon 2GB RAM
  12. @Twickland: thank for the reply. I had tried what you suggested, but it didn't work. @Ark: My next step was to contact support, but I figured someone else had already done it. Thanks for posting the email and sharing it with everyone. Uninstalling and running the new app did the trick (mostly). A few additional notes though that may help others: You may have to manually stop the Retrospect Engine either with the System Preferences control panel or through Activity Monitor/command line before running the uninstaller script. The uninstaller just sat there on my machine until the engine was completely stopped. I had to force quit mine because the system control panel wouldn't stop it and the processes would not respond to regular quit commands). I had to quit and relaunch the app before it recognized the server and asked for my license code. As I originally mentioned in my first post, I too got a "Retrospect has detected an encryption key problem with your AES-encrypted Media Set. Please start new Media Sets." error when the app started up the second time, which led me to http://kb.retrospect...Article/AES-Mac warning that I won't be able to read 8/9 backups. Yikes! I already have 10.0.1 which supposedly fixes this error and I was able to unlock a media set created in 8, so I'll be performing a test restore and reporting here. In any case, I'm creating new media sets as recommended for future backups. After running the app for a while, it suddenly quit and upon relaunch it wouldn't connect to the Retrospect engine (though it was definitely running and executing a backup script). I had to shut everything down, uninstall and reinstall to get it to show up in the console app again ... and restart my proactive scripts. Not a good sign Hope this was just a fluke. Edit: One additional note after a few days of running. If you encounter CPU/memory issues because of the RetroISA background app, you may want to disable instant scanning as detailed here and here.
  13. I've spent a couple of hours now trying to find out how to upgrade my Retrospect Server 8.x to 10.x. I can't seem to find any documentation on the site here. The documentation included in the 10.x upgrade is for Retrospect 8 which, unless I'm missing something, only talks about upgrading from the "classic" versions. I (hesitantly) decided to just copy over the application and run it. Nothing blew up, but it doesn't upgrade the server daemons or the System Preferences plugin either -- even after shutting everything down. I haven't tried uninstalling 8 for fear of losing my scripts/schedules (among other things). Any useful help, tips, steps or horror stories related to upgrading is welcome. Thanks! Edit: After fiddling around and restarting, my email notification comes in showing that it is indeed still running the old version: Date: 1/8/2013 + Retrospect version 8.2.0.399 Launched at 1/8/2013 1:04 AM
  14. I noticed my backup had been running much longer than usual today and on further inspection I discovered that Retrospect re-backed up my Windows clients in their entirety -- even files that were already in the catalog and hadn't changed since yesterday. This only happened with my two Windows clients. My two OS X machines were cumulatively backed-up properly. I can't find any other reason other than perhaps the daylight savings time switch really confused Retrospect or the Windows Retrospect client. Did anyone else discover today that their automated backup of Windows clients from OS X Retrospect behaved this way?
  15. Well, this bug continues to randomly plague my Retrospect Workgroup and firewire tape drive, even after the upgrade. I believe that I have discovered a crappy workaround though. It appears that I can avoid getting the "wrong version" error by following these steps: 1.) When the autolaunch begins, click stop and elect to defer the script execution until quit. 2.) Go to the Configure tab and select devices 3.) Wait for Retrospect to show all the devices 4.) Quit Retrospect and when prompted, click "Run script" As I've previously stated, restarting the computer also fixes the problem, but causes me to either miss a day of backup, or manually run one. By defering the script, checking devices, and then resuming the script, the wrong version error appears to be avoided. My guess is that I'm directly causing something to be "woken up" that doesn't happen properly when the script begins to access the drive in an automated state. It's difficult to say whether I'm really avoiding the error at this point, or just getting lucky - I will post an update if the problem happens even when I am following this procedure. Again, please note that this error didn't start happening until some time after the Jaguar compatible release of workgroup.
×