Hi Jim,

I appreciate your frustration, but I think we would need some more information/logs to get to know the root cause of the issue.

Do you have the output of the /nsr/tmp/sg/group_name_folder/

Have you seen any error in Application and/or System event logs If so which ones?

What is the output of running the backup from the client?

Have you run the backup with any debug options?

Have you enabled VSS Traces to find out what is going on with VSS?

This VSS traces can be really big (even 2-3GB), but with good text processor you can easily find out the error messages.

Thank you.

Carlos.

If you just backup certain data from that machine, then you do not need DISASTER RECOVERY save set at all and you can disable it.  Usually, that code is associated with something missing or failing to be found. Right now it is just a pure guess what it could be and it could be loads of things. Last time I saw it I had it on bizztalk server and Winblows guys found some patch for it (which by title had nothing to do with it, but either that or reboot after did a trick). If using MS VSS provider, your best bet is debug output of VSS itself to see where it really fails.

http://support.microsoft.com/kb/887013

Hello,

I have not seen this on the Disaster Recovery save sets, but we have had problems with backing up the passive cluster nodes several times due to services are being installed on shared cluster disks. There is an article at MS that we have used to solve the ERROR=0x80070002 several times. Take a look at it and see if it applies to your environment:

http://support.microsoft.com/kb/980794

/Rickard

Hi all,

The "workaround" from Microsoft is a well known one, and once again this is a VSS limitation.

NetWorker introduces time ago a save command to skip those "missing system files", however I didn't want to mention it here as we are talking about DISASTER_RECOVERY:\ saveset.

That workaround is only for clusters when, for instance, you try to backup a file system of a SQL cluster passive node, and VSS when tryi9ng to backup the registry (System Writer) finds out that the pointer to the file xxx is in fact residing on a shared disk.

As this is the passive node, it doesn't have access to the shared disk, so doesn't have access to that file.

In this particular case I would suggest to run a save -D3 to find out what is the "missing file" or what is the problem with ASR.

Anyway the save command to be set on the client configuration is as follows (note the single quote, double quote):

save -a '"ignore-all-missing-system-files=yes"'

Thank you.

Carlos.

Hey Carlos,

     I am assuming you put this into the "Backup command:" field on the Apps & Modules?  I tried that and still am getting:

savegrp: suppressed 3 lines of output.

77777:save: Added writer Registry Writer to disaster recover backup.

77777:save: Added writer Task Scheduler Writer to disaster recover backup.

77777:save: Added writer VSS Metadata Store Writer to disaster recover backup.

77777:save: Added writer Performance Counters Writer to disaster recover backup.

77776:save: ERROR: Failed to add writer System Writer to disaster recover backup, error=0x80070002.

77774:save: ERROR: Error adding writer to the snapshot set. ERROR=0x80070002.

77775:save: Processing completed for disaster recover backup.

80520:save: ASR Backup..Critical error creating snapshot of ASR critical volumes and cannot continue.

83449:save: Error occured while saving critical volumes.

Hi Jim,

We would need more information about the error, found in the tmp files /nsr/tmp/sg/group_name, also found in Application and/or system event logs and also running debug mode manual save from client.

Also, did you enable VSS traces?

Some times the reboot fixes these kind of errors where some files/folder required for ASR are not created, or it could be for some other reasons but again, to know it we need more information.

Thank you.

Carlos.