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 r...@cornell.edu<mailto:r...@cornell.edu>