Configuring NFS backup using DOMAIN or VIRTUALMOUNTPOINT

phajhu

ADSM.ORG Member
Joined
Feb 25, 2009
Messages
22
Reaction score
0
Points
0
Location
Baltimore MD
Hi. I've worked with TSM 5.5 for a month now. I'm still trying to get all of my client machines into TSM. I have a few legacy Linux machines running operating systems too old for 5.5, 5.4 or 5.3 clients (based on limited install efforts).

Seems to me that backing them up via NFS mounts on clients running 5.5 would be preferable to trying harder to get old TSM clients to work (b/c of the bugs in both the old TSM clients and their operating systems, etc). I'm willing to pay the networking penalty and not get ACL's captured.

TSM 5.5 server is on RHEL 5.1
TSM clients - new and old - are pretty much all Redhat based

My goal would be to choose one or two modern machines, configure them to automount the few older machine's file systems, and modify their TSM configuration to include these specific file systems. (They would be able to automount other file systems so I wouldn't just enable all-autofs or whatever the right DOMAIN syntax is.)

1) Is this technique used with any frequency? Am I out in the wild with it? The two pages in UNIX and Linux: Backup-Archive Clients Installation and User's Guide about Backing up NFS file systems are really poor and seem AIX-specific. I'm going on the on-line help inside dsmadmc and dsmc.

2)
Should I use DOMAIN or VIRTUALMOUNTPOINT statements?
2a) Can DOMAIN statements really go in either dsm.opt or dsm.sys?
2b) Do DOMAIN statements change the way normal daily incrementals work or do they only allow the NFS mount point to be specified (see below for my results and you'll understand why I ask this)?

3) How can I tell if my statements are going to have the desired effect?
(I manually NFS mounted a file system from an old Redhat 7.3 system onto a RHEL 5.1 one at /import/skysrv/d0, added these DOMAIN statements to my dsm.sys file:
domain all-local
domain /import/skysrv/d0

restarted dsmcad, then queried file spaces on the server (and on the client) but did not see the new target mount point listed. I then moved the statements to dsm.opt, restarted dsmcad, and still did not see any part of the path /import/skysrv/d0 listed with "q fi clientname" I fired off an incremental of the client with DEFINE CLIENTACT nodename command and afterwards still did not see the new file space listed.

4) :confused: I cannot find again a web page I found recently which looked like an extensive set of configuration arguments for a NFS situation which appeared to be from some TSM file (I guess that would be a dsm.{opt,sys}...). It looked very juicy and detailed and even had comments about what the reasoning was for including all of these entries. Included were specifications of both the NFS client and NFS server names and the paths for the file system to be NFS-mounted.....
However, reading the manual pages for DOMAIN and VIRTUALMOUNTPOINT don't reveal nearly the number or complexity of parameters I recall seeing. WAS I DREAMING THIS?

5) I have now manually started what looks like a successful backup with this command: def clientact nodename obj="/import/skysrv/d0"

6) Would there be any issues with ownership or permissions (other than ACL's of which we have very few if any) when restoring from such backups onto the TSM client we used to make the backups in the first place?

7) Would the file systems be automounted during backup or is this partially the function of using DOMAIN arguements like auto-nfs ???? I mean does the TSM backup/archive client do anything special to enable backups of automounts to work?

Thanks a lot.
 
Last edited:
Hi. I've worked with TSM 5.5 for a month now. I'm still trying to get all of my client machines into TSM. I have a few legacy Linux machines running operating systems too old for 5.5, 5.4 or 5.3 clients (based on limited install efforts).

Seems to me that backing them up via NFS mounts on clients running 5.5 would be preferable to trying harder to get old TSM clients to work (b/c of the bugs in both the old TSM clients and their operating systems, etc). I'm willing to pay the networking penalty and not get ACL's captured.

TSM 5.5 server is on RHEL 5.1
TSM clients - new and old - are pretty much all Redhat based

My goal would be to choose one or two modern machines, configure them to automount the few older machine's file systems, and modify their TSM configuration to include these specific file systems. (They would be able to automount other file systems so I wouldn't just enable all-autofs or whatever the right DOMAIN syntax is.)

1) Is this technique used with any frequency? Am I out in the wild with it? The two pages in UNIX and Linux: Backup-Archive Clients Installation and User's Guide about Backing up NFS file systems are really poor and seem AIX-specific. I'm going on the on-line help inside dsmadmc and dsmc.

2)
Should I use DOMAIN or VIRTUALMOUNTPOINT statements?

Use VIRTUALMOUNTPOINT as DOMAIN is Windows specific.

2a) Can DOMAIN statements really go in either dsm.opt or dsm.sys?
2b) Do DOMAIN statements change the way normal daily incrementals work or do they only allow the NFS mount point to be specified (see below for my results and you'll understand why I ask this)?

As I said, DOMAIN is Windows specific. VIRTUALMOUNTPOINT can go into the dsm.sys or dsm.opt file. I have tried both and it seems to work as what I desired.

3) How can I tell if my statements are going to have the desired effect?
(I manually NFS mounted a file system from an old Redhat 7.3 system onto a RHEL 5.1 one at /import/skysrv/d0, added these DOMAIN statements to my dsm.sys file:
domain all-local
domain /import/skysrv/d0

restarted dsmcad, then queried file spaces on the server (and on the client) but did not see the new target mount point listed. I then moved the statements to dsm.opt, restarted dsmcad, and still did not see any part of the path /import/skysrv/d0 listed with "q fi clientname" I fired off an incremental of the client with DEFINE CLIENTACT nodename command and afterwards still did not see the new file space listed.

Run a backup, either manually or through the scheduler and see if the files from the NFS mounts are shown when you open a GUI and had selected a restore, or by running a q backup from the dsmc prompt.

4) :confused: I cannot find again a web page I found recently which looked like an extensive set of configuration arguments for a NFS situation which appeared to be from some TSM file (I guess that would be a dsm.{opt,sys}...). It looked very juicy and detailed and even had comments about what the reasoning was for including all of these entries. Included were specifications of both the NFS client and NFS server names and the paths for the file system to be NFS-mounted.....
However, reading the manual pages for DOMAIN and VIRTUALMOUNTPOINT don't reveal nearly the number or complexity of parameters I recall seeing. WAS I DREAMING THIS?

Use the links you provided above.

5) I have now manually started what looks like a successful backup with this command: def clientact nodename obj="/import/skysrv/d0"

6) Would there be any issues with ownership or permissions (other than ACL's of which we have very few if any) when restoring from such backups onto the TSM client we used to make the backups in the first place?

7) Would the file systems be automounted during backup or is this partially the function of using DOMAIN arguements like auto-nfs ???? I mean does the TSM backup/archive client do anything special to enable backups of automounts to work?

You should have a method to mount the NFS mounts prior to a backup be it through scripts or as part of the backup schedule. There should be no issues about ACLs but the only way to verify this is by running some tests.

Thanks a lot.
 
I have been able to get this to work with the DOMAIN command on UNIX TSM clients running 5.5. The help inside dsmc for DOMAIN says "This option is valid for all UNIX and Linux clients."

I'm also using the AUTOMOUNT option.
(I'm still unclear on what the VIRTUALMOUNTPOINT is about.)

So I have a machine XYZ mounting other machines via NFS. XYZ's dsm.opt file includes two lines for each automounted file system:

domain /import/skysrv/d0
automount /import/skysrv/d0

Remember on the NFS server machine that you export the file systems you want backed up
1) read-only and
2) with no_root_squash

I did not need to specify any funky schedules; these automounted file systems are backed up when the machine XYZ is backed up.
 
Back
Top