[gpfsug-discuss] mmbackup monitoring

[Skylar Thompson]

On Wed, Mar 25, 2020 at 04:27:27PM +0000, Jonathan Buzzard wrote:
> On 25/03/2020 14:15, Skylar Thompson wrote:
> > We execute mmbackup via a regular TSM client schedule with an incremental
> > action, with a virtualmountpoint set to an empty, local "canary" directory.
> > mmbackup runs as a preschedule command, and the client -domain parameter is
> > set only to backup the canary directory. dsmc will backup the canary
> > directory as a filespace only if mmbackup succeeds (exits with 0). We can
> > then monitor the canary and infer the status of the associated GPFS
> > filespace or fileset.
> > 
> 
> I prefer this approach I think than grovelling around in log files that
> could easily break on an update. Though there is a better approach which in
> my view IBM should be using already in mmbackup.
> 
> It came to me this afternoon that one could use the TSM API for this. After
> a bit of Googling I find there is an API call dsmUpdateFS, which allows you
> to update the filespace information on the TSM server.
> 
> Fields that you can update include
> 
> DSM_FSUPD_OCCUPANCY
> DSM_FSUPD_CAPACITY
> DSM_FSUPD_BACKSTARTDATE
> DSM_FSUPD_BACKCOMPLETEDATE
> 
> Information on the API call here
> 
> https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.9/api/r_cmd_dsmupdatefs.html
> 
> How do we submit this as a feature request again? That said in my view it's
> a bug in mmbackup. The latest in a very long line stretching back well over
> a decade that make mmbackup less than production ready rather than a feature
> request :-)
> 
> I feel a breakout of a text editor and some C code coming on in the
> meantime.

I actually tried using the API years ago to try to do some custom queries,
and ran into the problem that custom API clients can only see data from
custom API clients; they can't see data from the standard BA client. I
contacted IBM about this, and they said it was a safety feature to prevent
a rogue/poorly-written client from trashing regular backup/archive data,
which makes some sense. Unfortunately, it does mean that IBM would have to
be the source of the fix.

-- 
-- Skylar Thompson (skylar2 at u.washington.edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine