Hello Hrvoje,

• We are backing up on a DataDomain using DDboost.
• File system is a windows 2008 (NTFS)
• mminfo:

     D:\>mminfo -avot -q "ssid=399334300"

      volume        type   client           date     time         size ssid      fl   lvl name

     DataAgentCHU.002 Data Domain mscs-bechu-0072.media.int 1/8/2014 3:07:21 PM 341 GB 399334300 cb full E:\

     D:\>mminfo -avot -q "ssid=3352129408"

      volume        type   client           date     time         size ssid      fl   lvl name

     DataAgentCHU.002 Data Domain mscs-bechu-0072.media.int 1/8/2014 4:32:16 PM 63 GB 3352129408 cb full G:\

• Backup was done with client direct File Access on the DataDomain  with Networker Agent 8.1.
• We try to restore on the same box where backup was taking from
• I will try without the mount option

Thanks

Greg

8.1 or 8.1SP1 (and which exactly version/build)?

What do you use for backup target (your tag says cifs, but it is direct DD cifs or AFTD?  What was the file system which you have backed up?  Can you show us mminfo output for savesets which shows this backup (mminfo -q ssid= -S)? Can you describe how backup was done?  Are you doing this on the same box where backup was taken from?  Can you try to do this without mount option and somewhere else on the system? (use -r for that)

Hi Greg,

Can you do:

mminfo -q ssid=399334300 -S

mminfo -q ssid=3352129408 -S

We just wish to see if this is seen as BBB backup and there should be extra properties associated with this ssid visible when using -S parameter in output of mminfo command.  If it is not, it might explain why it is not able to read it.

Hi,

I've run again some test:

• Command line from the same box where backup was taken from:

          recover -mount -S ssid XXXX

          Networker mount the virtual file system and I can browse it using dir \\?\km123456\\. But I' not able to copy           something and I'm not able to browse the virtual file system in Windows explorer.

• Command line from Networker server:

          recover -mount -S ssid XXXX

          91651:recover: Successfully established AFTD DFA session for recovering save-set ID '1696606651'.
          38008:recover:AttachVHD: OpenVirtualDisk failed with error 0x570. Error Message: The file or directory is            corrupted and unreadable.

          No file system mounted at all.

Here is the result of the recover command without the mount option (runned on Networker server):

     D:\Program Files\Legato\nsr\bin>recover -vvvv -S 1696606651 -R datadomain.mscs-begia-0004.media.int -i R

     Initiating remote recover to datadomain.mscs-begia-0004.media.int from server mscs-begia-0004.media.int, this may take      a while...

     Attempting to start recover session with server.

     Started recover session with server

     91651:recover: Successfully established AFTD DFA session for recovering save-set ID '1696606651'.

     38008:recover:AttachVHD: OpenVirtualDisk failed with error 0x570. Error Message: The file or directory is corrupted and      unreadable.

So the same errors appears.

Thanks for your help

Greg

C:\WINDOWS\system32>mminfo -avot -q "ssid=1696606651" -S

ssid=1696606651 savetime=3/12/2014 10:32:42 AM (1394616762) mscs-bechu-0072.media.int:E:\

  level=full   sflags=vF       size=354588557316 files=1          insert=3/12/2014

  create=3/12/2014 complete=3/12/2014 browse=3/26/2014 11:59:59 PM retent=3/26/2014 11:59:59 PM

  clientid=9f09c2c7-00000004-4e523694-4e54f7da-19f72500-6f1b00b5

          *backup start time: 1394616762;

         *BBB_LEVEL: 0;

         *BBB_START_VOLUME_OFFSET: 266240;

         *BBB_VHDX_BAT_LENGTH: 2097152;

         *BBB_VHDX_BAT_OFFSET: 2097152;

          *BlockBasedBackup: Yes;

     *NSR_VSS_SHADOWCOPY_SET: {80C6C8B2-07AF-46B2-8EB2-3C7FA290A5E1};

*ss data domain backup cloneid: 1394616763;

*ss data domain dedup statistics: \

"v1:1394616763:355926181252:223804527742:153051782871";

*ss index lookup for renamed dir: Enabled;

        *ss index time range: "1392291999:1392291999";

                  *VHDX_GUID: {1786E6C1-F797-4721-928E-662F95D1C011};

                  *VHDX_PATH: \

"..\\..\\08\\90\\9b339625-00000006-652029bb-532029bb-729d2500-de1b00b5";

                *VOLUME_GUID: 9d97735a-883b-11e0-abf5-806e6f6e6963;

                       group: DATA_chu_0030;

  Clone #1: cloneid=1394616763  time=3/12/2014 10:32:43 AM    retent=3/26/2014  flags=F

    frag@         0 volid=4228441675 file/rec=       0/0     rn=0 last=3/12/2014

I thought you need to use small r for destructive restores, but perhaps you wish to be not destructive until not able to browse data.  It is strange that you get different outputs on server and clients (if they are both same OS and same NW version and build).  Can you also check nsrinfo for that one?  Not 100% sure, but according to docs it should be something like:

nsrinfo -t 1394616762 -n bbb mscs-bechu-0072.media.int

The output you gave for mminfo, confirms that this is big bad boy (bbb) so we can rule out any issue there.

According to docs, if you do recover -S 1696606651 this should already mount this snapshot (admin guide page 642).  You used -mount option which I do not see example for. 

No additional responses on this??  I have the same problem - Unable to open handle to the mounted volume..... Reason The system cannot find the file specified.

AFTDs to DataDomain via CIFS, CIFS share exists, permissions are everyone = FULL access.... BBmount path is correct:

recover -S 3349613

Attempting to start recover session with server.

Started recover session with server

91651:recover: Successfully established AFTD DFA session for recovering save-set ID '3349613'.

102010:recover:

Unable to open handle to the mounted volume \\?\km12224, Reason The system cannot find the file specified.94807:recover: Could not get volume information for 'F:\nsr\tmp\BBB\CLIENT01\3349613\'

BBImage : [\\DATADOMAIN01\NW_2\R.30D.02\11\24\64eefcfa-00000006-00331c6d-53331c6d-0001b190-b5581c1c]

CreateFile failed on [\\DATADOMAIN01\NW_2\R.30D.02\11\24\64eefcfa-00000006-00331c6d-53331c6d-0001b190-b5581c1c]. err 1326

[km10708] not found, using device number 0

Successfully associated [km10708] with \Device\BBMount\BBMount0.

BBMount device [0] in use, trying next free device : [1]

Successfully associated [km10708] with \Device\BBMount\BBMount1.

BBMount device [1] in use, trying next free device : [2]

Successfully associated [km10708] with \Device\BBMount\BBMount2.

BBMount device [2] in use, trying next free device : [3]

Successfully associated [km10708] with \Device\BBMount\BBMount3.

BBMount device [3] in use, trying next free device : [4]

Successfully associated [km10708] with \Device\BBMount\BBMount4.

BBMount device [4] in use, trying next free device : [5]

Successfully associated [km10708] with \Device\BBMount\BBMount5.

BBMount device [5] in use, trying next free device : [6]

Successfully associated [km10708] with \Device\BBMount\BBMount6.

BBMount device [6] in use, trying next free device : [7]

Successfully associated [km10708] with \Device\BBMount\BBMount7.

Successfully created symlink:

--> [\\?\km10708\]

Use "dir \\?\km10708\\" to list volume's content

Use "bbmount /u \\?\km10708" to unmount the volume

Incremental chain dump:

     |

    \|/

\\DATADOMAIN01\NW_2\R.30D.02\11\24\64eefcfa-00000006-00331c6d-53331c6d-0001b190-b5581c1c

    /|\

     |

  [base]

Save-set ID '3349613' has been mounted for recovery at 'F:\nsr\tmp\BBB\CLIENT01\3349613\'

Performing a file level recovery of save-set ID '3349613' from mount point 'F:\nsr\tmp\BBB\CLIENT01\3349613\'.

A new command prompt with title 'File level recovery from save-set ID 3349613' has been spawned for file level recovery.

Exit that command prompt to continue with cleanup operation.

Command prompt opened for file level recovery exited with exit code = 1

102010:recover:

Unable to open handle to the mounted volume \\?\km10708, Reason The system cannot find the file specified.101566:recover: Error: Unable to

unmount the save-set.

102669:recover: Cleanup  of save-set ID '3349613' was NOT successful.

Recovery of BBB saveset 3349613 completed successfully

Total time taken for recovery: 0 hr(s) 05 min(s) 24 sec(s)

Did you open a ticket with support? I do not use this so I can't share much wisdom, but I see err 1236 which IF parsed from typical Windows subsystem would suggest issue with logon failure for CIFS.  However, only support can tell you exactly what it is.

You tested 2008R2 and NW 8.1.0.x and 2012 and 8.1.1.x, but our environment is 2008R2 and NW 8.1.1.x.

So is BBB for 8.1.1.x not compatible with 2008R2 i.e., creates the VHDX or do I need to downgrade to 8.1.0.x with the "enhanced feature" of a working product?

This BBB idiosyncrasy of 8.1.1.x is not well documented if myself and an EMC SME did not catch it.

Sent from my iPhone

I appreciate you clarifying this, but would like to suggest maybe a small footnote in NetWorker documentation stating this caveat. An upgrade from NW 8.1.0.X to 8.1.1.X would lead me to believe it is a relatively minor update with little to no OS level impact on functioning or not functioning.

I’ll set up a 2012 storage node and test restores.

Thank you