I'm not familiar with celerra, but on Netapp, TSM ignores the snapshot directories unless they are specifically mapped.
Are you sure the data that is being reported by TSM:q fi and the nas command are not snapshots? Maybe there is something special about the data on vol0 that is excluding it? Also, run "QUERY VIRTUALFSMAPPING" and see if there is anything strange in there. Maybe "/vol0" is being redirected to a subfolder Regards, Shawn ________________________________________________ Shawn Drew Internet [EMAIL PROTECTED] Sent by: ADSM-L@VM.MARIST.EDU 06/12/2008 05:42 PM Please respond to ADSM-L@VM.MARIST.EDU To ADSM-L cc Subject [ADSM-L] NDMP backup successful but incomplete I've got an NDMP client (Celerra) with two file systems - /vol0, and /vol1. When I run the backup (fulls only), /vol1 gets a complete backup, but /vol0 backs up only a few kilobytes, and the process ends as Successful. To be more specific: 06/12/08 10:17:12 ANR2017I Administrator RNLEAF issued command: BACKUP NODE SVGMN14GLBSM07 /vol0 mode=full (SESSION: 36846) 06/12/08 10:17:14 ANR1063I Full backup of NAS node SVGMN14GLBSM07, file system /vol0, started as process 552 by administrator RNLEAF. (SESSION: 36846, PROCESS: 552) ... 06/12/08 10:17:37 ANR0988I Process 552 for BACKUP NAS (FULL) running in the BACKGROUND processed 43,482 bytes with a completion state of SUCCESS at 10:17:37. (SESSION: 36846, PROCESS: 552) and... 06/12/08 10:17:14 ANR2017I Administrator RNLEAF issued command: BACKUP NODE SVGMN14GLBSM07 /vol1 mode=full (SESSION: 36846, PROCESS: 552) 06/12/08 10:17:16 ANR1063I Full backup of NAS node SVGMN14GLBSM07, file system /vol1, started as process 553 by administrator RNLEAF. (SESSION: 36846, PROCESS: 553) ... 06/12/08 15:26:39 ANR0988I Process 553 for BACKUP NAS (FULL) running in the BACKGROUND processed 620,126,384,679 bytes with a completion state of SUCCESS at 15:26:39. (SESSION: 36846, PROCESS: 553) Now, the administrator of the Celerra can demonstrate that /vol0 has plenty of data in it: [EMAIL PROTECTED] nasadmin]$ nas_fs -size vol0 total = 1578910 avail = 900497 used = 678412 ( 42% ) (sizes in MB) ( blockcount = 3283714048 ) volume: total = 1603376 (sizes in MB) ( blockcount = 3283714048 )) [EMAIL PROTECTED] nasadmin]$ nas_fs -size vol1 total = 1578910 avail = 985584 used = 593326 ( 37% ) (sizes in MB) ( blockcount = 3283714048 ) volume: total = 1603376 (sizes in MB) ( blockcount = 3283714048 )) I see something similar when I look at the information TSM has about that file space: q filespace SVGMN14GLBSM07 /vol0 f=d Node Name: SVGMN14GLBSM07 Filespace Name: /vol0 Hexadecimal Filespace Name: FSID: 2 Platform: DartOS Filespace Type: uxfs Is Filespace Unicode?: No Capacity (MB): 1,578,910.2 Pct Util: 43.0 Last Backup Start Date/Time: 06/12/08 10:17:13 Days Since Last Backup Started: <1 Last Backup Completion Date/Time: 06/12/08 10:17:36 Days Since Last Backup Completed: <1 Last Full NAS Image Backup Completion Date/Time: 06/12/08 10:17:36 Days Since Last Full NAS Image Backup Completed: <1 I don't know what kind of settings he might have on his end that might affect how TSM accesses, or fails to access, a file system on the Celerra. As you can see, the commands issued to invoke the backups are identical. No client option sets are applied to the node. TSM server is ver 5.3.5.2 on AIX 5.3; backing up to a VTL emulating a 3584 with LTO drives. If the version of DART on the Celerra matters, I'll dig it up. Does anyone have a theory as to why the /vol0 backup isn't backing up the data that's there, while the backups of /vol1 are working fine?, Thanks in advance! Robben Leaf --------------------------------------------------------------------- This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. Please note that certain functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.
