Run a local backup on M1, M2, and M3 that backs up the data that is not
failed over.
Run a shared1 and shared2 backup on all systems that backups up the data on
the system it exists on.
ie: M1 /usr /var / /opt
M2 /usr /var / /opt
M3 ""
shared1 /u /shareddata run a script to determine if the disk is
available and back it up to shared1 if it is
same on shared2
Sched all local and shared scripts under the node M1,2,3
This buys
1. Data backs up always under the same nodename
2. Filesystem last backup stats can be used to determine backup success
(to doubt check unreliable scheduler status)
Jeff Bach
> -----Original Message-----
> From: Warren, Matthew James [SMTP:matthewjames.warren AT EDS DOT COM]
> Sent: Friday, January 18, 2002 9:00 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: versioning / expiring / multiple backups under same
> nodename
>
> Thanks,
>
> but, the mechanics of the failovers etc.. is fine. only 1 machine will be
> failed over at any one time.
>
> I'll try and clarify;
>
> M1 and M2 share some common filespace / dirpath names. M3 is failover
> machine.
>
> Normal; M1 backs up to tsm under node M1, M2 backs up to TSM under node
> M2,
> M3 backs up to TSM under nodename M3.
>
>
> if M1 fails over to M3, M3 will now capture M1's files form the shared
> disk
> unde hte nodename M3, M1 backs up, but cannot see the shared disk area, so
> TSM marks all the shared disk files under nodename M1 as inactive.
>
> That goes on for a couple of days. Then M1 fails back to M1. M3 backs up,
> all M1's shared disk files go inactive under nodename M3, and become
> active
> files again on M1 under nodename M1.
>
> ..Then(!) M2 fails over to M2. The above process is repeated, but is
> complicated bacause M3 shares filespace names with M1, so, any duplicate
> filenames will back up and increase the version count of that file under
> nodename M3; but the version count will be too high as it counts versions
> from both M1 and M2. This will cause the files to expire earlier than they
> would have done from M3 than if they had only ever been backed up under
> the
> original machine nodename.
>
>
> ..Does anyone follow this? :-/
>
> basically (!)
>
> M1, M2 share dirpaths and filenames. The actual data is unique to each
> machine and is held on a slice of disk that only that machine has access
> to.
>
> M3 is a failover. When a machine is failed over to M3, that machines slice
> of disk is mounted on M3. The original machine still backs up, but can
> only
> see it's local O/S disk.
>
> M3 runs backups of all the disk it can see each evening, under the
> nodename
> M3.
>
>
> So, if M1 is failed over, its files are backed up under the nodename M3.
>
> ..So far, no problem. If you know what days you were failed over you can
> just get the files from the M3 nodename using -pitd / -pitt or -pick
>
> But, M1 fails back to M1, and then M2 fail over to M3.
>
> When M3 backs up, it will see M2's disk and save it under the nodename M3.
> PROBLEM! The shared filespace names between M2 and M1 will now cause TSM
> to
> mark files inactive, or back them up creating versions / expirations that
> should not be happening.
>
>
> Arg!
>
> Can anyone see what I'm getting at?
>
>
>
> -----Original Message-----
> From: Anderson F. Nobre [mailto:anderson AT SOLVO.COM DOT BR]
> Sent: Wednesday, January 16, 2002 6:30 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: versioning / expiring / multiple backups under same
> nodename
>
>
> Hi,
>
> > I have a customer who wishes to assess the maximum risk he would incurr
> in
> > the following situation;
> >
> >
> > We have a copygroup for backup set for 31 day point-in-time recovery. We
> do
> > not have nolimit for any copygoup parameters - we assume there will only
> be
> > a single backup each day.
> >
> >
> > The customer has a 5 node cluster. 1 -> 4 are production machines, 5 is
> a
> > failover machine.
> >
> > They would like to know the risk involved when, should a machine be
> failed
> > over to 5, they back up the data now visible to 5 under the nodename of
> 5
> > instead of the original machines nodename, & the original machine
> continues
> > to run a backup as well (this would only see local disk, as a portion of
> the
> > failed over machines disk is now visible to 5, and hence mark all the
> > non-visible files as inactive)
> >
> > We have told them backups would become inconsistent within filespaces
> that
> > have the same names across machines, and showed them how fiddly it would
> be
> > to restore a machine if they had only had one failover occurr in a 31
> day
> > period. They would like to know exactly what the risks are if they have
> > multiple failovers within a month, and have multiple machines backing up
> > same-named files under a single nodename!!
> >
> It depends how the cluster is configured. The TSM Client must be part of
> the
> resource group and inside of dsm.sys you must create several stanzas with
> the TCPPort and nodename forced to diferent numbers and names. And when
> you
> start the TSM Client Scheduler you must force the right dsm.opt
> with -optfile option.
>
> > They won't take 'It won't work' as a answer, they would like to know how
> it
> > will impact the point in time restore capability for a particular
> machine,
> > if they keep track of what machines failed over when.
> >
> > As far as I can work out with pen&paper, in a worst case, for a 3
> machine
> > cluster where 1 & 2 can failover to 3 at any time, the maximum impact
> would
> > be to reduce the point-in-time restore capability for a particular
> machine
> > by the number of days that machines have been failed over to 3 in the
> last
> > 31 day period, because files with the same path filename on machines 1
> and
> 2
> > would expire early if they change more often on one machine than they do
> on
> > another.
> >
> It's impossible two machines failover at same time to a third machine if
> the
> first two have the same filesystems. They even would import the VGs. You
> must check if this information it's true.
>
> > I get a headache if I try and extend this to a 5 machine cluster.
> >
> > do you other TSM'ers agree?
> >
> Yes, to mange would be a little bit hard. But the client probably has good
> administrators. Or in worst case you can sell a support contract to
> administer his environment. :-)
>
> > and, I know from our perspective this is a 'silly' thing to work out
> because
> > they should listen to the advice of the people that know & switch to
> backing
> > things up correctly, but they are insisting they have this info...
> >
> > Any help is much appreciated!
> > Thankyou,
> >
> > Matt.
> >
**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the individual or entity to
whom they are addressed. If you have received this email
in error destroy it immediately.
**********************************************************************
|
