unixadmin.free.fr just another IBM blog and technotes backup


Creating NIM resources on an NFS shared NAS device

You can use a network-attached storage (NAS) device to store your Network Installation Management (NIM) resources by using the nas_filer resource server.

NIM support allows the hosting of file-type resources (such as mksysb, savevg, resolv_conf, bosinst_data, and script) on a NAS device. The resources can be defined in the NIM server database, and can be used for installation without changing any network information or configuration definitions on the Shared Product Option Tree (SPOT) server.

The nas_filer resource server is available in the NIM environment, and requires an interface attribute and a password file. You must manually define export rules and perform storage and disk management before you use any NIM operations.

To create resources on a NAS device by using the nas_filer resource server, complete the following steps:

Define the nas_filer object. You can enter a command similar to the following example:

    # nim -o define -t nas_filer -a if1="find_net als046245.server.com 0" -a passwd_file=/export/nim/pswfile netapp1

Define a mksysb file that exists on the NAS device as a NIM resource. You can enter a command similar to the following example:

    # nim -o define -t mksysb -a server=netapp1 -a location=/vol/vol0/nim_lun1/client1.nas_filer NetApp_bkup1

If necessary, create a new resource (client backup) on the NAS device. You can use the following command to create a mksysb resource:

    # nim -o define -t mksysb -a server=netapp1 -a location=/vol/vol10/nim_lun1/mordor05_bkup -a source=mordor05 -a mk_image=yes NetApp_mordor05

If necessary, copy an existing NIM resource to the nas_filer object. You can use the following command to copy a mksysb resource.

    # nim -o define -t mksysb -a server=netapp1 -a location=/vol/vol10/nim_lun1/replicate_bkup -a source=master_backup NetApp_master_backup

SOURCE: IBM Knowledge Center

Remplis sous: AIX, NAS, NIM Aucun commentaire

Adding a nas_filer management object to the NIM environment

Follow the instructions to add a nas_filer management object.

If you define resources on a network-attached storage (NAS) device by using the nas_filer management object, you can use those resources without changing the network information and configuration definition changes on the Shared Product Object Tree (SPOT) server. To add a nas_filer object, the dsm.core fileset must be installed on the NIM master.

To add a nas_filer object from the command line, complete the following steps:

Create an encrypted password file that contains the login ID and related password on the NIM master to access the nas_filer object. The encrypted password file must be created by using the dpasswd command from the dsm.core fileset. If you do not want the password to be displayed in clear text, exclude the -P parameter. The dpasswd command prompts for the password. Use the following command as an example:

    # dpasswd -f EncryptedPasswordFilePath -U nas_filerLogin -P nas_filerPassword

Pass the encrypted password file in the passwd_file attribute by using the define command of the nas_filer object. Use the following command as an example:

    # nim -o define -t nas_filer -a passwd_file=EncryptedPasswordFilePath \
    -a if1=InterfaceDescription \
    -a net_definition=DefinitionName \

If the network object that describes the network mask and the gateway that is used by the nas_filer object does not exist, use the net_definition attribute. After you remove the nas_filer objects, the file that is specified by the passwd_file attribute must be removed manually.

To add a nas_filer object that has the host name nf1 and the following configuration:

host name=nf1
password file path=/etc/ibm/sysmgt/dsm/config/nf1
network type=ethernet
subnet mask=
default gateway=gw1
default gateway used by NIM master=gw_maste, enter the following command:

# nim -o define -t nas_filer -a passwd_file=/etc/ibm/sysmgt/dsm/config/nf1 \
-a if1="find_net nf1 0" \
-a net_definition="ent gw1 gw_master" nf1

For more information about adding a nas_filer object, see the technical note that is included in the dsm.core fileset (/opt/ibm/sysmgt/dsm/doc/dsm_tech_note.pdf).

Remplis sous: AIX, NAS, NIM Aucun commentaire

NAS backup fails with ANR8758W on EMC DATADOMAIN

ANR1069E ANR8758W failure for NAS (NDMP) backup indicating there are insufficient mount points and the drives to not match the number of paths for the source node.

NAS (NDMP) backup fails with:

ANR8758W The number of online drives in the VTL library NASLIB does not match the number of online drive paths for source NASNODE.
ANR1069E NAS Backup process 33 terminated - insufficient number of mount points available for removable media.

The problem was seen in an environment with a Unix server, Protectier VTL and Network Appliance (NetApp) NAS, but may also occur in other environments.
Resolving the problem

In this case, the error was resolved by changing the Library Type from VTL to SCSI.

Use the Tivoli Storage Manager command: UPDATE LIBR LIBTYPE=SCSI

Taggé comme: Aucun commentaire

How is Tivoli Storage Manager applying versioning to NAS backups?

To backup NAS filer using NDMP protocol a Tivoli Storage Manager client NAS node needs to be defined to the Tivoli Storage Manager server. This Tivoli Storage Manager client node belongs to a policy domain as all other nodes.
Therefore Tivoli Storage Manager policies (like versioning) apply to Tivoli Storage Manager NAS backups, too.

Tivoli Storage Manager versioning applies to the complete NDMP dump only because the Tivoli Storage Manager server is not aware of the single objects included in the NDMP dump (except when reading the TOC).
To apply Tivoli Storage Manager versioning to single objects the single objects within the NDMP dump would need to have their own Tivoli Storage Manager server internal object ID assigned which is NOT the case.
In addition, if Tivoli Storage Manager versioning would apply to single objects within the NDMP dump something similar to aggregate compression had to be available to "delete" the invalid objects out of the NDMP dump which is NOT the case, too.

For a NAS filesystem, full and differential backups are grouped, with the full backup being the peer group leader.

If for example VEREXISTS = 4 and you do a full backup followed by 3 differentials then your Tivoli Storage Manager server database will have 4 versions of this backup image.
The next differential backup of the NAS filer will expire the full backup (but the Tivoli Storage Manager server is still keeping it internally, since it is needed to restore any of the differential images ).

The Tivoli Storage Manager server may store a full backup in excess of the number of versions you specified. When this happens, the full backup will stay in Tivoli Storage Manager database until all dependent backups have expired.

'QUERY NASBACKUP' will not show this extra version.

Use SQL 'SELECT' statements and/or 'SHOW VERSION' Tivoli Storage Manager server commands to see this extra version.

Use the following command to examine the dependency of full image and differential image backups:

'show version nodename filespace_name'

/vol/vol1 : /NAS/ IMAGE (MC: default)
Inactive, Inserted 05/25/05 11:14:57, Deactivated 1900-01-01 00:00:00.000000
ObjId: 0.138114, GroupMap 00050000, objType 0x0b
Attr Group Leader, GroupId: 0.138114
Delta Group Leader, GroupId: 0.138114

We see this version is deactivated already (Deactivated 1900-01-01 00:00:00.000000), it should have expired, but it stays in the Tivoli Storage Manager server database because it is a delta group leader (GroupId: 0.138114) and the following delta member (GroupId: 0.138114) has not yet expired:

/vol/vol1 : /NAS/ IMAGE (MC: Default)
Inactive, Inserted 07/20/05 20:41:28, Deactivated 07/27/05 22:15:21
ObjId: 0.179387, GroupMap 00040001, objType 0x0c
Delta Group Member, GroupId: 0.138114
Attr Group Leader, GroupId: 0.179387

In the example above, Delta Group Leader represents the full image backup and the Delta Group Member the differential image backup.

Important to understand:
Although the already expired full and differential NAS backups can be seen, it is not possible to do a point in time (PIT) restore from the date of an expired full or differential backup! It is only possible to do a PIT restore from full and differential NAS backups that have not yet expired.

SOURCE: 1200154

Taggé comme: Aucun commentaire