Hi Wanda,
I haven't seen that flavor of this before. The case I am familiar with is
where the original file system has files with real names like:
- MYLONG~1.PST (no short name)
- My long file name.pst (MYLONG~2.PST is the short name)
Then during restore, "My long file name.pst" is restored first, and
Windows assigns a short name of MYLONG~1.PST. Then when the original
MYLONG~1.PST file is restored, the file name collision occurs. (Note that
the ENABLE8DOT3NAMESUPPORT option was added to the client, which supports
backup and restore of the file's original short name. The option has to be
set to YES at backup time, in order to back up the short name for the
file.)
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
IBM Tivoli Storage Manager support web page:
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 12/02/2006
05:01:20 PM:
> That is very strange.
> It certainly looks like the drive is not truly empty.
>
> The case where you can get this error legitmately, is if you have
> multiple windows long filenames, that map into the same 8.3 name.
> For instance, if you restore
>
> My long file name.pst
>
> then also try to restore
>
> My long file name.~pst
>
> You will get a duplicate file error because NTFS will try to give
> them the same 8.3 name; the DUPLICATE FILE error is on the 8.3 name
> being created, not the long name (although you can't tell that from
> the error message).
>
> You will only see that when you have some application that creates
> funky file postfixes like .~pst as well as .pst, or .@doc as well as
.doc.
> (The fix is to temporarily disable the creation of 8.3 filenames
> with a registry hack; go to MS knowledge base and search on "8.3".)
>
> BUT I doubt that is your problem, given you have thousands of these
> duplicate files.
> If you can replicate the problem, better call Tivoil Support.
>
>
>
>
>
>
>
>
>
>
>
> ________________________________
>
> From: ADSM: Dist Stor Manager on behalf of Dennis, Melburn IT7
> Sent: Fri 12/1/2006 3:40 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Skipped Files During Restore
>
>
>
> Here is the list of some of the files that were skipped according the
> dsmerror.log file. I know the user in question and he's pretty
> competent, and he swears that the drive he's restoring to is completely
> empty (it's a brand new box). He's tried to the restore on 2 separate
> instances, both on different drives/paths. This is a W2K3 server.
>
> 11/28/2006 16:46:48 ANS1946W File
> \\cahlt00t124\g$\Homes\SparksGX\Critical Mail\Archive2005.pst exists,
> skipping
> 11/28/2006 16:46:48 ANS1946W File
> \\cahlt00t124\g$\Homes\SparksGX\Critical Mail\Archive2006.pst exists,
> skipping
> 11/28/2006 16:46:48 ANS1946W File
> \\cahlt00t124\g$\Homes\SparksGX\Critical Mail\archivebak.pst exists,
> skipping
> 11/28/2006 16:46:48 ANS1946W File \\cahlt00t124\g$\Homes\SPURR00G\My
> Documents\repwatch.xsw exists, skipping
> 11/28/2006 16:46:48 ANS1946W File \\cahlt00t124\g$\Homes\SPURR00G\My
> Documents\_Local Data.lnk exists, skipping
> 11/28/2006 16:46:48 ANS1946W File \\cahlt00t124\g$\Homes\TEJAD00L\My
> Documents\_Local Data.lnk exists, skipping
> 11/28/2006 16:46:48 ANS1946W File
> \\cahlt00t124\g$\Homes\VandonJ\Critical Mail\Sept2005 to Jan2006.pst
> exists, skipping
> 11/28/2006 16:46:48 ANS1946W File
> \\cahlt00t124\g$\Homes\VandonJ\Critical Mail\September 2005.pst exists,
> skipping
> 11/28/2006 16:46:48 ANS1946W File \\cahlt00t124\g$\Homes\Verma00Y\My
> Documents\_Local Data.lnk exists, skipping
>
>
> Mel Dennis
> Backup Systems Engineer
> Siemens Business Services
> 4400 Alafaya Trail
> Orlando, FL 32826
> MC Q1-108
> Tel: (407) 736-2360
> Win: 439-2360
> Fax: (407) 243-0260
> Email: melburn.dennis AT siemens DOT com
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Prather, Wanda
> Sent: Friday, December 01, 2006 3:17 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Skipped Files During Restore
>
> Ditto.
>
> With 8738 file being skipped, most likely the drive wasn't empty to
> start with.
> On the other hand, there IS actually a case where you can get duplicate
> files created with Windows long file names (it's a Windows issue, not a
> TSM issue.)
>
> Please give us more details about the system being restored to, and a
> sample of these skipped filenames...
>
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Richard Sims
> Sent: Friday, December 01, 2006 1:45 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Skipped Files During Restore
>
> On Dec 1, 2006, at 10:54 AM, Dennis, Melburn IT7 wrote:
>
> > I have a user that has been testing out a TSM restore of a
> > fileserver in
> > case of a disaster, and he's been getting reports that out of the
> > 471,871 files that were selected to be restored only 463,133 files
> > were
> > actually restored. The remaining 8,738 files are being skipped.
> > According to the dsmerror.log report, it is saying the the files
> > already
> > exist on the target server and were skipped for that reason. Now
> > how is
> > this possible if the user is restoring the files to an alternate
> > location (other than the original server) which is an empty drive?
> >
> > TSM Server 5.3.3.1
> > TSM Client 5.3.4.0
>
> Mel -
>
> That's very scant, second-hand information...not enough to act on.
>
> The server log or accounting file or evan Activity Log ANE mesages
> will tell you whether or not there was perhaps an initial restore
> attempt that was terminated and then reattempted, which would leave
> some files there. If Unix, you can use 'ls -alc' to see when those
> questioned files were actually established in the file system,
> compared with the time period when the restoral was supposedly run.
> If Unix, a df command should reflect an inode count which matches the
> restored objects count.
>
> Beyond that, pursue the details... What is the client type? What
> was the full syntax of the restoral attempt? What is the type of the
> skipped objects (files, directories, other)? What are the actual
> error messages (which may turn up something in a TSM Support Page
> search)?
>
> Not that we don't implicitly trust users...
>
> Richard Sims
|
