Client error (-557) during backup

[bcarillon]

!Trouble reading files, error -557 ( transaction already complete)

 

Can someone shed some light on this error? I'm the most current release versions of the Console, Engine and client software under Mac OSX Leopard 10.5.8.

 

Each and every time I this client is backed up I get the error -557 and the backup does not complete. How can I troubleshoot this? Is it encountering a file that is corrupt?

 

I have repaired permissions, run maintenance w/Onyx and of course re-booted the client to no avail.

 

Thanks

[Maser]

The way I'd debug something like this would be to try to isolate what folder/file is choking things.

 

When do you get this? During the backup? Or during the "scanning"?

 

If it's *during* the backup -- Retrospect backs up things alphabetically, so if you examine what *does* get backed up, that should give you the point where it stopped and you could look at the file/folder where the next files would be.

 

If it's during the *scan* -- that's somewhat harder as it doesn't tell you where the scan is.

 

If that's the case (a scan error), then remember Retrospect is still scanning alphabetically, so you might make sets of "favorite folders" and see which favorite folders contain the file/folder that's barfing.

 

 

And I'm assuming you ran "Verify Disk" with Disk Utility, too? (I can't remember if Onyx does this or not...)

 

[bcarillon]

Here is the info from the log:

 

3/24/2010 6:16:01 AM: Connected to Xxxxxx Xxxxxx

* Resolved container Xxxxxx Xxxxxx to 1 volumes:

Xxxxxx Xxxxxx on Xxxxxx Xxxxxx

- 3/24/2010 6:16:01 AM: Copying Xxxxxx Xxxxxx on Xxxxxx Xxxxxx

>

!Trouble reading files, error -557 ( transaction already complete)

3/24/2010 6:38:29 AM: Execution incomplete

Remaining: 7228 files, 1.7 GB

Completed: 2 files, 129 KB

Performance: 0.1 MB/minute

Duration: 00:22:28 (00:19:13 idle/loading/preparing)

 

Yes, I have verified the disk and it reports that it is okay. Thanks

[Maser]

Not sure -- I don't have any "container" lines in my log. Are you backing up to Tape, maybe?

 

Either way, it did *some* backup (completed), so you should be able to browse the backups to see where the backup actuallly stops.

 

This should help you figure out what the *next file* to be backed up is and maybe help identify the problem.

 

It might be easier to backup that source to a new media set to determine this, too...

[bcarillon]

Thanks Maser... I'm actually backing up to disk. Not sure where the "container" line comes from but all our Macs have it in the log.

 

How do I turn on verbose logging... maybe that would show me which file it's getting the error on. Thanks

[Maser]

(I'm not the one to ask about which logging options show what, unfortunately.)

 

But the logging options *are* located in the retro.ini file at this path:

 

/Library/Application Support/Retrospect/RetrospectEngine.bundle/Contents/MacOS

 

 

 

Now, what changing each of these:

 

 

SetFoundationLogging=3

SetUILogging=3

SetAppLogging=3

SetDevicesLogging=3

SetEngineLogging=3

SetVolumesLogging=3

SetBackupSetsLogging=3

SetNetworkingLogging=3

 

 

To a higher number like 7 or 8 does -- I honestly don't know.

 

 

 

Otherwise, you might do what I suggest -- make a new disk media set and back that client up to it. After it fails, check at what folder it stopped -- then see if you can set that folder as a "favorite folder" and attempt to back that one up only, etc...

[bcarillon]

Good idea Maser, I'll give it a try.

[rhwalker]

Here is the KB article on Logging:

Retrospect 8 Debug logging directions

 

Russ

[bcarillon]

Thanks Russ...

[bcarillon]

Maser, I just set up a separate backup to a test media set for the client giving me this error. Using the same rule etc. it backs up just fine. So now what? Is there a problem with a file in the current media set? Is there a way to recycle just that client and not the entire media set?

 

Thanks

[Maser]

Well, was this a one-time event?

 

What happens if you back up the client to your current set again? Does it crash that set each time?

 

If that was the case, you might consider running a "verify" on that media set and/or rebuilding the catalog for the media set (or maybe just archiving that media set and starting with a new one.)

 

 

You *can* groom out the client's backups, but I'd be surprised if that was the issue as if it crashed *during backup* -- then that would just be when you are appending the incremental changes to the media set (assuming you are using the default settings for backup...)

[bcarillon]

Actually I spoke too soon. The backup did fail with the error -557. I had turned on extra logging for the client but it doesn't show the name of the file it had a problem with. In looking at the backup it not obvious to me that I can find a way to see where it stopped.

 

Any ideas? Thanks

[Maser]

The backup will have backed up the directory alphabetically (ie, applications, then Desktop, then Documents, etc...

 

If you go to "Past Backups" you can select that test backup and "Browse" it.

 

This should tell you where it stopped. Then you should be able to go from there when you drill down in the directory structure where the green check marks should indicate what *is* in the media set.

 

(This will be a lot easier to figure out with the new test backup which only has that one Past Backup to browse...)

[rhwalker]

Taking a completely different approach, you could try to create a new media set (why are they called "Past Backups" but go into "media sets"? hmmm) then do a copy (what used to be called a "transfer") from the suspect media set to the new one. You can use an appropriate filter to omit looking at the bad client's backup data, or perhaps Retrospect might be able to extract the bad stuff too.

 

Left as an experiment for you.

 

Russ

[bcarillon]

When I go to Past Backups and browse the backup I drill down the the "Users" folder but from there it's hard to tell what was the last file backed up and in which users folder. Maybe I'm missing something...

[Maser]

Attached is an example screen shot.

 

I started backing up a Users Favorite folder to a clean media set and then stopped it after a few minutes.

 

When I browse the past backup and drill downward, the *green arrows* indicate was *was* backed up.

 

The program (unfortunately, IMO) shows you the directory of what *could* be backed up (the empty circles), but only the green checked arrows indicate what is actually in the media set.

 

So, in the screen shot, it would mean my backup stopped before getting to that "Skype" folder and if I were to start the backup again (assuming no other changes to the Users folder), the backup would start backing up at "Skype"..

[bcarillon]

Thanks Maser... I have attached the browse window... where do you think the backup quit based on this screen shot? Thanks

[Maser]

There's a bug in 8.1 where the green arrow doesn't always show for the enclosing folder that something *within* the folder got backed up.

 

Is this from your clean media set? With only one backup attempt to it? And no "rule" at play exempting stuff? (I seem to recall from your other thread that you don't back up the entire "Users" folder, so what rules were used on this?)

 

 

Alphabetically, it clearly backed up to "secret-2009-19.01.incx" so it would have to be after that so I'd expand "Sites" to see if it backed up the default "sites" directory stuff (assuming it's not empty)

 

and then expand "mactech" -- my guess is that you need to look inside that folder for green arrows.

 

 

This isn't to say there aren't bugs in 8.1 in Browsing Backups, but that would be my feeling based on this screenshot that it's backed up everything in the "154543" account and it stopped somewhere in the "mactech" account...

 

 

[bcarillon]

Yes, this was from my clean media set... looking at the Sites folder there are some images in that folder on the client that are not shown when I browse the backup. I don't believe they were excluded unless my rule is doing something I'm not aware of. Also, it didn't backup anything in the mactech user folder so it must be failing on a file/folder in the 154543 user folder.

 

I have attached a screen shot of my rule for this backup.

[Maser]

Since it doesn't look like a lot of data, the other thing you can do is *restore* what you backed up to a new folder on another machine.

 

Then browse what got restored and compare that to the source. That may be an easier way to tell you where things stopped.

 

 

You never said if you ran "verify disk" on the source machine or not. If there are directory problems, that will tell you.

 

 

But, based on what you describe, looking at your rules and where it looks like things stopped, it *probably* failed on the "Sites" folder then. (Which is pretty odd as that's just populated with the standard stuff unless somebody actually starts modifying things, but who knows.) Your rule bypasses the "Music" folder, but if you drill down into "Library", everything there (besides the caches) is checked, right?

 

 

You might be able to easily determine if that "Sites" folder is the problem by moving the it to the root level of the hard disk temporarily, then try the backup again.

 

Or just try to make "Sites" a favorite folder and try backing that up only -- if it fails on that, then maybe there's something in there it doesn't like.

 

But if the backup didn't move into "mactech" -- and there *are* files/folders in "Sites" -- I'm fairly confident that the problem is in "Sites" -- if it's not an overall OS directory corruption problem.

 

Run "Disk Utility" on the client first to "Verify Disk". If that checks out OK, then examine "Sites" more closely...

 

 

I ran into something similar today. I tried to add a folder with weird characters in the name as a Favorite Folder and Retrospect refused to do it. When I then tried to browse the folder from the Source --> Browse -- the engine crashed.

 

You might just see if you can "Browse" the Sites folder from the Source window.

 

 

 

 

 

[pjonesvcc]

If it backs up all files before it processes folders, then the Documents folder might hold the culprit. It's a bit odd that it doesn't have a green check mark, isn't it?

[Maser]

I'm fairly positive that it backs up everything alphabetically (not files before folders...)

 

It's a bug (IMO) that the browse window doesn't have an indicator that is a "partial green" for folders that have some files backed up, but not others (ie, if you have a rule that excludes something in the folder.)

 

 

As I don't back up .DS_Store files -- that pretty much means *all* my folders never get the full green check mark, so the browsing requires me to open folders to check this.

 

But the OP could confirm this by just doing a restore of what he backed up if that was the case.

[bcarillon]

Finally got it! I had to repeatedly narrow down the backup using favorite folders until I found the culprit... a corrupt PDF file. Surprised that Retrospect can't handle this type of situation when it encounters a bad file.

 

Thanks for all the replies....

[Maser]

This is the kind of thing EMC should be able to fix. You should send them a copy of the file so they can debug in-house.

 

(If you want to send it to me, I'll be happy to do this...)

 

Out of curiosity -- where *was* the .pdf file?

 

 

[bcarillon]

The PDF was in a folder on the users desktop. I copied the PDF to my Mac and when I tried to open it Acrobat gave me an error (see attached).