cannot add back deleted source

[mjbolzan]

Just before the backup ran was also this morning? How much time passed between "just before the backup ran" and "this morning?"

 

my proactive backups run between 10:59 pm and 6 am. so the night prior to the morning, i checked sometime after 10 but before the backup ran and retrospect saw the volume as available. when i checked the next morning, the volume is unavailable and the backup has not run.

 

Between "just before the backup ran" and "this morning" was the volume on the USB device being used by other programs?

 

No.

 

You have 5 other volumes on a locally attached device that never go offline, and one volume on a different locally attached device that only recently began to consistently go offline.

 

How could you _not_ think it's some sort of hardware issue?

 

Because everything worked fine until 8.2? Only retrospect is having any problem with the device. Only proactive backups appear to have problems with the device. Stopping and starting the Retrospect engine makes the device available. Etc.

 

Backup failed again overnight. I am following a suggestion made earlier in the thread which is to use a different but identically named device.

 

I said earlier that several months ago I replaced the USB stick. I just unearthed the old stick, moved files back to it and will see what happens.

 

retrospect now has two entries for carryon4A, one marked with a tilde, one just plain available. I have left the tilde one there and just changed the scripts to point to the available (old) volume.

[CallMeDave]

my proactive backups run between 10:59 pm and 6 am.

 

Only proactive backups appear to have problems with the device

 

I'm sure there's a reason Proactive scripts are appropriate for your setup, but what happens if you use a Backup script instead for just this one volume, perhaps scheduled before the Proactive script. Isolating the behavior to the type of script would be an interesting datapoint...

 

 

Dave

[mjbolzan]

what happens if you use a Backup script instead for just this one volume, perhaps scheduled before the Proactive script. Isolating the behavior to the type of script would be an interesting datapoint...

 

i can try this but it will be a few days. I'm trying the USB old stick tonight, then the backup set changes, then i need to change back the device, then see if the problem still happens....

[Maser]

In this case -- is it a question of it working when the console is *not* running vs. not working (sometimes) when the Console *is* running?

 

 

You said this:

 

my proactive backups run between 10:59 pm and 6 am. so the night prior to the morning, i checked sometime after 10 but before the backup ran and retrospect saw the volume as available. when i checked the next morning, the volume is unavailable and the backup has not run.

 

 

How did you "check" this? Did you leave the console application running the entire time? (I can't remember -- are you using the console on the same machine as the engine?)

 

 

 

 

[mjbolzan]

How did you "check" this? Did you leave the console application running the entire time? (I can't remember -- are you using the console on the same machine as the engine?)

 

i don't leave the console running. i open it, check it, then quit the console.

 

console runs on same machine as engine.

[Maser]

Can you test restarting the engine (which seems to do the manual backup, right?), but leaving the console open overnight to see if that shows something changed hours later?

 

Or if the manual backup works after engine restart, can you change (temporarily) the Proactive script (or make a new temporary proactive script) so that a proactive backup fires off right after that and see what happens?

 

And leave the console open all the time.

[mjbolzan]

Or if the manual backup works after engine restart, can you change (temporarily) the Proactive script (or make a new temporary proactive script) so that a proactive backup fires off right after that and see what happens?

 

stopped and started engine. ran manual backup. remember this is on old stick. it ran fine.

 

changed proactive to allow runs as of 03:10. proactive scrkpts have kicked off. carryon4a received error -1102 (missing/unavailable). drive is now marked with a tilde.

[Maser]

so, restart the engine again.

 

Do another new manual backup.

 

Do a *second* manual backup -- does that *still work*?

 

If so make a *new* proactive script containing that source only (can use the same media set) -- does that work?

 

If that fails, restart again -- do two (successful?) manual backups -- then try a new *backup* script. Does *that* work?

 

 

Try to isolate if it's your *existing proactive script* at play here, or if there's a difference in the *type of script* accessing the source (maybe even try a "copy" or "copy backup" script, too?)

[mjbolzan]

so, restart the engine again.

 

Do another new manual backup.

 

Do a *second* manual backup -- does that *still work*?

 

Yes.

 

If so make a *new* proactive script containing that source only (can use the same media set) -- does that work?

 

No.

 

Interesting thing is the first time i did this, i forgot to do two manuals first, just did one. i duplicated the proactive script, set the single source in it, then set the time so it would run.

 

It failed with volume unavailable.

 

however, stopping and starting the engine would not make the volume available. i had to remove it out of the original proactive script, stop and start again. then the volume was available for manual backup.

 

since the sticks don't matter, have put the new one back, this time with a different name. retrospect seems to know though it has seen this one before. instead of two unavailable entries for "carryon4A", there is one unavailable, probably for the old stick, and one available for "Carryon4D".

[Daniels]

I have found that if a script is already corrupt and you duplicate it the copy has the same corruption so it is better to create the script from scratch instead of trying to duplicate a script.

It is starting to sound like the problem lies when you close the console before the proactive backup since all backups while the console is running are working fine. Here are a few things to try:

1. Make a non-proactive script with just USB drive and exit the console before the script starts. If my suspicion is correct this should fail.

2. Leave the console open while the Proactive backup is running.

[Maser]

Yeah -- don't duplicate your existing proactive script -- make a new one and try that.

[CallMeDave]

retrospect seems to know though it has seen this one before

 

Retrospect has never depended on volume names for identification; it's always used unique id's provided by the operating system.

[mjbolzan]

 

since the sticks don't matter, have put the new one back, this time with a different name.

 

backup failed overnight with volume unavailable message.

 

I have found that if a script is already corrupt and you duplicate it the copy has the same corruption so it is better to create the script from scratch instead of trying to duplicate a script.

 

OK, I'm trying this.

 

do not believe this is the source of the problem. earlier in this thread, i mentioned that i had to do a complete rebuild of retrospect. for the script to be corrupt requires it being corrupted on two different occasions. not impossible, but i certainly hope retrospect is not that fragile.

 

It is starting to sound like the problem lies when you close the console before the proactive backup since all backups while the console is running are working fine.

 

not true. for the last few tests yesterday, the console was open. whether the console is open or not has no impact on this problem.

 

My present theory for making this happen--

 

01) needs

 

OS X 10.6.4, retrospect 8.1, 2 USB sticks maybe of same size.

 

external firewire device

 

02) put a couple of things on stick A, including a dmg.

 

03) create a rule in retrospect to exclude the dmg file from backup.

 

04) create a backup file on external firewire device.

 

05) run a proactive backup of stick A and the mounted dmg.

 

06) copy all the files to stick B. unmount stick A. rename stick B to same name as stick A. unmount and remount in same port stick A was in.

 

change the proactive script to back up the new stick A.

 

07) upgrade retrospect to 8.2.

 

08) run the proactive backup.

[mjbolzan]

I have found that if a script is already corrupt and you duplicate it the copy has the same corruption so it is better to create the script from scratch instead of trying to duplicate a script.

 

OK, I'm trying this.

 

the proactive backup just failed. so whether it was a duplicated versus a new proactive script does not matter.

[Maser]

So, what about a backup *script* vs. a manual backup?

 

You've said a manual backup works -- *twice*, right? -- after you restart the engine?

 

Does a "backup" script work?

[Maser]

03) create a rule in retrospect to exclude the dmg file from backup.

 

05) run a proactive backup of stick A and the mounted dmg.

 

 

 

Are either of the above steps significant in your results? This is the first time you've mentioned the rule above (I think.)

 

 

What if you never mount the .dmg (or add it as a Source)?

 

Do you see the same problem backing up *only* the stick?

 

 

And, at what point in your steps above do you actually *mount* the DMG?

Edited September 10, 2010 by Guest

[mjbolzan]

So, what about a backup *script* vs. a manual backup?

 

You've said a manual backup works -- *twice*, right? -- after you restart the engine?

 

Does a "backup" script work?

 

yes it does. i created the manual backup script from scratch.

[mjbolzan]

03) create a rule in retrospect to exclude the dmg file from backup.

 

05) run a proactive backup of stick A and the mounted dmg.

 

Are either of the above steps significant in your results? This is the first time you've mentioned the rule above (I think.)

 

i don't know if it's been mentioned before. my feeling is that they don't matter but at this point i don't know what matters.

 

i ran a test using a proactive script against a file set which just has the new stick in it. it failed, so that may not be relevant either.

 

What if you never mount the .dmg (or add it as a Source)?

 

Do you see the same problem backing up *only* the stick?

 

i have run a proactive script with just the stick in it. it fails.

 

And, at what point in your steps above do you actually *mount* the DMG?

 

the dmg is pretty much always mounted.

[CallMeDave]

what about a backup *script* vs. a manual backup?

 

Same thing, Steve. Retrospect no longer has "Immediate" options, everything is a script (even the Assistant).

 

My present theory for making this happen--

 

Did you perform these steps on a clean testbed?

 

And what on earth is the purpose of step #6? Is that part of your Backup Plan?

[mjbolzan]

 

Did you perform these steps on a clean testbed?

 

No.

 

And what on earth is the purpose of step #6? Is that part of your Backup Plan?

 

because it is what happened. i changed the stick about a month before going to 8.2.

 

 

[CallMeDave]

earlier in this thread, i mentioned that i had to do a complete rebuild of retrospect.

 

Your rebuild didn't include the steps in your theory, did it? Didn't you uninstall 8.2 and then reinstall 8.2?

[Maser]

So, the problem in a nutshell seems to be "things worked after changing a stick to a new stick with the same name -- under 8.1, but under 8.2, things break".

 

And "I haven't tried this with a clean config file on a different Mac yet".

 

Pretty much it?

 

 

[mjbolzan]

Your rebuild didn't include the steps in your theory, did it? Didn't you uninstall 8.2 and then reinstall 8.2?

 

No. the theory is a work in progress.

 

when i rebuilt, i used the 8.2 base.

[mjbolzan]

So, the problem in a nutshell seems to be "things worked after changing a stick to a new stick with the same name -- under 8.1, but under 8.2, things break".

 

yes.

 

And "I haven't tried this with a clean config file on a different Mac yet".

 

also true, though i have tried it on a clean config on the same mac.

[Maser]

So, the problem in a nutshell seems to be "things worked after changing a stick to a new stick with the same name -- under 8.1, but under 8.2, things break".

 

yes.

 

 

 

 

So, have you reverted your current setup back to 8.1 to confirm things work again in 8.1?

 

You can just uninstall 8.2 and reinstall 8.1 -- it will use the same "config80.dat" file.