cannot add back deleted source

[Maser]

The fact I couldn't see the USB stick was because I didn't give the console enough time to display it.

 

I tried to reproduce this (even reformatted the stick as APM) and could never get any option to remove the stick *or* the mounted .dmg I created and copied to the stick.

 

Sorry. Probably the only thing I could suggest is starting with a clean config80.dat file and see if you can mount your problematic stick that way. If so, it just means your current config80.dat file got corrupted (somehow) and it would surprise me if it was fixable.

 

 

[mjbolzan]

As of Sunday, i downgraded to 8.1.626.1 and restarted. i removed the second proactive script and put the usb stick back in the original proactive script, i.e. everything is now back to the way it was before the upgrade.

 

scripts apparently ran all right but two issues--

 

01) i could not connect the console to the engine (get ~127.0.0.1). had to manually stop and start the engine (system prefs did not work) using

 

sudo launchctl unload /Library/LaunchDaemons/com.retrospect.launchd.retroengine.plist

 

sudo launchctl load /Library/LaunchDaemons/com.retrospect.launchd.retroengine.plist

 

02) the stick backed up as part of the original script but showed in the retrospect activities area as part of the now deleted script. when i click the "log" tab for the activity, the log display is completely blank.

 

if i open the separate log window, i can see all of the log detail for the runs last night, including for the original stick.

 

i'll see what happens tonight.

[Maser]

So -- now that you have reverted to 8.1 -- do you have the option to "remove" the USB stick as a Source (which was the start of all the problems, IIRC)?

 

That appears to not be an option in 8.2, so either 8.1 had a bug that allowed you to do this when it shouldn't have or 8.2 has a bug that *doesn't* allow you to do this when you should be able to.

 

 

I still think your config80.dat file is likely corrupt and you might (unfortunately) have to start clean again.

[mjbolzan]

So -- now that you have reverted to 8.1 -- do you have the option to "remove" the USB stick as a Source (which was the start of all the problems, IIRC)?

 

No. The option is only available when retrospect marks the volume with a tilde.

 

i just deleted the second USB stick which was a test performed earlier. it was not mounted in the finder, retrospect had it marked with a tilde. the delete worked.

 

i re-inserted the stick. it shows in the finder, it shows as available in retrospect. normal and usual behavior as other testers have reported before and which i saw too.

 

I still think your config80.dat file is likely corrupt and you might (unfortunately) have to start clean again.

 

maybe. it sure would be nice if there was a config export and import. i would love to be able to start with a template config rather than invent everything from scratch.

 

anyways, i'm going to see how it runs tonight. i really think it's a retrospect software issue....

[Maser]

So -- now that you have reverted to 8.1 -- do you have the option to "remove" the USB stick as a Source (which was the start of all the problems, IIRC)?

 

No. The option is only available when retrospect marks the volume with a tilde.

 

 

So, -- in 8.1 -- what steps can you take to *always* have a USB stick be marked with a tilde?

 

 

(I can throw 8.1 on a test box here to see if I can duplicate it, but I'd want to reproduce your steps...)

[mjbolzan]

So, -- in 8.1 -- what steps can you take to *always* have a USB stick be marked with a tilde?

 

the problem is i can't make this happen. the issue only appeared is 8.2. a proactive script would run; retrospect would mark the USB stick with a tilde (unavailable), but the stick was still mounted and completely available in the finder.

[Maser]

So, I guess you have two options: hope that "8.3" address this non-reproducible problem (unlikely because QA would need to be able to replicate it to fix it) or start with a clean config80.dat file (a better option.)

 

I wish I could have helped by reproduce this, but it's not happening here...

[mjbolzan]

So, I guess you have two options: hope that "8.3" address this non-reproducible problem (unlikely because QA would need to be able to replicate it to fix it) or start with a clean config80.dat file (a better option.)

 

i'm going to run a few more days to see if retrospect is stable. i'm not going the config route unless i have some other evidence of something wrong.

 

I wish I could have helped by reproduce this, but it's not happening here...

 

Is there any option for turning on more extensive logging?

 

Also, I can mail the config.dat file and the prefs to someone. Maybe if they see it, they can see something.

[Maser]

 

Is there any option for turning on more extensive logging?

 

Also, I can mail the config.dat file and the prefs to someone. Maybe if they see it, they can see something.

 

 

I believe this is in the manual, but if you stop the engine, you can then "show package contents" for:

 

/library/application support/retrospect/RetrospectEngine.bundle

 

and edit contents/macos/retro.ini

 

The "Set<>Logging=3" can be changed up to 7 (I think) for whatever you want to try to log, save the file and then restart the engine.

 

How much of this advanced logging is readable is up to you. I've done it in the past and it's never really shown me anything I could decipher.

 

 

And sending somebody else your config80.dat file doesn't really matter -- QA has to be able to replicate the problem on a clean config80.dat file to fix it.

 

Nobody has ever said that 8.1 didn't have enough bugs in it to corrupt existing config80.dat files and carry on that corruption to 8.2

 

 

[mjbolzan]

Is there any option for turning on more extensive logging?

 

I believe this is in the manual, but if you stop the engine, you can then "show package contents" for:

 

/library/application support/retrospect/RetrospectEngine.bundle

 

and edit contents/macos/retro.ini

 

The "Set<>Logging=3" can be changed up to 7 (I think) for whatever you want to try to log, save the file and then restart the engine.

 

Thank you for this. i had asked earlier in the thread for this info but you are the first to give me a lead on this.

 

If it is in the manual, i can't find it. It should be documented somewhere.

 

the info you provided isn't strictly accurate but it was close enough to allow a google search to come up with this post in the retrospect forums.

 

 

as seen in the retro.ini file you pointed to, there are 8 variables. would be nice to know what each controls--

 

SetFoundationLogging=3

SetUILogging=3

SetAppLogging=3

SetDevicesLogging=3

SetEngineLogging=3

SetVolumesLogging=3

SetBackupSetsLogging=3

SetNetworkingLogging=3

 

further down in the thread, there is info about how to turn on proactive script logging. Creating the file turns on the logging.

 

NOTE: I fixed one of the commands below to make it more unix-accurate. i am not a unix maven though.

 

Steps:

 

1. Open terminal, and type the command:

 

cd /Library/"Application Support"/Retrospect

 

2. Still in terminal, type the command:

 

touch proactive_backup_log.utx

 

3. Stop and start the engine.

 

4. Open the file with some text editor and notice all kinds of information.

 

Also, I can mail the config.dat file and the prefs to someone. Maybe if they see it, they can see something.

 

And sending somebody else your config80.dat file doesn't really matter -- QA has to be able to replicate the problem on a clean config80.dat file to fix it.

 

I understand QA has to be able to replicate it. However, I'm asking if someone can look in the file and

 

- see if it looks right.

 

- understand what is in it.

 

If that cannot be done, that's a documentation problem. It means to me that

 

- how the program builds and maintains the file is unknown.

 

- how the program actually works is unknown.

 

sigh.

 

i'll probably turn on the proactive logging in 8.1 just to see what comes out.

[mjbolzan]

i'm going to run a few more days to see if retrospect is stable. i'm not going the config route unless i have some other evidence of something wrong.

 

Sigh. The engine would not stay up. I re-upgraded to 8.2. Still no dice. Tried config restores. Still no dice.

 

Blew away the config. Tried to add media set files. Every time i tried to add the current file set (2), the engine crashed.

 

That should never happen.

 

Put in the previous file set (1), added it, did an immediate backup.

 

This morning, i recreated my rules. i blew away file set (2), created a new (2), and have started a manual backup to it. It will take more than a day.

[mjbolzan]

well, i've rebuild my retrospect config on 8.2.

 

the problem recurs. the proactive script runs and USB stick carryon4a does not get backed up. it is available in retrospect before the script runs. it is not available after the script runs.

 

i can stop and start the engine, making carryon4a available in retrospect, and manually back it up just fine.

 

I'll increase the log level and see if i can find anything useful.

[CallMeDave]

...the proactive script runs and USB stick carryon4a does not get backed up. it is available in retrospect before the script runs. it is not available after the script runs.

 

 

You've indicated in a single post that there was another physical USB device in use; do _both_ physical USB devices exhibit the _same_ behavior? Interchangeably?

 

You've indicated that the USB device "is directly plugged in to the USB port on the left side. it is always in that port."

Have you tried it with the USB device in a _different_ port?

[mjbolzan]

You've indicated in a single post that there was another physical USB device in use;

 

Usually, no. i think i tried a second device at the same time at your behest.

 

do _both_ physical USB devices exhibit the _same_ behavior? Interchangeably?

 

i believe the second device worked. it also does not have a dmg on it that is getting mounted and backed up.

 

Have you tried it with the USB device in a _different_ port?

 

I'll try that tonight.

 

 

[mjbolzan]

Have you tried it with the USB device in a _different_ port?

 

i tried it in the other port and with increased levels of logging. it worked, sort of.

 

it tried first around 11 pm and got the unavailable message--

 

> Can't access volume Carryon4A, error -1102 ( drive missing/unavailable)

 

i know the drive was mounted. retrospect showed it available as of 10:30 pm.

 

5 hours later, & 4 hours after the last other source successfully backed up, retrospect tried again, found the drive, and backed it up.

 

i'm putting it back in the original port and seeing what happens tonight.

 

the logs have no useful information; lines from around the time of the backup had rolled off. I'm increasing the number of lines retained.

[Maser]

If you are going with the possible problem being the port on your engine machine...

 

Do you have another Macintosh you can install the engine on to see if the problem continues using the original stick, too?

 

Or what if you put the same .dmg on the *other* USB stick and mount it like you are on the original stick?

[mjbolzan]

i'm putting it back in the original port and seeing what happens tonight.

 

everything worked last night.

 

If you are going with the possible problem being the port on your engine machine...

 

not my theory. doesn't seem to be the case.

 

Do you have another Macintosh you can install the engine on to see if the problem continues using the original stick, too?

 

i do have another mac that i could try this on. right now though, since everything worked last night, I'm going to leave alone and monitor.

 

Or what if you put the same .dmg on the *other* USB stick and mount it like you are on the original stick?

 

will leave alone. see above. this all worked for years the way it was.

 

[CallMeDave]

this all worked for years the way it was

 

Which is why failing hardware is a reasonable explanation...

[mjbolzan]

Which is why failing hardware is a reasonable explanation...

 

I might agree if it failed all of the time, or if a manual backup failed, or if it failed in the finder too, or if the failure wasn't reasonably contemporaneous with the 8.2 install....

 

the backup worked again overnight. I'll report back if it fails again.

[Maser]

Considering it *did* fail once with a clean config file (but seem to be working after that), it does sound more like a random hardware issue, rather than a specific bug in Retrospect.

 

I was going to suggest that if you have another USB drive, that you format it exactly like the first one (same name and partition) and put your mounted .dmg file on it, etc...

 

Just to rule out problems with that specific USB stick, too...

[CallMeDave]

if the failure wasn't (weren't -Editor) reasonably contemporaneous with the 8.2 install....

 

 

Regression testing is the easiest thing to do (well, after testing with a fresh, known-good test-bed). Fall back to 8.1 and leave all other variables untouched. If it fails, even once, it's unlikely to be a version change defect.

 

This is not to say that there aren't a whole host of oddities and defects in the current shipping product; lots of reports of volumes misbehaving in the Source list and Members misbehaving in Disk Media Sets.

[mjbolzan]

carryon4a did not back up last night. did a manual backup just now.

 

only thing unusual; i changed the error reporting from 5 back to 3.

 

will see what happens tonight.

[CallMeDave]

carryon4a did not back up last night. did a manual backup just now.

 

And?

 

Why did it not back up last night? Did it log the volume unavailable error? Was the volume marked as offline? How did you do a manual backup if the volume was offline? Did you remove/reinsert the USB device? Why aren't you providing details of what you are doing and what you see when you do it?

[mjbolzan]

Why did it not back up last night? Did it log the volume unavailable error? Was the volume marked as offline?

 

i don't know. it just didn't. volume was marked with a tilde this morning. it was available just before the backup ran. no log messages of any kind.

 

How did you do a manual backup if the volume was offline?

 

i stopped and started the engine. volume now available. ran a script manually to back it up. this work-around is described earlier in the thread.

 

Did you remove/reinsert the USB device?

 

No.

 

Why aren't you providing details of what you are doing and what you see when you do it?

 

I thought this stuff was already described earlier and don't wish to recapitulate it. Right now, all I'm doing is watching to see for occurrences of the problem.

 

sometimes retrospect works; sometimes it doesn't. it's not giving me any clues. maybe inspiration will strike.

 

i have some thought it has to do with whether the data is already backed up under 8.1 in the mediaset in question. since these rotate weekly, that's another variable.

[CallMeDave]

I thought this stuff was already described earlier and don't wish to recapitulate it.

 

Discussed, sure. Reproducible or reliable steps detailed? Not so much.

 

volume was marked with a tilde this morning. it was available just before the backup ran.

 

Timeline, please?

Just before the backup ran was also this morning?

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

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

 

 

sometimes retrospect works; sometimes it doesn't. it's not giving me any clues.

 

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?