How to Discover new Client after installing NBU agent?

Open NBU consol

In Left Pane, You will see Policy option in Netbackup console.

1. Click on policy Option- right click- new policy ( will see new window)

Here, you uncheck the "use backup policy configuration wizard", it will show in bottom of this window 

2. Give the Policy name.-click  Ok

3. You will see new window, in this window will see Client Tab- Click on this tab.

4. In this client tab window- Click on " New Button"

5. Put the client full name like. ab01c.tst.md

6. will automatically detect the Client O/S.

or using CLI

using the bpplclients command.

bpplclients -add

Example:

bpplclients my_test_policy -add my-test.mydomain.com Linux RedHat2.6

or for a Windows server

bpplclients my_windows_policy -add my-wintest.mydomain.com PC Windows2003

To confirm that it has been added you can run bppllist my_test_policy -U and review the list of clients in the policy.

Netbackup Issues: Policy has red cross mark, what does that mean?

If you see any "Red cross" mark as above mentioned figure, this means that the policy is de-activated so no backups taking place. Right-click on policy & "Activate".

Rescan Cmds after allocating Storage to AIX and Solaris

AIX:

AIX# cfgmgr
AIX# fget_config -Av

Solaris:

Solaris# devfsadm
Solaris# cfgadm -a
Solaris# format (to view new devices)

Netapp Snapmirror Setup.

Snapmirror is an licensed utility in Netapp to do data transfer across filers. Snapmirror works at Volume level or Qtree level. Snapmirror is mainly used for disaster recovery and replication.

Snapmirrror needs a source and destination filer. (When source and destination are the same filer, the snapmirror happens on local filer itself.  This is when you have to replicate volumes inside a filer. If you need DR capabilities of a volume inside a filer, you have to try syncmirror ).

Synchronous SnapMirror is a SnapMirror feature in which the data on one system is replicated on another system at, or near, the same time it is written to the first system. Synchronous SnapMirror synchronously replicates data between single or clustered storage systems situated at remote sites using either an IP or a Fibre Channel connection. Before Data ONTAP saves data to disk, it collects written data in NVRAM. Then, at a point in time called a consistency point, it sends the data to disk.

When the Synchronous SnapMirror feature is enabled, the source system forwards data to the destination system as it is written in NVRAM. Then, at the consistency point, the source system sends its data to disk and tells the destination system to also send its data to disk.

This guides you quickly through the Snapmirror setup and commands. 

1) Enable Snapmirror on source and destination filer 

source-filer> options snapmirror.enable 
snapmirror.enable            on 
source-filer> 
source-filer> options snapmirror.access 
snapmirror.access            legacy 
source-filer>

2) Snapmirror Access
Make sure destination filer has snapmirror access to the source filer. The snapmirror filer's name or IP address should be in /etc/snapmirror.allow. Use wrfile to add entries to /etc/snapmirror.allow.

source-filer> rdfile /etc/snapmirror.allow 
destination-filer 
destination-filer2 
source-filer>

3) Initializing a Snapmirror relation 

Volume snapmirror : Create a destination volume on destination netapp filer, of same size as source volume or greater size. For volume snapmirror, the destination volume should be in restricted mode. For example, let us consider we are snapmirroring a 100G volume - we create the destination volume and make it restricted.

destination-filer> vol create demo_destination aggr01 100G 
destination-filer> vol restrict demo_destination

Volume SnapMirror creates a Snapshot copy before performing the initial transfer. This copy is referred to as the baseline Snapshot copy. After performing an initial transfer of all data in the volume, VSM (Volume SnapMirror) sends to the destination only the blocks that have changed since the last successful replication. When SnapMirror performs an update transfer, it creates another new Snapshot copy and compares the changed blocks. These changed blocks are sent as part of the update transfer.

Snapmirror is always destination filer driven. So the snapmirror initialize has to be done on destination filer. The below command starts the baseline transfer.

destination-filer> snapmirror initialize -S source-filer:demo_source destination-filer:demo_destination 
Transfer started. 
Monitor progress with 'snapmirror status' or the snapmirror log. 
destination-filer>

Qtree Snapmirror : For qtree snapmirror, you should not create the destination qtree. The snapmirror command automatically creates the destination qtree. So just volume creation of required size is good enough.

Qtree SnapMirror determines changed data by first looking through the inode file for inodes that have changed and changed inodes of the interesting qtree for changed data blocks. The SnapMirror software then transfers only the new or changed data blocks from this Snapshot copy that is associated with the designated qtree. On the destination volume, a new Snapshot copy is then created that contains a complete point-in-time copy of the entire destination volume, but that is associated specifically with the particular qtree that has been replicated.

destination-filer> snapmirror initialize -S source-filer:/vol/demo1/qtree destination-filer:/vol/demo1/qtree 
Transfer started. 
Monitor progress with 'snapmirror status' or the snapmirror log.
4) Monitoring the status : Snapmirror data transfer status can be monitored either from source or destination filer. Use "snapmirror status" to check the status.

destination-filer> snapmirror status 
Snapmirror is on. 
Source                          Destination                          State          Lag Status 
source-filer:demo_source        destination-filer:demo_destination   Uninitialized  -   Transferring (1690 MB done) 
source-filer:/vol/demo1/qtree   destination-filer:/vol/demo1/qtree   Uninitialized  -   Transferring (32 MB done) 
destination-filer>

5) Snapmirror schedule : This is the schedule used by the destination filer for updating the mirror. It informs the SnapMirror scheduler when transfers will be initiated. The schedule field can either contain the word sync to specify synchronous mirroring or a cron-style specification of when to update the mirror. The cronstyle schedule contains four space-separated fields. 

If you want to sync the data on a scheduled frequency, you can set that in destination filer's /etc/snapmirror.conf . The time settings are similar to Unix cron. You can set a synchronous snapmirror schedule in /etc/snapmirror.conf by adding “sync” instead of the cron style frequency. 

destination-filer> rdfile /etc/snapmirror.conf 
source-filer:demo_source        destination-filer:demo_destination - 0 * * *  # This syncs every hour 
source-filer:/vol/demo1/qtree   destination-filer:/vol/demo1/qtree - 0 21 * * # This syncs every 9:00 pm 
destination-filer>

6) Other Snapmirror commands 

• To break snapmirror relation - do snapmirror quiesce and snapmirror break.
• To update snapmirror data  - do snapmirror update
• To resync a broken relation - do snapmirror resync.
• To abort a relation - do snapmirror abort

Snapmirror do provide multipath support. More than one physical path between a source and a destination system might be desired for a mirror relationship. Multipath support allows SnapMirror traffic to be load balanced between these paths and provides for failover in the event of a network outage.