mbotticelli
ADSM.ORG Member
- Joined
- Dec 13, 2002
- Messages
- 46
- Reaction score
- 0
- Points
- 0
Has anyone seen this or experienced this with a restore?
Sorry for all the details but this is a detailed problem.....
We are running TSM 5.1.6.3 on AIX 4.3.3 and the client we tested this restore on is a NT 4.0 box running client code 5.1.1.15
A backup of the volume backs up long filenames, while ignoring long-to-short filename mappings. The TSM client\server is unaware of any correlation between them. A restore restores in an order not easily manipulated\sorted.
Long filenames are restored in an order other than that of their original creation, so that corresponding short filenames do not match across machine rebuilds or file redirects.
8.3 or shorter filenames restored after long filenames MAY BE IDENTICALLY NAMED to the auto-created short file names. This means you are presented with a choice of overwriting one of the files, or skipping the other.
We encountered this issue when doing the following test:
In the test restore of PTMAINFS this behavior was data-destructive, in that A CLEAN REBUILD or redirected restore would result in (a) mismatched or absent file(s). TSM recommendations in terms of complete machine restore [build array, install OS, install TSM client, (reboot), restore filesystem, (reboot), restore OS, (reboot)] would result in this behavior occurring.
This does not bode well for disaster recovery in large environments using the product. 8.3 short filenames and short filename auto-creation have been (default) Windows behavior for many years. I would expect that a mature product would address this one of several ways (other than in the current "ignore the behavior" fashion). Any mixed environment with older downlevel clients and newer servers large enough to have many similarly-named files can\may experience this.
1. Files may not be restored, large-scale disaster-recovery may consume more time and require more personnel.
2. Inconsistent short\long filename relationships may cause issues for downlevel clients (e.g. DATARE~1.IDX, DATARE~2.IDX, DATARE~3.IDX, DATARE~4.IDX, DATARE~5.IDX, DATARE~6.IDX, DATARE~7.IDX, DATARE~8.IDX, and DATARE~9.IDX becoming DATARE~3.IDX, DATARE~7.IDX, DATARE~4.IDX, DATARE~6.IDX, DATARE~5.IDX, DATARE~1.IDX, DATARE~8.IDX, DATARE~9.IDX, and DATARE~2.IDX, respectively to a downlevel client could break many of our legacy applications).
3. Turning off 8.3 filename creation for restore operations could break functionality for downlevel clients.
Tivoli's response:
The TSM restore process is currently designed to minimize tape mounts during the restore. The issue we are running into is a unique situation, and will only occur when a client has a longfile name file, that matches the exact syntax of a windows created shortfile name for another longfile in the same directory, and the restore is performed to a new hard drive. In this case ororiginal.lbd and ororig~1.lbd. During the restore TSM sends the longer one first, and windows automatically creates it's shortfile name first, and when TSM attempts to send the next file, windows sends a message that it already exists.
- To accomplish what you are looking to do with a restore I recommend a change request be submitted through your business partner to either add server filtering capabilities to restore 8.3 files before longer file names ( This could effect the time it takes to perform a restore as it could potentially require many more tape mounts during the restore process), or to allow client ordering capability of what files are layed down first in a restore scenario (more likely)
- A temporary work around to this would be to perform two separate restores, sending the shorter file name first, before windows is able to create a "windows shortfile name" for the other file. The other workaround possibility would be to disable shortfile name creation during the restore process, and re-enable after the restore is complete.
Sorry for all the details but this is a detailed problem.....
We are running TSM 5.1.6.3 on AIX 4.3.3 and the client we tested this restore on is a NT 4.0 box running client code 5.1.1.15
A backup of the volume backs up long filenames, while ignoring long-to-short filename mappings. The TSM client\server is unaware of any correlation between them. A restore restores in an order not easily manipulated\sorted.
Long filenames are restored in an order other than that of their original creation, so that corresponding short filenames do not match across machine rebuilds or file redirects.
8.3 or shorter filenames restored after long filenames MAY BE IDENTICALLY NAMED to the auto-created short file names. This means you are presented with a choice of overwriting one of the files, or skipping the other.
We encountered this issue when doing the following test:
In the test restore of PTMAINFS this behavior was data-destructive, in that A CLEAN REBUILD or redirected restore would result in (a) mismatched or absent file(s). TSM recommendations in terms of complete machine restore [build array, install OS, install TSM client, (reboot), restore filesystem, (reboot), restore OS, (reboot)] would result in this behavior occurring.
This does not bode well for disaster recovery in large environments using the product. 8.3 short filenames and short filename auto-creation have been (default) Windows behavior for many years. I would expect that a mature product would address this one of several ways (other than in the current "ignore the behavior" fashion). Any mixed environment with older downlevel clients and newer servers large enough to have many similarly-named files can\may experience this.
1. Files may not be restored, large-scale disaster-recovery may consume more time and require more personnel.
2. Inconsistent short\long filename relationships may cause issues for downlevel clients (e.g. DATARE~1.IDX, DATARE~2.IDX, DATARE~3.IDX, DATARE~4.IDX, DATARE~5.IDX, DATARE~6.IDX, DATARE~7.IDX, DATARE~8.IDX, and DATARE~9.IDX becoming DATARE~3.IDX, DATARE~7.IDX, DATARE~4.IDX, DATARE~6.IDX, DATARE~5.IDX, DATARE~1.IDX, DATARE~8.IDX, DATARE~9.IDX, and DATARE~2.IDX, respectively to a downlevel client could break many of our legacy applications).
3. Turning off 8.3 filename creation for restore operations could break functionality for downlevel clients.
Tivoli's response:
The TSM restore process is currently designed to minimize tape mounts during the restore. The issue we are running into is a unique situation, and will only occur when a client has a longfile name file, that matches the exact syntax of a windows created shortfile name for another longfile in the same directory, and the restore is performed to a new hard drive. In this case ororiginal.lbd and ororig~1.lbd. During the restore TSM sends the longer one first, and windows automatically creates it's shortfile name first, and when TSM attempts to send the next file, windows sends a message that it already exists.
- To accomplish what you are looking to do with a restore I recommend a change request be submitted through your business partner to either add server filtering capabilities to restore 8.3 files before longer file names ( This could effect the time it takes to perform a restore as it could potentially require many more tape mounts during the restore process), or to allow client ordering capability of what files are layed down first in a restore scenario (more likely)
- A temporary work around to this would be to perform two separate restores, sending the shorter file name first, before windows is able to create a "windows shortfile name" for the other file. The other workaround possibility would be to disable shortfile name creation during the restore process, and re-enable after the restore is complete.
