Troubles with different mgmt classes for NDMP backup

[bonobos]

Hi,

I have 3 different mgmt classes for a NDMP backup, with different values for verexists etc.

Backups are done daily differential, weekly full etc. with different mgmt classes. The plan was to have 14 differential (daily) versions and 2 fullbackup (weekly) versions to have the possibility to restore each day of the last 2 weeks.

The problem now is that after each fullbackup, all versions prior are lost ...

I attached the schedules and the mgmt classes in a zipped pdf format. Any help would be great!!!

 

[nbs03]

Bones -
Check the following
1. You are using the web gui and logged into the TSM server as a admin with system rights.
2. in the web gui, select restore, and look under file level for a filespace of concern.
3. click on the point in time button and then select "Use Selected Images"
- you should be able to select an image from the list.

Cheers,
Neil

 

[bonobos]

Something else is the problem:

Backup works well, 14 days differential (14 versions), every weekend full (with a different mgmt class with 2 versions, AND a backup that is taken offsite with 2 versions (and as well a different mgmt class).

The problem: When the monthly, full, extern backup is done (offsite) - ALL other restore information is deleted.

I thought with different mgmt classes it is possible to have different/separate version management? (version history)???????

 

[BBB]

I don't know how the NDMP backups work, so this post may or may not be relevent.

You cannot backup the same file to different management classes. Each time you back it up, it will rebind the previous versions of the file to the new mangement class you have selected. But like I said, I don't know how this works for NDMP backups.

WHen you do a "select * from backups where node_name='YOURNDMPNODEINALLCAPS'" do you get a list of all the files on the ndmp node, or is it more like 1 great big file per backup? And what MC's are they bound to?

 

[bonobos]

mmh, that would be the explanation, if I can't bind a version of a file to a weekly mgmt class, and another version (full backup mode) to a monthly mgmt class. But thats just what I want to! (please take a look at the attached zipped pdf file ... - daily differential on weekdays, weekly full on sundays, and weekly full on saturdays to take the tapes offsite and check them out of the library)

I just want to have 14 daily versions IN THE library, 4 weekly full versions IN THE library and 2 weekly versions OFFSITE outside the library - how can I do that ?????????

Can I create a copypool for NDMP data? Has anybody experience with "filer to server" backup? Is it slower?

 

[bonobos]

>>>> You cannot backup the same file to different management classes.
Each time you back it up, it will rebind the previous versions
of the file to the new mangement class you have selected.

So the only workaround to have different mgmt classes for the same file is to create a new node? Right?

 

[BBB]

Yes, a new node, assuming this still applies to NDMP backups. Someone else will need to confirm this for you...

 

[bonobos]

Thanks BBB, I'm waiting for somebody's response .... impatiently! ;-)

What I still need to know:
Has anybody experience with "filer to server" backup? Is it slower? If I have a copypool for my NDMP filer, without filer to server, I need much more tapes, don't I?

 

[nbs03]

Bones,
I have ndmp backups through the ethernet to a TSM server. The backups go to a disk or virtual tape pool prior to being migrated to real tape. NDMP over ethernet works well.

Limiting factor is speed of ethernet interface and you need to watch CPU load. You also need to install TSM V5.4.1.1+ which fixes several NDMP related bugs in V5.4.1.0

Using the ethernet allows the data to be managed in regular TSM storage pools which greatly simplifies creating a second copy for offsite and also allows you to use disk pools. The NDMP backups are still differential though.

If all you need is 14 days of recovery you may just create a single management class with Versions =nolimit, retextra=14 days, retonly=14 days. Perform a full backup on Sunday and differential backup all other days.
Each day you can backup to the copypool for offsite storage.

If you make special weekly full backups (for monthly retention), you will miss all of the changes that occur during the week and could end up loosing a file created on Monday and deleted on Friday.
Cheers,
Neil

 

[bonobos]

>>>> You cannot backup the same file to different management classes.
Each time you back it up, it will rebind the previous versions
of the file to the new mangement class you have selected.

Ahm, but 2 different versions of a file are 2 different objects, so it should be possible to have different mgmt classes for different versions of a file, not?

 

[BBB]

>>>> You cannot backup the same file to different management classes.
Each time you back it up, it will rebind the previous versions
of the file to the new mangement class you have selected.

Ahm, but 2 different versions of a file are 2 different objects, so it should be possible to have different mgmt classes for different versions of a file, not?

Bonobos, don't guess what "should" and shouldn't be based on your own way of thinking. The only thing that counts is what the TSM developers did. So ... the different versions of a backed up file are always in the same management class.

 

[bonobos]

Oh I got a red card? Sorry for my shameless behaviour, but I am confused about working with different objects/different management classes with the NDMP format.

Here is what an IBM employee told me:
One object can only be bound to one management class. But 2 versions of an object are 2 objects and can be bound to 2 different management classes. Thats the purpose of management classes.

Please notice, it's all about NDMP ...

 

[BBB]

In the case of ndmp, it is possible the ndmp backups are stored as different objects, I don't know. Like I said at the start, I wasn't sure about this side of things with ndmp. Have a look at the backups table for your ndmp node and see whats in it.