Jump to content

Problem with a component, Error -1101


Recommended Posts

Hello,

I'm new to this product, and have read all that I can find about the situation, but I can't seem to find where this error is coming from. I'm hoping one of you all will be able to help me sort this out.

 

The error we receive is: Component "FSRM Reports" backup failed, error -1101 (file/directory not found).

 

Questions:

1. In retrospect-speak, what is a 'component'?

2. Does this error mean that there is (or rather, should be) a directory called FSRM Reports somewhere in my backup set?

3. Where can I find what this error refers to in Retrospect itself? I've tried searching for the terms: "FSRM", "FSRM Reports", and "Reports" and have not been able to find anything.

4. On the forums, I found one other post that mentioned about error 1101, but the support given was that it is a message from windows, and not from Retrospect. So now I'm confused, is the error message that retrospect is emailing me from retrospect, or from windows?

 

It's not a major issue, but it is awfully aggravating to get this message in my inbox every day. A resolution would be fantastic!

 

Thanks for your time,

Link to comment
Share on other sites

  • 1 month later...

We have a similar issue with Retrospect 7.0 on a Windows 2003 Small Business Server. The server is backing up a second Windows 2003 R2 (Standard) Server in the domain, and gives the error mentioned above on every attempt to back up the second server. We just added the second server to the backup cycle, and I'd like to know that I could restore it if I had to!

Link to comment
Share on other sites

"Microsoft File Server Resource Manager"

Does it write reports that are deleted automatically?

 

Retrospect scans the hard drive for file and then starts backing up the files found. If the "FSRM Reports" file is deleted in the time between scanning and the actual backup, you will get this error.

Link to comment
Share on other sites

The FSRM component has not been used or configured on that server. It's a new technology with R2 that I haven't explored much so I'll have to get back with you on specifics, but I don't think that it is generating and deleting a report prior to Retrospect being able to back it up.

 

Our occurrance of the error is coming when Retrospect attempts to back up the System State of the target server; does that indicate something? I'm not sure if I'm "barking up the wrong tree".... :-)

 

Thanks for the reply!

Link to comment
Share on other sites

  • 1 year later...

This is an old thread but there doesn't seem to be an answer. I have just gone through two weeks of pure hell because my Retrospect safety net turned out to have a huge hole in it, which I fell through.

 

The Active Directory became corrupt on the Windows 2003 R2 Standard PDC (which is the only DC) because the log files that were located in the D: partition (since the promotion to DC advised that the logs be on a different partition than the database ... for better recovery) became victim to some file system corruption that occurred. The server would not boot and restoring the System State to a few days prior did nothing to recover from this.

 

These AD logs were not contained in any Snapshot of C:, which supposedly contained the System State, or D:, which was backing up all except cache files. The question yet to be answered by EMC is if the System State in version 7 includes the AD logs when they are not located in the default location of C:\Windows\NTDS. It should, so that they are contained in the C: Snapshot, even though they reside on D:, so that they are archived at the same time as the database that they are supposed to stay in sync with. But even failing that, they should have been included in the D: backup, but weren't.

 

I have been getting this FSRM error since reloading Windows on this server, which is also the Retrospect server. I suspect that it has something to do with the System State backup.

 

The scary part is that now that basic functionality has been restored, which the AD logs left in the default location, a browse of the C: Snapshot shows the NTDS and NTDS\Drop folders, but no log files and no AD database. So I am still vulnerable to another unrecoverable system failure. My Retrospect safety net still has the huge hole in it!

 

Is this a bug that was fixed in version 7.5?

Link to comment
Share on other sites

I don't know what using a Microsoft API is supposed to mean to me. Are you saying that if Retrospect isn't backing up the system state in a way that can be used to recover, that the fault lies in a Microsoft utility that Retrospect uses?

 

The Properties clearly list NTDS (ntds) in the list, yet when I browse that Snapshot all I see is the folder C:\Windows\NTDS and NTDS\Drop, but no files. At the time this Snapshot was taken the log files were on D: but the database was there.

 

During the same backup the Snapshot of D: shows the D:\System\Windows\ADlogs, and ADlogs\Drop, folders but again, no files.

 

Now that I've rebuilt this server and left the AD logs in their default location, the Snapshot still only shows the NTDS folders, but no files.

 

Why are the database and log files not being archived? How can a Domain Controller be restored without this critical component of the system state? As far as I can see, I'm still at risk of not being able to restore this PDC if its AD becomes unrepairable again.

Link to comment
Share on other sites

yet when I browse that Snapshot ...

 

System state data (registry, etc) will never be displayed when browsing the snapshot with Retrospect. Snapshot browser windows do not display registry/system state items. These items are restored when you do a restore entire disk operation. You must restore the entire system state with Retrospect. We do not allow users to pick and select parts of the system state to be restored.

 

To restore a domain controller you must do a restore entire disk operation. The source snapshot should be the one that displays the valid system state in the snapshot properties (usually C:)

Link to comment
Share on other sites

After trying a couple of times to restore the System State only I did a C: restore and got the same problem of AD not starting due to corruption. I went back to the first backup after promoting the server to a PDC, but the results were the same.

 

The tech support I spoke to said that even the current version (mine is 7.0) hasn't been tested to restore when the AD logs are not in the default location. So in this life as a PDC the logs have been left at default.

 

Thanks for the help.

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...