Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About someguy

  • Rank
  1. 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. 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
  2. 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.
  3. 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
  4. Hi - I've found that with Windows clients using a backup password (for client authentication), moving to a private/public key auth model is simple - just copy the pubkey.dat file into the client program folder ("C:\Prog files\Retrospect client" or whatever), and *boom*, the server with the private key will authenticate immediately the next time it tries. Piece of cake, don't have to reinstall a thing. Can the same be done with the Mac 6 client? I can't find any supporting files or prefs in "\Library\Application Support" for Retrospect, and I don't know where the pubkey.dat file could possibly go, and reinstalling on this thing would be a huge pain, as I'm basically being tasked with getting this moving without knowing an admin password for this client box. (Existing Retrospect 6 installation on a Mac OSX 10.4 machine using client auth password, but nobody knows what it is... moved to cert auth for the entire office, and the Windows machines were easy to convert, but this one I'm scratching my head over.) Thanks
  5. I'm having the same issue, and it's quitting at 499.9 GB. Both the backup source server and the backup server itself are systems less than 60 days old running 64-bit Windows 2008 R2. The registry change listed above had no effect (applied to both servers). The only Windows Event Viewer entry comes from the Retrospect server as follows (edited for formatting and applicability): - System - Provider [ Name] Retrospect - EventID 1 [ Qualifiers] 49154 Level 2 Task 0 Keywords 0x80000000000000 - TimeCreated [ SystemTime] 2011-08-29T14:14:05.000000000Z EventRecordID 814 Channel Application - EventData Trouble reading files, error -1019 ( not enough resources) Going to try the suggested workaround of limiting backup scope to shed some weight on the initial backup (which has yet to succeed.) Just wish it didn't take 12 hours to fail, this is taking a really long time to troubleshoot. Edit (24 hours later): Reducing the backup size to 480GB via selectors did the trick. I'm just glad the initial data was only in the ~550GB range and not several TB, I have no idea what I'd do other than find some other (very very expensive) alternate solution.
  6. excellent - so, basically transfering the needed snapshots to a new backup set was a sort of manual grooming operation - I was able to recycle the old backup set and hopefully got rid of the broken pieces during the transfer. Thanks for the help.
  7. yeah, I knew it was one of those 3-letter words thanks, I didn't see the google field before, I've been using the built-in search at the top. I'm almost out of disk space on the backup array, and the transfer set would exceed the available space (pretty much the reason I need to groom - low disk space.) Am I in a catch-22, or can I somehow transfer just the newest snapshots?
  8. I need to groom an MS-SQL backup set and am having one helluva time doing it. It hangs when I let it run proactively, it hangs when I try to schedule a groom job, and it hangs when I run a groom job manually... Retrospect window turns white and stops responding and the Windows task manager shows two Retrospect applications, both not responding, and it will hang for literally a week at a time if I let it (I end up having to end task on them so I can continue backups for the other clients.) This is a dedicated backup server, Windows 2003, 4GB of RAM, two dual-core CPUs, with Retrospect Multi-server 7.6.111. (Incidentally, it looks like Retrospect only ever uses one core, as my CPU usage never goes above 25% even when it's obviously pegged and unresponsive.) I have rebuilt the catalog file several times to no avail. Catalog file is only about 30MB, so I don't know why it would take so long to process, especially after being newly rebuilt. I read something in another post that might indicate a corrupted .rbu file due to ending task on the application? But I can't search for "rbu" in the forums because it's only 3 letters long... and the word "corrupt" gives me way too many unrelated results to sift through... not sure where to look any more.