NMM SQL Restore fails due to missing Writers XML file

Hi,

That is the problem, you don't have a valid saveset for the metadata, Please note that NMM will restore first the metadata, so it can read it and gather the required information about the snapshot to be restored, the writer and files to be restored. If there is no metadata NMM won't be able to restore.

the Metadata (.xml file, name should be something like: C:\ProgramData\EMC\NetWorker\LG_VSS_CLIENT136942188.xml)

I recommend you do the following:

Try to run a new backup and let's see if you can restore afterwards?

Can you restore from a cloned saveset or you dont have clones ???

As the writers.xml is not browsable please scan the volume to populate this saveset.

Hope this helps you. Waiting your updates.

Thanks,

Ahmed Bahaa

Hi Chris,

During an NMM backup (doesn't matter which application you are backing up) the first files to be generated are the .xml files.

These are the wrietr metadata or also called BCD, see below. These are  XML documents created by a requestor (using the IVssBackupComponents interface) in the course of setting up a restore or backup operation. The Backup Components Document contains a list of those explicitly included components, from one or more writers, participating in a backup or restore operation. It does not contain implicitly included component information. In contrast, a Writer Metadata Document contains only writer components that may participate in a backup.

Basically these files will contain a detailed information of:

- Path for the writer files

- Characteristics of the writer configuration

- Status of the writer and his components, such as DB, etc.

So during the backup, the first step is to generate these files, this is done by nsrsnap_vss_save.exe, in fact you can create them yourself by running nsrsnap_vss_save -G

IMPORTANT: These files won't help you to restore a backup, this is just for your information so you can understand what these files are for.

So once these .xml files are generated the rest of the backup procedure is carried out, VSS freezes the DB, tale the snapshot, thaw, etc etc...and eventually rolls the files to tape (or backup device), and important as well is the coverset (VSS:\), this we could say is kind of an index of the snapshot itself, but only at NetWorker level. Without these 2 components (xml file sand VSS) you won't be able to restore.

Logically the first files to be backed up (or rolled over to tape) should be the xml files, as without those files you can't do anything, in other words backup will not be consistent, so you will just have data on tape that you cannot longer use.

Then the data (snapshots of the application you are backing up) are rolled over to tape (this also depends on the snapshot policy you have assigned).

For the restore process, NMM/NetWorker will first restore the XML files, so that the writers can understand what data are we trying to restore, so steps should be:

1.- Restore XML files (MetaData)

2.- Writer "reads" that file and now is aware of what data we are talking about and what to do with it

3.- NMM starts pulling data from backup device

4.- Writer starts restoring files into the appropriate path as per xml files

5.- VSS performs post-restore operations.

This is a high level overview of the restore process to have a betetr understanding before I continue with the answer.

I don't really understand what you said by "I marked SAL and VSS to be retained), I suppose you are talking about the retention policy? that is set at client level, not at saveset level.

Also the xml files are usually recoverable just after the backup, same for VSS:\ this retention is set by PowerSnap during the backup, and it's linked to the retention of the application saveset, in this case APPLICAITONS:\SqlServerWriter.

So first, to restore we need to ensure that we have a consistent backup, for it check these savesets:

APPLICATIONS:\SqlServerWriter

VSS:\

C:\Program data\EMC\NetWorker\LG_VSS....

index.

Having these 4 savesets at the same time (same backup) you should be able to restore, but you can also scan those savesets in to be sure that all are browsable.

To see what is going on, can you please attach the nmm.raw?

Thank you.

Carlos.

Carlos,

Thank you for your help!  I am on the same page with you as far as the basic high level process of how the backup takes place.  I am normally able to restore the NMM backups that i take with no issues.  But in this case here is what happened.

1) i took an NMM SQL backup on 4/7/12.  That completed ok and there were no errors.  All 4 savesets you mention above were present and restorable.

2) on 5/5/12, my sql admin determined that there had been data lose due to an application issue.  he was going to do a restore from the 4/7/12 backup, but it was going to be some time before he could do that.

3) the 4 savesets were set to expire on 5/7/12 (client retention policy).  So i manually set the retention of those savesets to be 6/30/12 using the nsrmm utility.  the retention of the "APPLICATIONS:\SqlServerWriter", "VSS:\" and index savesets were set with no issues.  But the "C:\Program data\EMC\NetWorker\LG_VSS...." saveset would not let me change the retention date.  Before i could figure out what the issue was, the "C:\Program data\EMC\NetWorker\LG_VSS...." saveset was removed from the disk storage device.

4) The storage device is a adv_file type and automatically overwrites reclaimed space, so i have no way of "re-scanning" to reindex the data as you can do with tape.

So i am missing the LG_VSS.....xml file, but i have the other 3 savesets.  I only need 4 data files from the backup, i do not even have to do an NMM SQL type restore.  If i could do a directed restore of just the 4 data files that would work as well.

That is why i asked if there was a way to rebuild the xml file and get the restore to use it in any way.

The frustrating part is that i have the actual data, it is just the metadata that is lost.  There must be some way to get the data from the storage device and parse through it to access the actual DB/transaction Log files it need.

When i try to to any type of restore (NMM SQL or directed), the restore process first tries to restore the xml metadata/writers file and fails at that point.  Nothing else is tried.  That is clear from the logs.

Any suggestions would be appreciated.

Thanks,

Chris

Hi Chris,

As far as I know there is no way to restore the data if you don't have the MetaData (xml files). You cannot generate the metadata for the data already backed up, the new metadata will point to different files, so backup with no metadata is useless.

Anyway would be interesting to check the daemon.raw on the date when the nsrim delete the xml files, as those should have not been removed.

I'll give it a think, but I'm afraid you won't be able to restore any of that data, sorry about that.

Thank you.

Carlos.