Thanks for the feedback. I got this info from another source. Method #1 is exactly what we DON'T want to do. The DFS process is replacing the CIFS process we currently use for backups. There are going to be dozens of "mountpoints", 1-per individual department/group and each will be kept as separate/individual nodes so everyone has their own control over restores, etc.
Method#2 is also lacking since we will need to backup multiple DFS "mountpoints" from 1-"workstation", like we currently do with CIFS. We have 2-Windows 2012 servers whose sole purpose is to run 20-30 TSM backups (each), one per CIFS node. Unfortunately, there aren't an details on how to configure the DFS stuff and TSM options to work the same way. All of our tests have mostly failed with the backup backing-up too much (traversing too many subdirectories) or not-enough). Our structure is going to be (and is currently working as such as CIFS mounts) DFS backup server(s) Department Directory A A-Subdir A-Subdir....etc Department Directory B B-Subdir.....etc and each "Department" must have their own backups/TSM node/interface On Fri, Sep 9, 2016 at 7:39 AM, Rick Adamson <rickadam...@segrocers.com> wrote: > Hi Zoltan, > There's a section in the BA client user guide that talks about the options > available for backing up Microsoft DFS, perhaps that will help.... it's a > short read. I haven't used it in a few years so would be reluctant to be > specific on usage. > > (from page 180 on the 7.1 version of the BA guide) > > There are the methods you should use to protect your Microsoft Dfs data: > 1. Back up the Dfs link metadata and the actual data at the share > target of each > link from the workstation hosting the Dfs root. This method > simplifies back up > and restore by consolidating all of the Tivoli Storage Manager > activities on a > single workstation. This method has the disadvantage of requiring > an > additional network transfer during backup to access the data > stored at link > targets. > 2. Back up only the Dfs link metadata that is local to the > workstation hosting the > Dfs root. Back up the data at the target of each link from the > workstation(s) > which the data is local too. This method increases back up and > restore > performance by eliminating the extra network transfer, but > requires Tivoli > Storage Manager back up and restores to be coordinated among > several > workstations. > > Hope this helps...... > > -Rick Adamson > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Zoltan Forray > Sent: Thursday, September 08, 2016 3:44 PM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] Help with DFS backups > > We were able to determine it was a rights issue on the Isilon system. TSM > needs root-level access. > > However, our current problem is how TSM backs things up when using DFS > mounts. Eventhough we specifically say to backup "\\rams.adp.vcu.edu\vpa\vp > administration\*", the only filesystem TSM sees and registers when it backs > up is the highest level, that being "\\rams.adp.vcu.edu\vpa" - it ignores > the "vp administration" sub-directory/folder. > > Does anyone out there have experience with backing up DFS with TSM? Is > this the way it is going to be? This is back to each > department/group/area wanting total control over backup/restore of their > "shares". > > On Thu, Sep 8, 2016 at 9:18 AM, Schneider, Jim <jschnei...@essendant.com> > wrote: > > > Do you have the correct capitalization in the backup command? > > > > Jim Schneider > > > > -----Original Message----- > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf > > Of Zoltan Forray > > Sent: Thursday, September 8, 2016 7:54 AM > > To: ADSM-L@VM.MARIST.EDU > > Subject: [ADSM-L] Help with DFS backups > > > > We are redesigning our storage systems, moving to Isilon and to DFS vs > > CIFS. > > > > Unfortunately, we have not been able to get TSM to backup the first > > test DFS mount. > > > > All efforts to run a backup the DFS fail with: > > > > Incremental backup of volume '\\rams.adp.vcu.edu\vpa\vp administration' > > ANS1228E Sending of object '\\rams.adp.vcu.edu\vpa\VP Administration' > > failed. > > *ANS4007E Error processing '\\rams.adp.vcu.edu > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__urldefense&d=DQI > > BaQ&c=AzgFQeXLLKhxSQaoFCm29A&r=eqh5PzQPIsPArLoI_uV1mKvhIpcNP1MsClDPSJj > > Ffxw&m=5PRblP2zIuEBKbqOWcmYmtDqOHrzrqJ4mnewDAB6qEg&s=rZoJajrq2_UeeiVpg > > -zB-efFopQrZGkd8a0nu0ICnbo&e= .> > > proofpoint.com/v2/url?u=http-3A__rams.adp.vcu.edu_&d=DQIBaQ&c= > > MqzcmAKsw3j3xTQl5efyrz6ChwH9_xFQsqxq8hPjflw&r=oC06_8Fv3bsc_6MYFkLOVjvW > > vgE- JVnMc6qtesQ14R0&m=FGrnyJKGKidLaS1WgSPITHIybdYao96cpsMsRS6Ip-A&s= > > JpzTtoiZFZZag3Nn8eLnC77-XeRLd9tdS020hD2N7nA&e= >\vpa\VP Administration': > > access to the object is > > denied* > > ANS1802E Incremental backup of '\\rams.adp.vcu.edu\vpa\VP > Administration' > > finished with 1 failure(s) > > > > This is supposed to be the structure: > > > > Isilon - \\uccisilon.rams.adp.vcu.edu\VP Administration DFS - \\ > > rams.adp.vcu.edu\VPA\VP Administration > > > > Normally the "access denied" would be an authorization/rights issue. > > However, everything has been checked and double-checked and supposedly > > (I don't have anything to do with it) is correct. > > > > Backing up the Isilon mountpoint works. This command fails with the > > "access denied" error: > > > > dsmc i -optfile=C:\tsmcifsnode\isilon-vpadmin\dsm-vpadmin.opt > > -subdir=yes "\\rams.adp.vcu.edu\vpa\vp administration" > > > > So, what are we missing? > > > > > > -- > > *Zoltan Forray* > > TSM Software & Hardware Administrator > > Xymon Monitor Administrator > > VMware Administrator (in training) > > Virginia Commonwealth University > > UCC/Office of Technology Services > > www.ucc.vcu.edu > > zfor...@vcu.edu - 804-828-4807 > > Don't be a phishing victim - VCU and other reputable organizations > > will never use email to request that you reply with your password, > > social security number or confidential personal information. For more > > details visit https://urldefense.proofpoint.com/v2/url?u=http-3A__ > > infosecurity.vcu.edu_phishing.html&d=DQIBaQ&c= > > MqzcmAKsw3j3xTQl5efyrz6ChwH9_xFQsqxq8hPjflw&r=oC06_8Fv3bsc_6MYFkLOVjvW > > vgE- JVnMc6qtesQ14R0&m=FGrnyJKGKidLaS1WgSPITHIybdYao96cpsMsRS6Ip-A&s= > > j5Kzor69UmuMAbR8r3Lsv6l9uRm50ZAn2FTOQgjdoEc&e= > > > > ********************************************************************** > > Information contained in this e-mail message and in any attachments > > thereto is confidential. If you are not the intended recipient, please > > destroy this message, delete any copies held on your systems, notify > > the sender immediately, and refrain from using or disclosing all or > > any part of its content to any other person. > > > > > > -- > *Zoltan Forray* > TSM Software & Hardware Administrator > Xymon Monitor Administrator > VMware Administrator (in training) > Virginia Commonwealth University > UCC/Office of Technology Services > www.ucc.vcu.edu > zfor...@vcu.edu - 804-828-4807 > Don't be a phishing victim - VCU and other reputable organizations will > never use email to request that you reply with your password, social > security number or confidential personal information. For more details > visit https://urldefense.proofpoint.com/v2/url?u=http-3A__ > infosecurity.vcu.edu_phishing.html&d=DQIBaQ&c=AzgFQeXLLKhxSQaoFCm29A&r= > eqh5PzQPIsPArLoI_uV1mKvhIpcNP1MsClDPSJjFfxw&m= > 5PRblP2zIuEBKbqOWcmYmtDqOHrzrqJ4mnewDAB6qEg&s=zxFV3jdAaEaoP1MWn0NKj- > WV3bZfdb9RP1g604VMr0w&e= > -- *Zoltan Forray* TSM Software & Hardware Administrator Xymon Monitor Administrator VMware Administrator (in training) Virginia Commonwealth University UCC/Office of Technology Services www.ucc.vcu.edu zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html
