>>I would like to use an existing server to archive the folders via UNC path.
>>However, I am told by our windows admins that the system user may not have
>>access to these network resources.
The system user definitely will not.
1. First pick a system to run the archives off the netapp, presumably any
convenient Windows host (including the TSM server, if it's Windows).
2. You will need to run the TSM scheduler service under an account that has
network login rights. That's a common thing to do. Your Windows admins just
have to create you an appropriate domain-level account that has access to the
path and TSM-client required backup rights (listed in the Windows client
manual).
3. Then you put the UNC name in a DOMAIN statement in dsm.opt, e.g: (again
your Windows admins have to provide the appropriate sharename):
DOMAIN \\hostname\d$ , or \\xxx.yyy.zzz.qqq\e$
4. In a preschedule script you will (usually) need to do a net use to mount
the drive:
net use \\hostname\d$
5. In a postschedule script undo the net use
>>Can you archive via UNC path? If so , how to make it schedulable, and
>>retrievable after the netapp has gone away?
Above steps make it schedulable. Retrievable is a non-issue. When you open
the client whose dsm.opt you used, you will see those drives as drives
available with data for restore/retrieve.
At my customers we usually put 2 schedulers on the backup-ing host, one for its
own local drives, and another for the NAS/Netapp backups.
We give the NAS/Netapp back scheduler its own dsm.opt, and its own nodename.
That makes it easy to move to a different host. For big NAS/Netapps, we even
split the load across multiple proxy machines, 'cause it's slow as dirt if the
directory(s) on the NAS/Netapp share is of any size or complexity. Throughput
is usually more limited by the CIFS overhead than the proxy machine hardware,
so pretty much any box that doesn't have much to do in the middle of the night
is a fine candidate as a proxy machine. At one customer we use the backup
domain controllers.
|
