Automator and Retro config files

[Camelhump]

I created an automator task which is *supposed* to copy the config files to a second folder when the Retrospect Folder in /library/application support is modified.

 

This copies both .dat and.bak files, and simply lets the copy numbers pile up.

 

I added 2 rules, and a license - from a remote console.

 

No Joy -- the automator action didnt trigger.

 

so... anyone have any other ideas on how to get a copy of the config files when ever they are Modified???

 

Thanks

[Maser]

I haven't played a lot with Automator, but how does it defined "modified" -- just by changing the time stamp of the file? Or do you have to modify the contents?

 

That said...

 

Why would you need to get a copy of the file every 90 minutes or so? Why not just once a day with a backup script copying the files to a media set?

[Camelhump]

I never said every 90 minutes

 

Why would I want to get a copy of the config files when they are modified?? See many (including my own) other threads on the config files being lost/corrupted = lost clients = lost selectors = lost license = MAJOR MAJOR PITA

 

Im not sure how automator flags a modified folder,

(automator works at the folder level not the file level).

 

I did notice this morning - I opened retrospect console, remotely, aded a client (manual via IP), and quit. The time stamp, modified, on the config files have NOT changed.

 

This could be the main problem.

 

How the hell do you trap for a modified file - if the file is NOT being time stamped with the most recent change time/date?!?!?!?

 

as for using retrospect to backup retrospect.... well if I lose the config files, how do I access the software?? the license code is stored there - entering the license code erases/overwrites/clears BOTH the corrupted .dat AND the .bak files.

 

this is really not looking like the right path.......

 

Id ask but i suspect that this is not the right forum -- other backup software? must do Macs, and PCs, must backup to Disk, must support a Mac as the server, must support Firewire disk as the backup destination, must be able to handle roughly 100 clients, and half dozen servers including Sql and OS X server.

 

Thanks

 

[Maser]

The reason I said "every 90 minutes" is that appears how often *my* config80.bak file updates itself (as I run Proactive scripts 24/7).

 

If you back up the config files to their own media set, if you have a crash, it's (relatively) easy to reenter the serial number, locate *only* this set and restore the last file you backed up. Then quit the engine, replace the files, restart the engine and you are back in business. I've had to do that a few times while testing stuff. It's not as easy as having a Finder copy, but it works.

 

Unless you are making changes to the configuration hourly (and, in which case, you might just as well make a Finder copy of the files), there's likely no significant reason a daily backup of the files done at midnight (or whenever) wouldn't suffice.

 

 

I think you've hit the nail on the head about why the files get corrupted. The config80.dat file changes *appear* to be cached and only written to the file when there are no other activities going on. Frequently, this is quick, but it's not always quick.

 

I remember asking them waay back when about when does the *bak* file get updated and they weren't able to tell me (as it wasn't an automatic interval -- for me, it's about every 90 minutes...)

 

 

 

 

 

[Maser]

So, I asked them about this.

 

Turns out changes made with the console are stored in RAM and then flushed to config80.dat at specific intervals (such as starting a script or stopping the engine).

 

This could explain why you are corrupting your file when you power your engine machine off -- maybe you are doing this right when the file would be updating?

 

 

Whether or not this is an industry-standard way to do things, I don't know.

 

I'm guessing there's a technical reason they don't automatically update the config80.dat file every time that there is a modification to something...

[Camelhump]

well - in the mean time (no responses to alternatives??)

 

Ill write some more code, and see if I can get the apple script to start the engine to also stop it - and run that at regular intervals. until I get the server setup completed.

 

In concept starting and stopping the engine will update the config files, which will trigger the automator script creating copies and then restart the engine allowing me to continue setup with backups along the way.

 

Ive already lost the manual entry of over 90 IP addresses, and all my rules.........

 

[twickland]

In concept starting and stopping the engine will update the config files...

A simpler way to force an update is to open and close the Retrospect preferences.

[Camelhump]

Ive done that - and NOT gotten an update, at least according to the last modified time stamp (in the finder)

 

[Maser]

Huh -- opening/closing the Console preferences worked here. That's a good tip!

 

Creating a new temporary script -- and then deleting it -- seems to force an update to the config80.dat file, too.

 

(EDIT: I take that back -- the creating/deleting of a new script doesn't seem consistent)

 

Edited December 14, 2010 by Guest

[Camelhump]

I added a client this morning at about 10:30 am local time, not a rule or backup script - but I too did not get an update (as far as the finder is concerned) to the config files.

 

I just looked -the .bak file shows a last modified time of 3:40pm today, the .dat file shows a last modified time of 5:30 YESTERDAY!

 

Does that make any sense?!?!?!?

 

[Maser]

Maybe the time on your computer is off?

 

Or your automator script grabbed the wrong file and put it in the wrong folder (maybe it's running in reverse?)

 

I keep my "application support\retrospect" folder open 100% of the time on my 10.6.5-running Mini. I've never seen the .dat file have an earlier time stamp than the .bak file.

[Camelhump]

time is correct.

automator script hasnt run since yesterday when I finished testing it

 

 

[CallMeDave]

Why not just once a day with a backup script copying the files to a media set?

 

as for using retrospect to backup retrospect.... well if I lose the config files, how do I access the software??

 

I use a Copy script; no Media Set needed, Retrospect simply makes a copy to various other volumes at various times, overwriting the ones that are already there.

 

On each of these destination volumes I keep the Retrospect installer, as well as a text file of my license (just in case). Should I need to I can install Retrospect on another machine and pop in my config file and be up and running in no time.

 

Works for Catalog files, too (since Copy scripts don't use a catalog file).

 

 

Dave

[Daniels]

I keep a hard copy of my rules, clients, license, etc. with my installation CD just in case my config files get corrupted.

[Camelhump]

thanks -

I wanted to keep a 'history' not over write every time.

 

This way:

- if the config file(s) get FUBAR in some way which is not immediately obvious - rules start to change, times of scheduled tasks change etc etc

- if both files get trashed

- if something else I havent thought of

 

happens I can go back in time to try to find a config file that is still valid.

 

[Maser]

So, if you want a history -- do a daily backup of the files with Retrospect.

 

I have almost a year of "config80.dat" files in a media set and it takes less than 500M to store this.

 

If you are concerned about the time it takes to revert, just make a *clean* config80.dat file with the license in it and the already-located config80.dat backup media set in it only. And store that version of config80.dat somewhere safe.

 

 

That way, you can just swap that out if necessary to retrieve something you've already backed up without spending a whole lot of time on it.

 

 

I certainly appreciate the need to consider alternate ways to access the files, but you can (relatively) easily do it with the tools provided.

[Camelhump]

I guess what it boils down too at this point:

 

Im not sure I trust Retrospect enough to do even this simple task.

 

why?

Retrospect 6 - setup time about about an hour, maybe 2 to get the selectors setup to do what I wanted. AN additional few minutes to add clients - which were located automagically.

 

Retrospect 8.2 - I am around 3 months of screwing around trying to get server to see clients, get server to run, get server to hold on to a configuration. Each step has been a fight. Eventually ending in whatever process that takes the most time and effort. See any of my other threads... Hours wasted cloning machines, reinstalling OSes, copying user data back to the original machine re-re-re-re-re installing retro client. TIme on the phone (and through the web site) dealing with tech support to try to resolve some/any/all of the issues. In some cases there have been simple solutions - but not for most.

 

When I **finally** get the 8.2 server up and running Im probably not going to trust it for at least another 3 months without any problems.

 

So - yes - I will try to find other ways to manage backing up some things.