3-way-NDMP backup questions.

mohit

ADSM.ORG Member
Joined
Apr 16, 2004
Messages
24
Reaction score
0
Points
0
Website
Visit site
Hello Everyone,

I have implemented a 3-way-ndmp backup solution with NetApp v-6080, TSM 5.5 and 3584 tape library. I have 2 disk storage pools dedicated for NDMP, one for TOC and other for data; both with data format native. The maxsize is set to no limit.

When I run ndmp backups using backup node, the backup do not go to disk pool but go straight to the tapes which is defined as next storage pool for the disk storage pool, the TOC still goes to disk. Any idea why this happens? Only some very small filespaces (2-5 MB in size) seem to go to disk.

After backup storage pool runs, the image storage pool name in "query nasbackup" changes to copy pool name. Does it mean that onsite copy is gone and I am left with only DR copy?

I was reading about problem some people are facing with backing up same NAS volume to different management classes. I have the same requirement here, i.e. weekly fulls to be retained for 2 weeks, daily diffs for 7 days, and one annual full to be retained forever (I know, but that's what 'they' want). I have created 3 different management classes; but does TSM bind all data for a filespace to the management class last used for it and thus changing the retention for everything backed up in past?

Thanks in advance for your help.
 
If you're backing up q-trees within a volume (via virtual filespaces or otherwise) you might find that the size of each q-tree is being evaluated as the size of the entire volume upon which the q-tree resides - i.e. it might well be larger than the entire disk pool.
 
All the backups are indeed virtual filespace based. So that can sure be the reason. Thanks.

Now the other two questions please?
 
Re the query nasbackup - dunno, mine doesn't do that...TSM can't have a copy without a primary so I don't think that's it.

Re the mgmt class - hmm, again, dunno. All images are stored as the same filename, so maybe they do get rebound. Best try it and see - let us know what you find. If they do - one way to sort it out might be to create multiple virtual fs mappings (one per mgmt class) for each q-tree.
 
What version of TSM are you running?

I guess I will have to find out as I go about management class. The problem is we are close to running out of capacity of TSM 5.5 (497 GB fb size and 12 GB log size; upgrade is in works but who knows how long before it gets approved) so any select query on this database takes forever to run; particularly on backup and archives tables.
 
The instance storing the NAS data is at 6.1.3.4...

Your 5.5 database is 497 GiB in size? That's humongous. I generally spawn a new (5.5) instance at 100 GiB database capacity :eek:
 
I am sure when it was implemented it started somewhere around 100 GB too. I inherited it at this size though and currently struggling with data owners for retention policies. Having everything indefinitely is not a smart decision.
 
Back
Top