Jump to content

scanning incomplete, error -1010 (API request bad)


Recommended Posts

RAID 1 (mirror) configurations are very hard to troubleshoot when there are problems. One of the drives could have bad sectors and the other might not. Most RAID drivers, on read requests, will return the first data to come from either drive, so it's possible a bad sector on one drive might not always cause an error, which will only be reported when both sectors error out. Many RAID drivers will try to recover a bad sector on one member by rewriting or even remapping the sector. Errors can be further masked by the automatic sector remapping that some drives do when soft errors start occurring.

 

The only way to check for bad sectors on a RAID 1 volume is to split the mirror, check each drive individually, then pick which drive is to be the RAID primary, and re-establish the mirror and allow the mirror to rebuild.

 

Russ

Link to comment
Share on other sites

I did chkdsk. Here are the results:

 

Checking file system on C:

The type of the file system is NTFS.

 

A disk check has been scheduled.

Windows will now check the disk.

Cleaning up minor inconsistencies on the drive.

Cleaning up 1270 unused index entries from index $SII of file 0x9.

Cleaning up 1270 unused index entries from index $SDH of file 0x9.

Cleaning up 1270 unused security descriptors.

CHKDSK is verifying file data (stage 4 of 5)...

File data verification completed.

CHKDSK is verifying free space (stage 5 of 5)...

Free space verification is complete.

CHKDSK discovered free space marked as allocated in the

master file table (MFT) bitmap.

Windows has made corrections to the file system.

 

732411350 KB total disk space.

581498836 KB in 236797 files.

74980 KB in 18582 indexes.

0 KB in bad sectors.

358822 KB in use by the system.

65536 KB occupied by the log file.

150478712 KB available on disk.

 

4096 bytes in each allocation unit.

183102837 total allocation units on disk.

37619678 allocation units available on disk.

 

Internal Info:

80 1a 04 00 9e e5 03 00 e8 37 05 00 00 00 00 00 .........7......

a0 06 00 00 02 00 00 00 1a 09 00 00 00 00 00 00 ................

e2 77 dd 13 00 00 00 00 5c 81 7a a2 00 00 00 00 .w......\.z.....

4a 88 7a 17 00 00 00 00 26 7a dd fb 17 00 00 00 J.z.....&z......

3c da df 13 00 00 00 00 f8 29 c8 de 18 00 00 00 <........)......

20 1d d3 b2 00 00 00 00 e8 3f 07 00 fd 9c 03 00 ........?......

00 00 00 00 00 50 df a3 8a 00 00 00 96 48 00 00 .....P.......H..

 

so there were a few inconsistencies found.

 

Alas, I get the same error as before.

Anyone have any more ideas?

Link to comment
Share on other sites

One item in the filesystem repair might be an issue:

 

CHKDSK discovered free space marked as allocated in the master file table (MFT) bitmap.

The interesting part about your problem report is that it "just recently started happening." So, Retrospect worked fine with this RAID 1 volume until recently.

 

Did anything (hardware, software, drivers) change?

 

It may be that the filesystem issue caused some mystery garbage block from space to drop on some critical structure, and Retrospect isn't able to do its filesystem traversal.

 

Is it possible for you to boot from something else (perhaps a CD), copy this particular folder off somewhere (to another drive), delete the folder, and then copy it back? That should eliminate any filesystem issues.

 

Russ

Link to comment
Share on other sites

Nothing has changed that I know of.

I tried this: I copied the folder on that machine, then deleted the other folder, renamed the copy, recreated shares, etc. This should have put it on a different part of the disk.

 

Then did the manual backup and got the same thing.

Anyone have any other thoughts?

Link to comment
Share on other sites

Ok, next thing to try would be to see if it's a pathname length issue.

 

What happens if that directory is moved to a higher level. Can it be backed up then?

 

If this works, you know it's a pathname length issue.

 

Or perhaps it is an odd filename problem or some such. Have you tried to isolate a particular file or subdirectory that is causing the problem?

 

I'm stumped. But using the approach above might help you find the problem so that you could submit a bug report and get it fixed.

 

Russ

Link to comment
Share on other sites

pathname:

c:\data

 

Can't get much simpler than that.

I'm stumped to.

 

It would be nice if the current owner's of the Retrospect product would chime in about now.

 

I've no way to know about the filenames, because the error is so vague.

Link to comment
Share on other sites

It would be nice if the current owner's of the Retrospect product would chime in about now.

You may be under the misconception that these forums are the way to contact Retrospect support. They are not. From the Retrospect Forum Rules / Terms of Use:

 

This forum is a community based self help tool for users of the Retrospect Backup Software and other EMC Insignia Products.

 

While this forum is monitored by members of the EMC Technical Support team, it is not possible to reply to all questions and threads. This forum is not an official method for contacting technical support. EMC employees are under no obligation to reply to individual forum posts. If you need immediate technical support, you can contact technical support directly at http://www.emcinsignia.com/contactsupport

Now, admittedly, the "EMC" part needs updating after the recent sale, but we are just users like you are.

 

If you want a response from Retrospect support, you need to contact them, and these forums aren't the way to do that. The updated contact information link is:

http://www.retrospect.com/contactsupport

 

Russ

Link to comment
Share on other sites

Here's what I would suggest:

 

I've no way to know about the filenames, because the error is so vague.

Your testing seems to have eliminated a RAID 1 data issue.

 

You indicate that the pathname is simply "c:\data", but it isn't clear from that response whether you have a single directory with all of the files (hmmm.... perhaps there is some issue with the number of files in the directory, and that could correlate with why the problem just started recently) or whether there are subdirectories below that. My point about pathname length would only apply if there are lots of nested subdirectories below c:\data .

 

You could duplicate that directory and then do a binary search (delete half the files, see if the remaining half can be backed up, etc.) to narrow down if it's a single file that has the problem.

 

That would also test whether it's a "number of files in one directory" issue that Retrospect can't handle.

 

For faster testing, you could define that duplicated directory as a Retrospect subvolume so that the entire volume doesn't have to be scanned. Test first that the error is seen when just having this directory as a subvolume.

 

Another approach would be to use a trial license of Retrospect 7.7 to see if it's a bug fixed by that version. A caution, though: Once you use Retrospect 7.7 with a backup set, you can't go back to Retrospect 7.6. So, you will have to do your testing with a new backup set.

 

Russ

 

Edited by Guest
testing with subvolume
Link to comment
Share on other sites

  • 4 weeks later...
hmm. Well my support has run out. It is ashamed I'll have to pay for it to fix something that appears to me that it may be a Retrospect bug.

If it indeed is a bug, you will get a refund.

The price for one support incident is VERY reasonable. (Or it was last year, when I last paid for one).

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...