Re: Q's about IBM TSM (was Re: HEADSUP: ibcs2 and svr4 compat headed for history)

"Paul Seniura" <pdseniura_at_techie.com> wrote:

(I get freebsd-current in digest form; I'm replying to several of your
messages in one reply.)

> Message: 2
> Date: Mon, 28 Jun 2004 14:25:27 -0500 (CDT)
> From: "Paul Seniura" <pdseniura_at_techie.com>
> Subject: Q's about IBM TSM (was Re: HEADSUP:  ibcs2 and svr4 compat
> 	headed	for history)
> To: "Carl Makin" <carl_at_xena.IPAustralia.gov.au>
> Cc: freebsd-current_at_freebsd.org
> Message-ID: <20040628192527.1C2755C29_at_techpc04.okladot.state.ok.us>

> > It will cause us a lot of grief unless we can find an alternative way to
> > run IBM's Tivoli Storage Manager.  We currently use the SCO v2 client
> > which has huge warts, but runs.
> 
> Could you take time or point me to something that would
> explain how to use the SCO client, please?

The SCO V2 client *does not run* under 5.x.  It does run under 4.x,
still.  If you are using 5.x, the SCO V2 client is not a viable option
until someone fixes iBCS2 emulation, which is largely broken there.  (I
did get the example iBCS2 "Hello World" program to run, but nothing
else.)

> We'd be another bunch to add to the ibcs/svr group if it
> actually works here, too.  ;)

Even if it did, it is not pleasant to use under a contemporary TSM
server because of the huge versioning gap.  (For instance, our 5.1.8.3
TSM server would always report the scheduled backup had failed, even
though the V2 client logs and test restores indicated it was
successful.)  Many current features and options are not supported, and
current IBM TSM servers do not officially support such an old client
(although it does appear to work).

> > The linux client trips over the whole filesystem overlay thing badly and
> > I'm not sure disabling that to run just the TSM client is a good idea.
> > (Plus I hate the idea of maintaining custom kernel patches.)
> 
> I've had no luck, likewise, with the Linux TSM client. 
> I had never considered another compatible client until
> seeing your msg just now.

I'm using the Linux 5.1.5.15 TSM client on a FreeBSD 5.2.1-RELEASE-p8
system.  (See previous message in this thread.)  It was a bit finicky to
get going.  I found I had better luck using emulators/linux_base-8 than
emulators/linux_base, though I did get it running under both.  One
hurdle for most people is that the client aborts with an out of memory
error during file activities.  I discovered that this is caused by
having an empty or missing /compat/linux/etc/mtab file.  Creating a
proper mtab file solves these problems.  One way to do this is via
something like the following:

	sed 's/ufs/ext2/' < /etc/fstab > /compat/linux/etc/mtab

That way, the Linux TSM "sees" your UFS partitions and will
backup/restore to them.

> FWIW, our support contract with IBM does cover TSM clients,
> but IBM won't consider a FreeBSD-native client despite
> their supporting their MacOSX client very well & officially. 
> IBM says they need more "user base" to even consider a BSD
> flavor... go figure...

When I had our TSM administrator enquire about a native FreeBSD client,
they reported back they had one.  However, like Daniel Lang's
experience, the price we were quoted was exorbitantly high for our
purposes, so we passed.

> Message: 15
> Date: Mon, 28 Jun 2004 16:56:40 -0500 (CDT)
> From: "Paul Seniura" <pdseniura_at_techie.com>
> Subject: Re: Q's about IBM TSM (was Re: HEADSUP: ibcs2 and svr4 compat
> 	headedfor history)
> To: "Lukas Ertl" <le_at_FreeBSD.org>
> Cc: Carl Makin <carl_at_xena.IPAustralia.gov.au>
> Message-ID: <20040628215640.C14935C29_at_techpc04.okladot.state.ok.us>

> > I'm using the Linux client with the nullfs hack.  Works rather well.
> > At least the Linux client isn't as awful as the ancient SCO client.
> 
> I google'd and didn't like what I saw.  Stuff about
> nullfs not being too kosher on -Current.  :(

I successfully used the nullfs hack for months and didn't notice any
problems.  I didn't do many heavy restores, although the test restores I
did do worked without error.

One disadvantage of the nullfs hack is that you also need something like
a nightly rsync cron job to mirror over the stragglers (because you
can't nullfs remount the root partition under the root partition).  My
current approach (using mounted snapshots, as described in a previous
message in this thread) does away with that requirement, and also has
the advantage of providing a read-only filesystem for TSM to back up,
meaning no objects will rebound.  (The snapshot approach will only work
under 5.x onwards.)

> My krak about "go figure" was a slam on the number of
> OSX users that would need TSM while IBM supports _it_.

In terms of users, there are probably a *lot* of MacOS X desktops out
there.  I'm guessing MacOS X support was required because of prior
client support for the Mac.  I'm using their TSM client on a MacOS X
10.3.4 Server system I use.

> Probably will do my own backups
> on this FreeBSD box the same way.  End-users, tho,
> will be a different matter -- they won't know what
> to do without a GUI.  <ouch!>  ;)  Any of this would
> be possible nowadays with custom bootable CDs.

Another option would be to use some kind of rsync mirroring to a machine
that did have a supported TSM client and let back up the files. 
Alternatively, you could NFS mount your FreeBSD partitions on such a
supported client machine and add the network filesystems to the backup
domain.  (That's assuming you were apprehensive about running the Linux
client on your FreeBSD system.)

There are quite a few backup options in the ports.  Try "make search
key=backup" in /usr/ports to list some.

> I wonder what it would entail with your nullfs hack
> and having to _restore_ a user's system from TSM?

You just restore in-place and the files automagically appear in the
correct place, sans your chosen prefix (/backup, in my case).  You do
have to do some manual copying restoring files in /, because those
aren't nullfs-mounted.

With the snapshot approach I'm using, all restores require some moving
to get them into the correct place.  E.g., you'd have to restore
/backup/usr/... to, e.g., /usr/backup/... and then mv to /usr/...
afterwards to get the files into the correct logical place.

As for disaster-recovery (i.e., complete system recreation), you'd
probably have to do some kind of minimal install and setup of TSM, or
else have made some kind of custom TSM FreeSBIE bootable CD system from
which you can run dsmc et al.  I've never tried that.  I've only done
standard restores on a working system.

Cheers,

Paul.
-- 
e-mail: paul_at_gromit.dlib.vt.edu

"Without music to decorate it, time is just a bunch of boring production
 deadlines or dates by which bills must be paid."
        --- Frank Vincent Zappa