script and media ready for backup but nothing!

[kruppasing]

i had set up a friend's macbook for scripted backups every night. she had a drive crash and i went to restore and noticed that the last backup snapshot was over four months ago. i did the restore and soon as iaunched retrospect it began it's scheduled backup. she always kept her external drive connected except when she took her laptop somewhere for the day and has never received a "media can't be found" or "script failed" message during the months that are missing. any ideas what might have caused this?

 

thanks.

[rhwalker]

Retrospect 6.x has had a bug for years whereby its "retrorunfile" preferences become corrupted and prevent autolaunch running of backups. Search these forums.

 

The workaround (rubber chicken dance) to restore operation when this happens (there seems to be no "fix") is to quit Retrospect, trash this file

(/Library/Preferences/Retrospect/retrorunfile), relaunch Retrospect (which causes the file to be regenerated), then quit Retrospect.

 

Many release notes over the years have indicated that this problem is "fixed", but that's never been the case. Hits us about once a month; only way I know to detect is to have Retrospect email you the results of its backups and, when the emails stop coming each morning, it's time to do the rubber chicken dance (see above).

 

I gave up long ago hoping that this bug would ever be fixed. Now that Retrospect 8 has been, um, "released", that's where all of the effort is focused - don't expect any future releases of Retrospect 6.x.

 

Russ

 

[kruppasing]

Retrospect 6.x has had a bug for years whereby its "retrorunfile" preferences become corrupted and prevent autolaunch running of backups. Search these forums.

 

The workaround (rubber chicken dance) to restore operation when this happens (there seems to be no "fix") is to quit Retrospect, trash this file

(/Library/Preferences/Retrospect/retrorunfile), relaunch Retrospect (which causes the file to be regenerated), then quit Retrospect.

 

Many release notes over the years have indicated that this problem is "fixed", but that's never been the case. Hits us about once a month; only way I know to detect is to have Retrospect email you the results of its backups and, when the emails stop coming each morning, it's time to do the rubber chicken dance (see above).

 

I gave up long ago hoping that this bug would ever be fixed. Now that Retrospect 8 has been, um, "released", that's where all of the effort is focused - don't expect any future releases of Retrospect 6.x.

 

Russ

 

thanks russ. i usually check my backup drive every few days to see if the backup set date is current but my friend is not that conscientious.

 

[rhwalker]

An alternative that might work for your friend would be for you to write a simple Python script, schedule it daily, to check the backup date (probably checking the Retrospect log would be the easiest) and send her an email if the date is more than 36 hours old or so.

 

I think that there are some other scripts posted in these forums a while back that would automatically work around this using other ways. I think if you search this forum for retrorunfile, you should be able to find them.

 

Russ

[kruppasing]

russ:

 

i'm interested in your log email trick but i can't find how to set that up. my friend is running 10.4.1 and retrospect 6.1.230. is this something you need a script for? and if so, could you point me in the right direction?

 

thanks again.

[rhwalker]

Well, poke about in the macmail.py python script that Retrospect uses to send its email, and the cShutdown.py script that it uses to shut down Retrospect clients after backups have occurred. Python ships as a standard part of the MacOS X install.

 

macmail.py email stuff

cShutdown.py

 

There's also this workaround for the problem that you were seeing:

Retrospect autolaunch fixer

(note that it creates a log file of unbounded size, so you may want to comment out the logging stuff)

 

Hope this helps,

 

Russ

[kruppasing]

this is fantastic russ. how reliable is the TS Scheduler? should i still run the email script just in case?

 

thanks again...again!

[rhwalker]

how reliable is the TS Scheduler? should i still run the email script just in case?

Well, two comments:

 

(1) It has the "unbounded log" problem that will eventually fill up your disk. Once you get it running and tested, you could comment out the logging in the Python script, or else you could add some stuff to the standard log rolling scheduled jobs for Mac OS X. For 10.4.x, see the end of /etc/weekly and add the appropriate logfile to the list of rolled logs. You will probably have to change the location of the logfile - that's the easiest way.

 

(2) I don't use the script for a different reason. The reason is a bit long, and has to do with how we do a "RAID 1 mirror split" before doing software changes on our server. See the attached email that I sent to Walter Reed (formerly of EMC Retrospect support) (with CC to some of the other EMC support people who were trying to track this bug down) a few years ago under our support contract when he provided this script. Walter was a good guy and a good Python programmer. I miss him.

 

I think that the email stuff is good regardless, because it lets you check on what was backed up. See the discussion in the attached email.

 

Russ

[kruppasing]

how reliable is the TS Scheduler? should i still run the email script just in case?

Well' date=' two comments:

 

(1) It has the "unbounded log" problem that will eventually fill up your disk. Once you get it running and tested, you could comment out the logging in the Python script, or else you could add some stuff to the standard log rolling scheduled jobs for Mac OS X. For 10.4.x, see the end of /etc/weekly and add the appropriate logfile to the list of rolled logs. You will probably have to change the location of the logfile - that's the easiest way.

 

(2) I don't use the script for a different reason. The reason is a bit long, and has to do with how we do a "RAID 1 mirror split" before doing software changes on our server. See the attached email that I sent to Walter Reed (formerly of EMC Retrospect support) (with CC to some of the other EMC support people who were trying to track this bug down) a few years ago under our support contract when he provided this script. Walter was a good guy and a good Python programmer. I miss him.

 

I think that the email stuff is good regardless, because it lets you check on what was backed up. See the discussion in the attached email.

 

Russ[/quote']

 

well i don't know anything about "commenting out the logging" so i guess i'll just use the email script. thanks.

 

 

[rhwalker]

well i don't know anything about "commenting out the logging" so i guess i'll just use the email script.

It would have just involved editing the python script to delete the lines that cause the logging.

 

Getting the Mac OS standard log rolling to roll this log just like it does all of the other logs) is even simpler, as I indicated above.

 

Just add "Rcheck-log.txt" to the appropriate place in /etc/weekly and it will all happen when the other logs are rolled. Here's a snippet showing the change (note the added "Rcheck-log.txt" at the end of the file list):

 

...
echo ""
printf %s "Rotating log files:"
cd /var/log
for i in ftp.log lookupd.log lpr.log mail.log netinfo.log hwmond.log ipfw.log ppp.log secure.log Rcheck-log.txt; do
   if [ -f "${i}" ]; then
printf %s " $i"
if [ -x /usr/bin/gzip ]; then gzext=".gz"; else gzext=""; fi
if [ -f "${i}.3${gzext}" ]; then mv -f "${i}.3${gzext}" "${i}.4${gzext}"; fi
if [ -f "${i}.2${gzext}" ]; then mv -f "${i}.2${gzext}" "${i}.3${gzext}"; fi
if [ -f "${i}.1${gzext}" ]; then mv -f "${i}.1${gzext}" "${i}.2${gzext}"; fi
if [ -f "${i}.0${gzext}" ]; then mv -f "${i}.0${gzext}" "${i}.1${gzext}"; fi
if [ -f "${i}" ]; then mv -f "${i}" "${i}.0" && if [ -x /usr/bin/gzip ]; then gzip -9 "${i}.0"; fi; fi
touch "${i}" && chmod 640 "${i}" && chown root:admin "${i}"
   fi
done

...

If you have trouble getting the email stuff working, post back. Sometimes the instructions aren't clear, and there's a lot of historical stuff in the email setup that confuses MacOS people. Search these forums for "python" and you should see my posts telling people how to do it.

 

Russ

Edited May 6, 2009 by Guest

[kruppasing]

how reliable is the TS Scheduler? should i still run the email script just in case?

Well' date=' two comments:

 

(1) It has the "unbounded log" problem that will eventually fill up your disk. Once you get it running and tested, you could comment out the logging in the Python script, or else you could add some stuff to the standard log rolling scheduled jobs for Mac OS X. For 10.4.x, see the end of /etc/weekly and add the appropriate logfile to the list of rolled logs. You will probably have to change the location of the logfile - that's the easiest way.

 

(2) I don't use the script for a different reason. The reason is a bit long, and has to do with how we do a "RAID 1 mirror split" before doing software changes on our server. See the attached email that I sent to Walter Reed (formerly of EMC Retrospect support) (with CC to some of the other EMC support people who were trying to track this bug down) a few years ago under our support contract when he provided this script. Walter was a good guy and a good Python programmer. I miss him.

 

I think that the email stuff is good regardless, because it lets you check on what was backed up. See the discussion in the attached email.

 

Russ[/quote']

 

well i don't know anything about "commenting out the logging" so i guess i'll just use the email script. thanks.

 

 

russ, thank you for your time on this but i know nada about python scripting, or any scripting for that matter. i assume what you mean about unbounded logs is that the TS scheduler actions will continue to be posted to this log so at some point it will be enormous. i think i'll just go with the email script--that i understood how to edit for my email info.

 

 

[rhwalker]

russ, thank you for your time on this but i know nada about python scripting, or any scripting for that matter. i assume what you mean about unbounded logs is that the TS scheduler actions will continue to be posted to this log so at some point it will be enormous.

Yep, you understand the issue. And it's always a good time to learn an new language...

 

i think i'll just go with the email script--that i understood how to edit for my email info.

Yep, that's the solution I used.

 

However, while the installation instructions are accurate, they aren't always fully understood.

 

Here's the short cookbook hint, which I put at the front of our Retrospect Event Handler because I can never remember the magic dance:

 

-- When saving edited script, save as application, stay open, never show startup screen

-- then delete the ".app" extension on the saved file because Retrospect

-- expects the script to be named "Retrospect Event Handler". Sigh.

-- Then copy the renamed compiled script to /Library/Preferences/Retrospect

Also, I seem to recall that some people have reported problems getting the AppleScript compiler to work right with Intel machines on Leopard. Search these forums for the solution.

 

Again, if you have a problem, post back.

 

Good luck.

 

Russ

[kruppasing]

russ:

 

email scripted worked like a charm! got two messages--"retrospect script has started" and "retrospect script has finished". this is great...no need for the TS scheduler in my mind.

 

THANK YOU.

 

(ps--how do i edit the email script so i just get the "retrospect has finished" message?)

[rhwalker]

(ps--how do i edit the email script so i just get the "retrospect has finished" message?)

Um, use the AppleScript editor and press the right keys?

 

Seriously, change the "sendMailOnStart" property to false, thus:

 

-- Set this property to false if you don't want the main group to receive mail on script or Backup Server starts.
property sendMailOnStart : false

I assume that you have the logic for this property in your Retrospect Event Handler - ours is a very heavily-modified version with bug fixes, trigger scripts to start and stop the mail server for checkpointing, etc. Our version has ancestry in the ancient version used with our ASIP server many years ago before OS X.

 

Russ

[kruppasing]

you do realize that you're corresponding with a scripting ignoramus, right ?

 

i never learned anything about scripting and i wish i did--it's a whole new world of possibilities, isn't it? i'm a graphic designer so i know a lot about adobe apps, fonts, etc but never peered into this world. i went back into the script and found the line you're referring to and made the edit--thank you.

 

now i have to read up on applescripts!