someguy Posted September 7, 2011 Report Share Posted September 7, 2011 I sure hope this is obvious for someone - it's simply not for me - and that the answer is short enough that someone would feel happy to share the solution Does the "proactive" part of Retrospect (7.7.562 on Windows Server 2008 x64) allow itself to be run as a service? I'm hoping the answer is yes so I don't have to have the backup server logged in at the console all the time. I'd prefer the Retrospect software just run as a service in the background, so in the event of a reboot (intentional or otherwise) we don't have to remember to go in and manually launch the Retrospect software to get it going again... we'd like it to "just work" like anything else on a server that is just supposed to do its thing after being configured. I understand scheduled scripts are supposed to work even without the program running interactively, but how about the proactive scripts? Thanks in advance Quote Link to comment Share on other sites More sharing options...
04254619-5320-4164-92ae-6339ca6048ea Posted September 7, 2011 Report Share Posted September 7, 2011 Not exactly.... In preferences you can tell retrospect to run in a session as whatever user has sufficient privileges. It will start and execute proactive or scheduled tasks. You will need a remote console not RDP to connect to the session. Quote Link to comment Share on other sites More sharing options...
someguy Posted September 7, 2011 Author Report Share Posted September 7, 2011 (edited) Not exactly.... In preferences you can tell retrospect to run in a session as whatever user has sufficient privileges. It will start and execute proactive or scheduled tasks. You will need a remote console not RDP to connect to the session. I tried that over the weekend - Configure -> Preferences -> Execution - Startup: check all boxes, radio selection to "stay in Retrospect" - Security: Run Retrospect as a user account with domain "backup administrator" privs, set Launcher service as same user for good measure (this user account is not a local admin on the backup server, though - that's what I'm going to test as soon as I'm done posting this.) Then, for good measure, rebooted. Checked today, but no scripts fired over the weekend at all. So I found a reference in the old Dantz boards to change the setting to run Retrospect as the "logged in user" which is supposed to just use the Launcher service credentials... tested again just now, still nothing happened. Be right back with the results of setting to local admin (hopefully) edit: I lied, the domain user referenced *is* a member of local admins on the backup server. Edited September 7, 2011 by radiumsoup Quote Link to comment Share on other sites More sharing options...
jotrago Posted September 8, 2011 Report Share Posted September 8, 2011 Retrospect does NOT run as a service (Yet - coming in future edition, watch this space:rolleyes:) Retrospect runs as a normal program. However it does have a Launcher Service (see Retrospect launcher in Services) The launcher manages starting and stopping Retrospect to run jobs according the the schedules, or the Scheduled time slots for ProActive. So after a reboot, Retrospect will lauch itself when required Whether you actually see Retrospect running, and whether it stays active after a job has finished is controlled by the Preferences Discussed above. The sources and Backupsets must also be available for ProActive to run, check in the ProActive tab, that the sources are showing as ready, and that the BackupSets are Ready. If they show Media or Failed they may be missing or damaged. Proactive is also controlled by the Default schedule in Prefs, and by Individual Schedules in the Proactive Scripts. Remeber that by definition, ProActive does not run at any fixed time for any given client, based on the frequency you specify in the script it will constantly sort the ProActive backup queue by the longest outstanding backup client, so it is possible there may be times when it has nothing to do. A useful trick, and one that makes remote management easier is to have Retrospect Running Permanently in a Terminal Services Session. That way it is always running, does not interfere with other console activty, and is always available for remote access by RDP. (remember to ONLY close the RDP session dont LOGOFF) THere is a section in the manual about doing this, and see this note Quote Link to comment Share on other sites More sharing options...
someguy Posted September 8, 2011 Author Report Share Posted September 8, 2011 Retrospect does NOT run as a service (Yet - coming in future edition, watch this space:rolleyes:) Retrospect runs as a normal program. However it does have a Launcher Service (see Retrospect launcher in Services) The launcher manages starting and stopping Retrospect to run jobs according the the schedules, or the Scheduled time slots for ProActive. So after a reboot, Retrospect will lauch itself when required Whether you actually see Retrospect running, and whether it stays active after a job has finished is controlled by the Preferences Discussed above. I'm not concerned with watching it in real-time, it just doesn't seem to run at all - the proactive time for all but one script is set to run 24/7, but they never start. The one that is set to 7PM to 7AM didn't start either. The sources and Backupsets must also be available for ProActive to run, check in the ProActive tab, that the sources are showing as ready, and that the BackupSets are Ready. If they show Media or Failed they may be missing or damaged. Proactive is also controlled by the Default schedule in Prefs, and by Individual Schedules in the Proactive Scripts. Remeber that by definition, ProActive does not run at any fixed time for any given client, based on the frequency you specify in the script it will constantly sort the ProActive backup queue by the longest outstanding backup client, so it is possible there may be times when it has nothing to do. A useful trick, and one that makes remote management easier is to have Retrospect Running Permanently in a Terminal Services Session. That way it is always running, does not interfere with other console activty, and is always available for remote access by RDP. (remember to ONLY close the RDP session dont LOGOFF) THere is a section in the manual about doing this, and see this note It works fine if I launch the application manually, so I know it's not a source or backup set issue (backing up to local disk). Default schedule is 24/7. Individual schedules are 24/7 except for one source. I understand the terminal services trick, it's one that I used in a past life when I ran Retrospect years ago for a long-gone employer... I just can't recall all of the nuances since it's been so long, and am frankly a little shocked that it still can't be run as a pure service. I know I had created a workaround somehow, I just can't remember how I did it. The backups that should have fired over the weekend did nothing, there were no history entries to show that any backups had occurred during that timeframe. At minimum, I expected the scheduled backup at 7PM to fire, but it did not. Will check out the link, thanks Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.