Sergey,
Yes, the LAN path isn't used! Thus the restore will fail when the object is
on disk. Even worse is that in our case it failed in the end of a large
restore after first having restored the online backups and in the end the
transaction logs that unfortunately were on a disk pool.

The following is part of the answer from IBM regarding this problem. There
is nothing in here about API/TDP but it gives you the idea about how
development seems to see this problem (feature). Of course we do not migrate
to disk in our case but the outcome is the same:

"Doc #1067224 - IBM Tivoli Storage Manager: Files not restorable in a
LAN-Free environment
Problem Desc: In a  LAN-Free environment files that have migrated to storage
pools who's device  classes are not SAN attached or accessible (such as
devclass DISK) can become un-retrievable to  your LAN-Free enabled client
unless special actions are taken.
Solution: Files that are stored in storage pools  that are not SAN attached
or accessible have to be moved over the LAN path. In  most cases the
customer runs into a problem when attempting to restore a single active file
or and  inactive copy of any number of files. The reason is that the
customer is not  performing a 'no query restore'. A no query restore is
defined as any restore using an unrestricted wildcard source  file
specification, and not using any of the options: INACTIVE, PICK, FROMDATE
or TODATE.

For example: dsmc restore /home/myfiles/*

A LAN-Free  enabled client must use a 'non query restore' to enable a duel
session restore over LAN-Free. This duel  session restore allows  the client
to open more than one concurrent session. These 2 sessions allow the  client
to retrieve data over the LAN-Free path and the LAN path on the same run.
In cases where a 'no query restore' is not possible then you will need to
retrieve files that are not LAN accessible by disabling 'enable lanfree'
from your dsm.sys (dsm.opt  in windows) file.

Customers typically run into this problem for  performance reasons. Small
files do not transfer efficiently over LAN-Free  connections due to the meta
data overhead. Thus they set up policy so that small  files are moved over
the LAN to a DISK storage pool. In order to reduce this  problems impact TSM
administrators should migrate these DISK storage pools to a LAN-Free
accessible  storage pool as soon as possible. "

Jan

-----Original Message-----
From: Sergey Tantlevskiy [mailto:sert AT US.IBM DOT COM]
Sent: Monday, 12 May 2003 21:08
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: LAN and SAN backups. Don't expect that you can restore your
backu ps if you have a mixed LAN/SAN environment.


Jan,

IMO, TDPs do not use NQR, since an application alsways knows the names of
the objects to be restored, so wildcard
is not sent to the server, hence no NQR...it is not an API limitation, it
is just not needed. I am sure that TSM API provides a developer
a way to send a wildcarded object specification to the TSM server, the
point is that it is up to an application whether to utilize this
functionality.

I would expect to see API to use LAN path in case SAN path fails for any
reason (for example an object is stored in the disk storage pool so it is
not
accesible through SA)...so are you saying it does not do this?


Sergey






"Norback, Jan" <Jan.Norback AT ATOSORIGIN DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
05/12/2003 12:18 AM
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        LAN and SAN backups. Don't expect that you can
restore your backu ps   if
you have a mixed LAN/SAN environment.



Do you believe that your end user can restore without the TSM admins
involvement?
Forget that if you are running in a mixed LAN and LAN free backup
environment. I appreciate you comments on the below:

We are supporting a number of larger SAP databases using TDP for SAP and
TDP
for SQL (or is it IBM Tivoli Data Protection for Databases now?...). The
online backups are going LAN free but the transaction logs (redologs) are
going over the LAN to a disk pool. This works perfect and it makes it
possible for us to have a good utilization of our tape drives with
controlled migration of the logs instead of tape drive competition. TSM
truly backs up anything anywhere and completely transparent to the end
users.

Restoring is a completely different area, it no longer works! In fact the
only alert that things are not working is in the end of a restore of an
SQL
Server when it fails with a read error. It fails because the transaction
logs hadn't migrated yet from the disk storage pool to tape. There is no
documentation in the manuals for TDP for XYZ that warns about this major
limitation, the only semi documentation related to this is in the Storage
Agent manual where it states:
-"Dual-session No-Query Restore  for LAN-free Path: When performing a
No-Query restore the TSM server builds a list of files to restore and
sends
data to the client while continuing to build  the list. This type of
restore
is more efficient especially in a LAN-free  environment, and allows the
restore to be restarted if interrupted. Two sessions  are used for the
restore when data for the restore resides on devices with a  LAN-free path
and devices with a LAN-only path. One session restores data from  the
server
with a LAN-only path. The other session uses the storage agent to  restore
data over the LAN-free path."
Here the manual talks about  "more efficient especially in a LAN-free
environment". That is very correct as there is absolutely no way of
getting
the data unless reconfiguration (or getting TSM sys admin involved for a
migration). It doesn't say that a query restore will fail! The manual also
explains that:
-"The  server determines if the client is  requesting access to storage
for
which the client has a SAN path defined. If a SAN path is defined, the
client (by means of the storage agent)  transfers data on that path."
To me that sounds that data residing on the disk should be transferred
over
the LAN. However, this is a no go when data requested is partly on a disk
pool and partly in the tape pool.

I can't find any limitation in the API documentation, nor can I find it in
the TDP for R/3 or SQL server documentation. The UNIX client BA and
Install
guide do not mention this major limitation for the "enablelanfree yes".
Nowhere is it clear that the products built on top of the API can't use
the
"No-Query " restore and that they will fail in a mixed LAN/SAN environment
as this!

I have opened a PMR in which I have asked IBM to fix this that I see as a
major problem, the order of my expectation for this fix where:
-Make sure that TSM can handle mixed LAN/SAN restores and once again
becomes
the tool we are used to have.
-Get the developer of the TDP for XYZ to utilize the API such that
"No-Query
restores" are used. (Don't know if this is possible).
-At least clearly document this limitations in all manuals with
information
on how to handle the problem. It has to be clear for the TSM admin that
migration must be very frequent for this setup. It would also be good if
the
TDP tooling had a "test-restore" facility that could warn for this and
alert
with a suggested work around.

None of the above was accepted by IBM. They don't see this as a bug and I
have been asked to submit a Design Enhancement Request or a Design Change
Request for this.

Regards,
Jan Norback
Tivoli Certified Consultant: ADSM/TSM
IBM Cert. Adv. Technical Expert RS/6000 AIX
Atos Origin-IT (MS/DS/OSS Unix)
VA-106
Groenewoudseweg 1
5621 BA Eindhoven, The Netherlands
Email: Jan.Norback AT Atosorigin DOT com
Tel: +31 (0)40-2780289
Mobile: +31 (0)6-12994492
Fax     : +31 40 2783962