Backing up your scripts: best practices and strategy?

[jamesiporter]

Is there a good strategy for backing up one's scripts (retrospect scripts) in case these should get lost/damaged? And preferences? I assume these are in Application Support/Retrospect and the preference file in Home/Library, and that's all one really needs.

 

The real nightmare is this: what if you lose all your scripts, even those that would allow you to recover your backed up scripts? Can you rebuild them from the catalogs? I've never tried, hence the question.

 

But it seems that there's always going to be a vicious circle here. The backed up scripts will require a script to retrieve them, and it will be among those back-ups. Or, am I missing something in the logic?

 

Thanks in advance, JIP

[rhwalker]

Is there a good strategy for backing up one's scripts (retrospect scripts) in case these should get lost/damaged? And preferences? I assume these are in Application Support/Retrospect and the preference file in Home/Library, and that's all one really needs.

The location depends on the version of Retrospect. Good strategy is to include them in your backup (perhaps a separate "favorite" source, to use the currently correct term), perhaps even a separate "duplicate" (copy) script, whatever the current term is, to replicate this folder on a different disk from your startup volume.

 

The real nightmare is this: what if you lose all your scripts, even those that would allow you to recover your backed up scripts?

You restore them from your backup. Remember, your backup shouldn't be on your startup volume. Otherwise, you have no backup if your startup volume dies. And, if you have your startup volume, then you have your scripts and preferences independent of whether you have your catalogs.

 

Can you rebuild them from the catalogs? I've never tried, hence the question.

No. The catalogs are a database index into the backup set (now known as media set), that tells Retrospect where the various files are stored for the snapshot(s), and the preferences and scripts aren't in the catalogs. Depending on whether you backed them up, the preferences (which include the scripts) might be in your backup set (um, media set) for restoration.

 

But it seems that there's always going to be a vicious circle here. The backed up scripts will require a script to retrieve them, and it will be among those back-ups. Or, am I missing something in the logic?

You are missing something. No script and no preference (except for your license number) is required to restore. The scripts and preferences are only required for backup.

 

Well, almost. The preferences know where the clients and destinations are, in case you are trying to restore a client. But, if you are trying to restore a client, then you have the Retrospect engine and its preferences and scripts.

 

Comment: It's good that you are asking these questions now and gaining this understanding. The time to figure this out is not in the middle of a crisis when you are trying to do your first big restore and bring things back up while everyone is standing around your desk.

 

I seem to recall that the early Retrospect user's guides started out the section on bare metal restore with the words "Don't Panic" or "Calm Down".

 

I suggest that you test a bare metal restore sometime, starting only from your offsite backups (you do have those, don't you?) just so you fully understand the process of doing the initial install of Retrospect, configuring, rebuilding catalogs from the backup set (media set), restoring your preferences / scripts, etc., just to make sure that your backup policy is backing up everything that is necessary to recover after a fire. Been there, done that. No fun, but it's better than not having the backups for restoration.

 

Russ

[jamesiporter]

ah, very good. It sounds like I can indeed restore (bare metal) from media sets (which I do keep on separate drives). I will try this just to see how it is done. I am using Retr. 8 now. In earlier versions I made backups (media sets) of the scripts but just realized I hadn't done this till now but should have done so.

 

So, recapping: scripts are for creating and running media sets, which can be restored even in the absence of scripts. If that's correct, I'm happy, possibly even safe.

 

Thanks again Russ. Jim

Edited August 20, 2009 by Guest

[rhwalker]

I'm sure it will all be explained when (if) the User Manual for Retrospect is released.

 

Stay happy,

 

Russ

[jamesiporter]

OK, so now I'd like to try to restore from bare metal, but don't even know how to begin the process. Any tips appreciated.

 

Jim

 

wait, I think I just stumbled on it: you just pick the media set you want to restore and give the rebuild catalogue command? It seems to have done the trick somehow (I think)

Edited August 23, 2009 by Guest

[rhwalker]

OK, so now I'd like to try to restore from bare metal, but don't even know how to begin the process. Any tips appreciated.

 

Jim

 

wait, I think I just stumbled on it: you just pick the media set you want to restore and give the rebuild catalogue command? It seems to have done the trick somehow (I think)

Let's make sure that we are talking about the same thing.

 

A "bare metal restore" means taking a fresh computer, with nothing on it except the Mac OS, and getting Retrospect up and running with your backups, etc. That process has nothing to do with rebuilding the catalog unless you don't have a saved copy of the catalog.

 

Steps are, in brief:

 

1. Get the OS installed.

2. Install Retrospect.

3. Get the catalog onto that computer. If you don't have a saved copy of the catalog for the media set, yes, you will have to rebuild the catalog in that case. For large media sets, this can sometimes take a day or two, which is why you might want to have a saved catalog as a part of your backup process.

4. Restore on top of the OS. Full restore, from most recent backup. This will also restore your backed up catalog, assuming that your catalog backup was a part of the backup process.

5. Update the catalog (because the backed up catalog, if it was backed up and restored as a part of the process, will not have been updated at the end of the last backup.

 

Clear?

 

Russ

[CallMeDave]

A "bare metal restore" means taking a fresh computer, with nothing on it except the Mac OS

 

I'd disagree on this definition.

 

I'd consider a Bare Metal Restore to mean taking a fresh computer or drive volume with nothing on it at all; an empty, freshly erased hard drive, and Restoring onto that empty volume all the bits and bytes that had been on the Source computer when it was backed up.

 

Of course that's only a good idea if the backup contains valid information, which might be an issue if the Source was busy reading and writing files at the time of the backup.

 

All part of your Backup Policy decisions...

 

 

Dave

[rhwalker]

Whatever, I'm not going to nit pick. I think we are in total agreement. Unless you are doing a bare metal restore from a separate bootable volume (CD or disk) brought to the fresh computer, you need an initial install of the Mac OS in order to then install Retrospect and do the "bare metal restore" to bring things back to the way they were before the restore. A necessary first step is to get the computer operational so that Retrospect can do the "bare metal restore".

 

Russ

[jamesiporter]

Thank goodness all I meant was restoring a part of my files from a media set on an external HD by rebuilding a catalog and then rebuilding scripts from that. Luckily I found the way. Thanks for all the input.

 

I still wonder what the indicator means when it says a media set's capacity is yellow or red: what determines the limits of storage, the drive's capacity or something intrinsic to a media set's limits regardless of the drive's storage? I assume that a media set has no intrinsic limits: it is equal to the size of any given drive, true? thanks very much. Jim

[CallMeDave]

Russ,

 

I don't think it's a nitty thing at all to differentiate between the two activities.

 

When Retrospect 5.0 was released, Dantz referred to your steps as a "Live Restore." I don't think they gave a term to my steps, perhaps "Offline Restore" might be descriptive.

 

A "Live Restore" is orders of magnitude more complex to achieve. Every file in the existing (new) System OS needs to be scanned and matched. Then there was the requirement that the version/patch level of the "new" system OS be exactly the same as what is/was on the Backup Set. This was, as I was led to understand, because Apple managed to supply binary files that matched all Retrospect's matching criteria but had different content (something about the VCS they used(d)). Some restored files need to be written to a temporary locations (can't have two kernals in the same place at the same time!), and on restart those file need to be moved to their correct place and the other's moved or deleted.

 

The Retrospect Boot CD project was undertaken because a Live Restore from a Removable Disk Backup Set would fail due to an inability to have valid drivers present/available during this process.

 

Heck, you can boot a new Macbook Pro from an SD card in its slot; I'd want to opt for an offline restore anytime I could.

 

 

Dave