Jump to content

Memory, quitting issues


Recommended Posts

I'm running the current Retrospect Server on an OS X 10.5.1 server, with seven workstations (all 10.5.1). Backup is to file backup sets on large external FW800 drives. The Backup Server script is set to run each night.

 

If Retrospect is launched cold, the backup runs great. Goes through each computer, scans, backs-up, and moves to the next.

 

After a small number of nights, the backup looks like it's running alright, but isn't - stops after scanning each computer due to a memory error. This is noted in the log, but Retrospect continues.

 

After another small number of nights, Retrospect will simply quit, and won't automatically relaunch.

 

The result of this is I need to babysit the server, and I've completely lost confidence in the backup working properly.

 

The only thing I'm thinking of is having Retrospect quit each night after all the backups are done, then having iCal launch it again. Trouble is I'd need to leave it unsecure (password not required to launch), which I'd prefer not doing.

 

This is a remote server to me (50 miles away) with no one local that can look at this daily. I can look remotely of course, but shouldn't need to be part of my daily routine.

 

I've read about segmenting the backup - possible, but a hassle (and sad hack) without much guidance in terms of specifics. Should I split this into Users and other? System and Other? System, Apps, and Other?

 

It appears the current version of Retrospect is left in the 1990's, with the new version still quite a ways away (although the demo at Macworld was slick). I'm looking for suggestions as to how to get Retrospect to work reliably in the meantime.

Link to comment
Share on other sites

After a small number of nights, the backup looks like it's running alright, but isn't - stops after scanning each computer due to a memory error. This is noted in the log, but Retrospect continues.

 

- What is the exact log entry?

 

After another small number of nights, Retrospect will simply quit, and won't automatically relaunch.

 

Sadly, this is expected behavior, due to the way Retrospect auto-launch configuration was designed. If the program doesn't quit cleanly, the information about the next pending Schedule is not written to the necessary configuration file. The solution to this (to get Retrospect to again auto-launch) is to trash that file (Library/Preferences/Retrospect/retrorunfile). But Retrospect's scheduling needs to be more fault-tolerant.

 

The only thing I'm thinking of is having Retrospect quit each night after all the backups are done, then having iCal launch it again.

 

If Retrospect quits cleanly, auto-launch will work (fairly) reliably.

 

I've read about segmenting the backup - possible, but a hassle (and sad hack) without much guidance in terms of specifics. Should I split this into Users and other? System and Other? System, Apps, and Other?

 

You haven't provided any description of what your backup Sources are, but managing data appropriately for your needs and tools is never a hack. It all depends on what you're trying to do, and what your disaster recovery plan is.

 

Backup Server scripts are very flexible (although from your limited description it's unclear if regular Backup scripts might not be as good or better then Backup Server scripts), and segmenting your Sources might be something you'd want to consider even if you weren't having any memory issues.

 

 

Dave

Link to comment
Share on other sites

approximately how many files are being backed up on each machine? Approximately how many files in the catalog? Approximately how big is the catalog?

 

The backup just ran for the first time in a week. Number of files having been backed up ranged from 307 (1.5GB) to 21127 (4.3GB). The 21127 was an exception; I'm sure that user applied a system or application update since the last backup; all others were under 3000 files.

 

The entire boot drives are being backed up. They're all identical graphic workstations - MacPro, 10.5.1, Quark 7, CS3 Design Standard, and not much else. Server plus six workstations. I'm not sure how many files there are in total, but it's a typical setup. Not very many user-created files compared to the number of standard system files.

 

The catalog is 2.03GB, and the main backup file is 478GB. (There are two identical backup sets, one on each of two 1TB drives.)

 

The backup always works fine the first few times through (even if the backup hadn't taken place in a while). The problem occurs a few days in.

 

 

Link to comment
Share on other sites

After a small number of nights, the backup looks like it's running alright, but isn't - stops after scanning each computer due to a memory error. This is noted in the log, but Retrospect continues.

 

- What is the exact log entry?

 

Scanning incomplete, error -108 (not enough memory). Once the error starts, it happens on all computers and will not stop until Retrospect is quit and relaunched.

 

There is no error when it quits out on its own; the app just goes away.

 

After another small number of nights, Retrospect will simply quit, and won't automatically relaunch.

 

Sadly, this is expected behavior, due to the way Retrospect auto-launch configuration was designed. If the program doesn't quit cleanly, the information about the next pending Schedule is not written to the necessary configuration file. The solution to this (to get Retrospect to again auto-launch) is to trash that file (Library/Preferences/Retrospect/retrorunfile). But Retrospect's scheduling needs to be more fault-tolerant.

 

Agreed; I don't trust Retrospect's autolaunching, but there are enough decent workarounds that I don't mind. This is the only situation where I've considered forcing a nightly launch using iCal or similar. (I typically have the system launch it at login, and just leave it running.)

 

The only thing I'm thinking of is having Retrospect quit each night after all the backups are done, then having iCal launch it again.

 

If Retrospect quits cleanly, auto-launch will work (fairly) reliably.

 

I've read about segmenting the backup - possible, but a hassle (and sad hack) without much guidance in terms of specifics. Should I split this into Users and other? System and Other? System, Apps, and Other?

 

You haven't provided any description of what your backup Sources are, but managing data appropriately for your needs and tools is never a hack. It all depends on what you're trying to do, and what your disaster recovery plan is.

 

I posted details in a followup message a few minutes ago. Retrospect should (at least in my opinion) deal with the situation at hand, which is a typical small design network. It's probably the most vanilla network I support - all the exact same hardware, OS, and software.

 

The only thing I could do differently that I wouldn't consider a hack is to give each computer its own backup set (which does have some benefits). But I shouldn't need to do that to work around a memory issue when there's 5GB in the machine. I'm sure the problem is a result of the current version of Retrospect having primarily been written in OS 9 days, when a drive rarely had more than a few thousand files. With OS X just the OS install has (rough guess) 300K files. So the file parser is likely stretched beyond original intent. The curious thing here is the problem doesn't occur at first scans, but a few days later, meaning there's some memory leak or other info improperly retained.

 

Backup Server scripts are very flexible (although from your limited description it's unclear if regular Backup scripts might not be as good or better then Backup Server scripts), and segmenting your Sources might be something you'd want to consider even if you weren't having any memory issues.

 

I've gone to Backup Server scripts here because there is nobody looking at this server on a daily basis. I've found Backup Server scripts to be more resilient of minor errors and to throw fewer useless error messages on the screen (thus scaring anyone that happens to walk by).

 

Thanks for the questions, followup, etc. I do appreciate it.

 

...Mitch

Link to comment
Share on other sites

5GB RAM

 

Retrospect itself can only address 2 GB of RAM. I have seen reports of trouble on systems with high amounts of RAM.

 

What happens if you drop the total physical RAM on the computer to 2 or 3 GB of RAM? Does the problem still continue?

 

This isn't something I can easily test... The problem occurs only after a few days (and hard to predict exactly when), and I don't want to leave the server in a low memory state for that long. Plus this is a remote server 50 miles from me so I'd have to make 2-3 visits. So unfortunately I probably won't give that a try.

 

I have other servers of similar setup where I haven't seen the out of memory issue (including a very similar MacPro, 10.5.1 Server, 5GB RAM, but doesn't back up client workstations).

Link to comment
Share on other sites

I'm not sure how many files there are in total...

 

File counts are part of the information provided by a Backup Set's Summary tab:

Configure->Backup Set->YourSetFoo->Configure->Summary

 

I don't trust Retrospect's autolaunching, but there are enough decent workarounds that I don't mind

 

As I noted, Retrospect's auto-launch functionality is generally trustworthy, except in situations such as yours where something is causing the program to fail.

 

If you have encountered a situation where leaving the program running causes it to fail, you should implement a process where the program is _not_ left running.

 

I'd suggest using the Weekly Schedule window to make the Backup Server script active only at specific times, then use a small regular Backup script to trigger a program quit. Make sure your Look Ahead time is small enough to allow the program to quit instead of waiting for the next pending script.

Link to comment
Share on other sites

I'm not sure how many files there are in total...

File counts are part of the information provided by a Backup Set's Summary tab:

Configure->Backup Set->YourSetFoo->Configure->Summary

 

The whole backup set has 1,975,259 files. (Well, that's one of the two sets; the other is about 5000 fewer.)

 

I don't trust Retrospect's autolaunching, but there are enough decent workarounds that I don't mind

As I noted, Retrospect's auto-launch functionality is generally trustworthy, except in situations such as yours where something is causing the program to fail.

 

And of course that's the situation where I most need to rely on auto-launching... :-)

 

If you have encountered a situation where leaving the program running causes it to fail, you should implement a process where the program is _not_ left running.

 

I'd suggest using the Weekly Schedule window...

 

Since Retrospect is flaky in the launch regard, I'd prefer using something else to handle the quitting and launching. I'm going to test using iCal (which on the server is unused). iCal will launch an app as needed, and I'll have it call an applescript to do the quitting. I'll do a launch at 5pm (active time is 6pm) and a quit at 9am (after the script should be long done).

 

I've set the launch up, and I'll see how that goes before setting the quit script. I'll know in an hour...

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...