My NDMP backup has gone missing!

[rizhun]

Hi Guru's,

I've recently set up NDMP backups from our NetApp NAS servers to our TSM 5.5.3.0 server.

I added a 'virtualfsmapping' and ran a full backup as a proof-of-concept. Everything worked a treat, the backup was wicked fast, I could restore individual files and was generally well chuffed.

After my proof-of-concept, I was dragged onto another project that was deemed a higher priority by management (sigh).

Now I've come back to TSM to find that my proof-of-concept backup has vanished!

>q nasbackup NAS-B *
ANR2034E QUERY NASBACKUP: No match found using this criteria.
ANS8001I Return code 11.

But it's still there on a 'q occ':

>q occ NAS-B

Node Name      Type     Filespace       FSID     Storage        Number of      Physical       Logical
                        Name                     Pool Name          Files         Space         Space
                                                                               Occupied      Occupied
                                                                                   (MB)          (MB)
----------     ----     ----------     -----     ----------     ---------     ---------     ---------
NAS-B          Bkup     /archive           1     NASTOCPOOL             1         42.22         42.22
NAS-B          Bkup     /archive           1     NAS_ONSITE             1     115,526.4     115,526.4

And it's still holding the tapes:

>q vol dev=nas

Volume Name                  Storage         Device         Estimated       Pct      Volume 
                             Pool Name       Class Name      Capacity      Util      Status 
------------------------     -----------     ----------     ---------     -----     --------
LTO097L3                     NAS_ONSITE      NAS                1.0 T      11.3     Filling

>run tape_contents LTO097L3

FILESPACE_NAME            SIZE_MB     BACKUP_TYPE       
------------------     ----------     ------------------
/archive                115526.00     Bkup              

  TOTAL_GB
----------
    112.00
ANR1462I RUN: Command script TAPE_CONTENTS completed successfully.

Am I being a muppet and missing something really obvious here?
What's going on? If it had been 'expired', wouldn't it have marked the tape as 'empty'?

Thanks for reading, I look forward to your replies.
- Riz

 

[Harry_Redl]

Hi,

sure shot is:
select * from backups where nodename='NAS-B'

what caused your problem (most probably)
do not forget that "q nasbackup" command uses "begind=today-7" as default .... so try for "q nasbackup nas-b * begind=-365"

Harry

 

[rizhun]

Hi Harry,

You were right, that found it!
Thanks a lot for your help.

1 more quick question:
When I run another backup of the same virtualfs, it seems to overwrite the original.
Is this expected behaviour? Is there any setting I can change to stop this? Or do I just need unique (ie. dated) vfs names?

Thanks again,
- Riz.

 

[Harry_Redl]

Hi,

no, it just moves the old_image to inactive version - if the corresponding copygroup says to keep one version only, then the old_version is expired/deleted - do not forget that all retextra/retonly options apply as well.
Use the select to see if there is any inactive version.

My VFSmappings are fixed - like this:
define virtualfsmapping nas1 /VFS1 /vol/VOL1 /.snapshot/sqlsnap__whatever__recent
define virtualfsmapping nas1 /VFS2 /vol/VOL2 /.snapshot/nightly.0


Harry

 

[rizhun]

Thanks for your help Harry.
Increasing VerDE shows the older backups.

I have another question to throw into the mix though:
Why don't my off-site COPY pools work as expected?

I run a backup.

backup node nas-b /archive mode=full

Then I send the TOC its next pool, which is TAPE_ONSITE:

migrate stgpool NASTOCPOOL lowmig=0 wait=yes

Then I backup TAPE_ONSITE to TAPE_OFFSITE, to create my off-site copy:

backup stgpool TAPE_ONSITE TAPE_OFFSITE maxpr=1 wait=yes

Then I backup NAS_ONSITE to NAS_OFFSITE (these pools are both of the NETAPPDUMP type):

backup stgpool TAPE_ONSITE TAPE_OFFSITE maxpr=1 wait=yes

Then I do my other DR stuff:

backup volhistory
backup devconfig
backup db devclass=lto type=full scratch=yes wait=yes

Next I eject my DR media tapes:

move drmedia * wherestate=mountable enddate=today-1 tostate=courier tolocation=Firesafe wait=yes

But the NAS_OFFSITE tapes don't come out and they are not listed in 'q drmedia'.
My latest full backup is now showing as being stored on NAS_OFFSITE:

>q nasbackup nas-b /archive begind=today-3

Node Name        Filespace       Object Type        Object      Creation      Has Table     Mgmt Class     Image     
                 Name                            Size (MB)        Date        of Conte-     Name           Storage   
                                                                              nts (TOC-                    Pool Name 
                                                                              )?                           
------------     -----------     -----------     ---------     ----------     ---------     ----------     ----------
NAS-B            /archive        Full Image      104,917.2     15/03/11       Yes           STANDARD       NAS_ONSITE
                                                                12:46:30                                             
NAS-B            /archive        Full Image      104,949.6     15/03/11       Yes           STANDARD       NAS_OFFSI-
                                                                13:31:06                                    TE

... So presumably even if I sent that tape off-site, I wouldn't be able to restore using an on-site copy.

I'm pretty confused here. Can't you use NDMP in this fashion?
How do you get your off-site copy any other way?

Thanks in advance,
Riz.

 

[Harry_Redl]

Hi,

what about "q drmstatus" output?

Harry

 

[rizhun]

That's weird...
The NAS pools aren't listed...
But those ARC_ pools are quite new, and I don't remember doing anything to add them here...

> q drmstatus

              Recovery Plan Prefix: /usr/local/backups/tsm_recovery_plans/
          Plan Instructions Prefix: /usr/local/backups/tsm_recovery_plans/
        Replacement Volume Postfix: @
             Primary Storage Pools: ARC_ONSITE BACKUPPOOL DB2_DISK DB2_ONSITE TAPE_ONSITE
                Copy Storage Pools: ARC_OFFSITE DB2_OFFSITE TAPE_OFFSITE
       Not Mountable Location Name: Harrogate
                      Courier Name: COURIER
                   Vault Site Name: IronMountain
  DB Backup Series Expiration Days: 3 Day(s)
Recovery Plan File Expiration Days: 8 Day(s)
                      Check Label?: Yes
         Process FILE Device Type?: No
                 Command File Name:

How do I add them?

Thanks!

 

[Harry_Redl]

Hi,

this should work:
set drmcopystgpool ARC_OFFSITE,DB2_OFFSITE,TAPE_OFFSITE,NAS_OFFSITE

Then you can test it using "q drmedia"

Harry

 

[rizhun]

Brilliant!
Thanks Harry.

Should I also add NAS_ONSITE? Using something like:

set drmprimstgpool ARC_ONSITE,BACKUPPOOL,DB2_DISK,DB2_ONSITE,TAPE_ONSITE,NAS_ONSITE

>set drmcopystgpool ARC_OFFSITE,DB2_OFFSITE,TAPE_OFFSITE,NAS_OFFSITE
ANR6700I SET DRMCOPYSTGPOOL command completed successfully.

>q drmstatus                                                         

              Recovery Plan Prefix: /usr/local/backups/tsm_recovery_plans/
          Plan Instructions Prefix: /usr/local/backups/tsm_recovery_plans/
        Replacement Volume Postfix: @
             Primary Storage Pools: ARC_ONSITE BACKUPPOOL DB2_DISK DB2_ONSITE TAPE_ONSITE
                Copy Storage Pools: ARC_OFFSITE DB2_OFFSITE TAPE_OFFSITE NAS_OFFSITE
       Not Mountable Location Name: Harrogate
                      Courier Name: COURIER
                   Vault Site Name: IronMountain
  DB Backup Series Expiration Days: 3 Day(s)
Recovery Plan File Expiration Days: 8 Day(s)
                      Check Label?: Yes
         Process FILE Device Type?: No
                 Command File Name:

 

[Harry_Redl]

Hi,

yes, you may - but it has no effect on tape rotation. Just for building the DR plan (and I am not sure if NetAppDUMP format stgpools are processed at all in the DR plan ....)

Harry