>>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.
