[ADSM-L] Odd behavior during CIFS file restore

Folks:
  Now that Paul Zarnowski and his extensive knowledge and experience have 
retired to greener pastures, we need to reach out to the community for some 
insight.

  We have a NetApp appliance that supports our Shared File Service for campus, 
offering both CIFS and NFS shares.  In line with a recent list discussion about 
the problems with NDMP backups, we use two proxy systems for backup (Windows 
Server 2012 R2 for CIFS shares; RHEL 6 for NFS shares).  While we have our fair 
share of issues with the backups, in general this architecture has worked for 
us.

  Recently, though, we had to perform a restore of a directory on a CIFS share 
for a user.  This is outside our normal boundaries, but it was an emergency.  
In the process, we encountered something odd that I can’t explain.  Actually, 
there were 2 oddities.

So, starting with the facts:

   NetApp Filer Version Information        : NetApp Release 9.1P5: Sun Jun 11 
02:26:58 UTC 2017
   SP Client Version 8, Release 1, Level 0.1
   TSM Server Version 7, Release 1, Level 7.200

The restore was not back to the source directory, but rather to a new directory 
created by the user as a target for the restore.  As such, we initially started 
out using UNC names for both the source AND the larget directory, namely

 Dsmc restore -optfile=“share.opt” -latest -subdir=yes 
“\\share.files.cornell.edu<http://share.files.cornell.edu>\vol\user\source 
dir\*” 
“\\share.files.cornell.edu<http://share.files.cornell.edu>\vol\user\target dir”

Obviously, the actual UNC names differ, but the “ “ in both the source and 
target directory names did exist.

Oddity 1: Issuing the command as written resulted in the SP client attempting 
to restore to the source directory, for we got a prompt about overwriting an 
existing file.  However, SP client wrote no message of any kind about not being 
able to access the target directory to either standard output or the 
dsmerror.log.  It just tried to restore back to the source directory.

Oddity 2: it appears that the “ “ in the target directory was causing the 
problem.  That is, we eventually got the restore to work, via trial and error, 
via the following sequence
Net use Z: 
“\\share.files.cornell.edu<http://share.files.cornell.edu>\vol\user\target dir”
Dsmc restore -optfile=“share.opt” -latest -subdir=yes 
“\\share.files.cornell.edu<http://share.files.cornell.edu>\vol\user\source 
dir\*” “z:\”

However, any attempt to set the drive letter to a higher level directory 
failed, i.e.
Net use Z:  “\\share.files.cornell.edu<http://share.files.cornell.edu>\vol\user”
Dsmc restore -optfile=“share.opt” -latest -subdir=yes 
“\\share.files.cornell.edu<http://share.files.cornell.edu>\vol\user\source 
dir\*” “z:\target dir\”
failed.

Has any one seen anything like this?

Thanks,
Bob T



Robert Talda
EZ-Backup Systems Engineer
Cornell University
+1 607-255-8280
rpt4 AT cornell DOT edu<mailto:rpt4 AT cornell DOT edu>