ADSM-L

Re: [ADSM-L] Help with DFS backups

2016-09-12 09:22:15
Subject: Re: [ADSM-L] Help with DFS backups
From: "Ryder, Michael S" <michael_s.ryder AT ROCHE DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 12 Sep 2016 09:20:02 -0400
Zoltan

Have you tried explicitly including each DFS share as a mount point?

I've had to do something similar in the past, though I can't remember
exactly whether I used the "DOMAIN" "INCLUDE" or BOTH statements.

Sorry, that's my best effort - though I would like to hear about the
solution you end up with.

Best regards,

Mike, x7942
RMD IT Client Services

On Mon, Sep 12, 2016 at 9:05 AM, Zoltan Forray <zforray AT vcu DOT edu> wrote:

> 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 <RickAdamson AT segrocers DOT 
> 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 AT VM.MARIST DOT EDU] On 
> > Behalf Of
> > Zoltan Forray
> > Sent: Thursday, September 08, 2016 3:44 PM
> > To: ADSM-L AT VM.MARIST DOT 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 <JSchneider AT essendant DOT 
> > com
> >
> > wrote:
> >
> > > Do you have the correct capitalization in the backup command?
> > >
> > > Jim Schneider
> > >
> > > -----Original Message-----
> > > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On 
> > > Behalf
> > > Of Zoltan Forray
> > > Sent: Thursday, September 8, 2016 7:54 AM
> > > To: ADSM-L AT VM.MARIST DOT 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
> > > zforray AT vcu DOT 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
> > zforray AT vcu DOT 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
> zforray AT vcu DOT 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
>

<Prev in Thread] Current Thread [Next in Thread>