Backing Up Your Retrospect Catalogs

[dstranathan]

Just curious if you guy backup your Retro catalogs as part of a separate backup routine outside the normal backups, or if you perhaps use something other than Retrospect to back them up.

 

My catalogs live in the default location (i.e; /Library/Application Supports/Retrospect), and I backup my Retro server's boot/system volume nightly (catalogs included).

 

I have been considering running a separate rsync script to copy the catalogs to a network volume on another server as well. Seems like there is a chicken and egg paradox when you use Retro to backup its own Retro catalogs right? After all, Retro needs to write to the Retro catalog to record the contents and snapshots of the backups of its catalog which is stored in the Retro catalog that's getting backed up...by Retro. Therefore the catalog you are backing up is never totally accurate because its changing as you are backing it up. Its like the quantum mechanics allegory of Schrodinger's cat. :-)

[Maser]

What I do:

 

My main media sets go to a 6TB RAID.

 

Every Friday, I stop the engine, then I use Carbon Copy Cloner to backup this RAID to a separate RAID (which just backs up the weeks changes.)

 

After that's done, I just do a finder copy dump of the Catalogs directory to the backup RAID.

 

That way, I have a backup copy of everything that's at most one week old should I need it. And I *have* needed it in the past...

[cpguru21]

to backup the catalog, and retro directory under application support, can you do this live, or is it recommended to shut down the engine first?

 

also, I have a lot of old catalogs that are large from my initial setups and backup schemes that are no longer used. what is recommended for catalog cleanup/removal?

 

thanks and please let me know if I should start my own thread.

 

[Maser]

Well, you *can* do it live, but if the catalog files are accessed while you do this, you won't get a clean "snapshot" of things. If it were me (and it is when I do it), it's trivial enough to stop the engine for an hour while I do my archive backups to my backup RAID/copy the catalog files.

 

I do backup the "config80.dat" file, "live" though. I've restored a "live" backup version without issue.

 

 

As for old, unused catalogs? Just "remove" them from the Media Sets tab in the console, then trash them.

[baweeks]

Even without Retro 8 yet to have script support, could not an applescript or automator script to be written to run at a time that the Engine is known not to be doing a backup, the applescript would be written to kill the Engine's process, and then copy config.dat and config.bak to a folder elsewhere, then restart the Engine's process. If one used the 'folder.org' folder action script on the destination folder where the .bak and .dat files were copied to, you could keep dated copies of your config files going back for a very extended period of time. All of this would be automated. See the Entourage forums for more info about the 'folder.org' folder action script.

-baweeks

[Maser]

It's just as easy (IMO, easier) to set up a media set and do a daily backup of the /library/application support/retrospect folder to it (or just get the .bak file only.)

 

The .bak file updates frequently while the engine is running, so if you back up that file daily, you should be fine.

[rhwalker]

Even without Retro 8 yet to have script support, could not an applescript or automator script to be written to run at a time that the Engine is known not to be doing a backup, the applescript would be written to kill the Engine's process, and then copy config.dat and config.bak to a folder elsewhere, then restart the Engine's process.

I don't think that is possible.

 

Consider the situation with proactive backup, where the engine is forever polling the network and might fire off a backup at any moment.

 

Consider also the case of grooming that might be triggered for whatever reason, which can take a VERY long time.

 

Consider also the case of new media action ("Start new Media Set" or "Recycle Media Set" media action), which will trigger a complete backup. Don't know about you, but that takes a long time for me.

 

Right now, in its fragile infancy, if you kill the Retrospect engine while its doing anything, that's almost guaranteed to corrupt the config file, the catalog, or the media set. Heck, it might just decide to corrupt them out of spite even if it's not doing anything.

 

Really, the only way to do this stuff (and other stuff, as well, such as stopping/checkpointing/restarting services, etc.) on a server is coordinated scripting action with Retrospect. I'm hopeful that "real soon now" this will appear.

 

Scripting, plus stability, plus ability to read older backup sets, are what we are waiting for before deployment.

 

Russ