ADSM-L

Re: [ADSM-L] NDMP policies/schedules

2008-12-22 17:50:59
Subject: Re: [ADSM-L] NDMP policies/schedules
From: Shawn Drew <shawn.drew AT AMERICAS.BNPPARIBAS DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 22 Dec 2008 17:49:05 -0500
I just queried my backups table.  (it's not bad at all when only dealing
with NAS nodes)
The same node can have backups to different management classes.

However, I use virtualfs's to point to different snapshots, so I can't
verify if the same volume can have multiple management classes.


Regards,
Shawn
________________________________________________
Shawn Drew





Internet
david-bronder AT UIOWA DOT EDU

Sent by: ADSM-L AT VM.MARIST DOT EDU
12/18/2008 08:19 PM
Please respond to
ADSM-L AT VM.MARIST DOT EDU


To
ADSM-L
cc

Subject
[ADSM-L] NDMP policies/schedules





I'm wondering what those of you using TSM for NDMP backups are using
for your policy settings and managing your backup schedules.  I figure
some of you must have found some kind of workable policy and schedule
configuration...

I was asked to configure NDMP for our NetApps to retain monthly full
backups for a year, weekly fulls for a month, and daily differentials
for a week.  Welcome back to the old days.  Anyway...

So I set up a policy domain for the filers with management classes for
daily (retextra=6), weekly (retextra=31) and monthly (retextra=366)
backups.  Then I set up scripts for each node to run the "backup node"
commands, with arguments specifying mode (full/diff) and mgmt. class,
and set up admin schedules to run the scripts with the right arguments
on the right days of the week/month.

It all sounds good (as good as NDMP gets on TSM).  Except it doesn't
work.  It turns out that specifying the mgmt. class for an NDMP backup
rebinds all previous images for that volume/filespace (and now support
is telling me it in fact rebinds for all filespaces on that node, but
I haven't verified that assertion).  So my weekly full from two weeks
back is gone, because subsequent daily's have rebound it to a 6-day
retention.  This is detailed in Technote 1240848.

So I opened a PMR about how to get the desired retentions, assuming
it's possible.  The initial feedback from support was to use two nodes
in TSM:  one for monthly fulls with 1 year retention, one for weekly
fulls and daily diffs with 1 month retention (for both full and diffs).
The week following the monthly, the diffs would be supposedly be based
off the prior weekly full (now support is unsure about this point).

I'm also exploring using a VIRTUALFSMAPPING to map the volumes into a
/monthly/vol/volname path and run monthly fulls using that path and
corresponding mgmt. class.  This is where the question arises about
whether specifying a different mgmt. class rebinds all filespaces for
the node, or just previous backups of the same filespace.  I plan to
test this soon.

Unfortunately, I have to use NDMP for these backups.  The files are
being migrated from a Windows fileshare cluster to the NetApp.  There
are many millions of files, and on the Windows cluster we absolutely
had to have the TSM journal service in use for the backups to finish
in a reasonable time.  So using a TSM B/A client on a Windows box to
backup the shares doesn't seem viable, since the journal service only
works with local filesystems.

(Oh, to have a native DataONTAP TSM client with journal service...)

Those of you who read this far without your head exploding, congrats
and thanks. :)  So for anyone with similar NDMP requirements, how
have you implemented your solution?

=Dave

--
Hello World.                                    David Bronder - Systems
Admin
Segmentation Fault                                     ITS-SPA, Univ. of
Iowa
Core dumped, disk trashed, quota filled, soda warm.
david-bronder AT uiowa DOT edu


This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.

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