Woes with backing up a loop-mounted filesystem

[JensD]

Hi

I'm in the process of setting up some NFS shares in a NFS v4 environment on RHEL7, where everything has to be mounted to the NFSv4 virtual root via loop mounts (mount --bind <cur dir> <new dir>).

During this process I experience a somewhat strange behaviour from the BA client (running BA client 7.1.2.2).

If I mount my homedir /home/jedc to the NFS virtual root /mnt/exports with this command
$ sudo mount --bind /home/jedc /mnt/exports/jedc
I get what I expect from NFS.

However, TSM begins to annoy me, and I tried all sorts of combinations (ALL-LOCAL, ALL-LOFS, ALL-AUTO-LOFS and specific mountpoints) for the domain options to no avail..

When the above mountpoint is NOT mounted, every file under /home/jedc/ is backed up as expected.

Since /mnt/exports/jedc is not a filesystem but only a directory, nothing is backed up from it either.
So far so good.

However, when I mount /mnt/exports/jedc to /home/jedc/ and do an incremental backup, all files from under /home/jedc are expired and every file is backed up under /mnt/exports/jedc.

How can I avoid that?
I do not wish to have a loop-mounted filesystem cause every file to move from the rightful owning filesystem to a loopmounted place - this potentially messes up everything if a loop mount is down when backups are run.

If I add "DOMAIN -/mnt/exports/jedc" to the options file, nothing gets backed up while /mnt/exports/jedc is mounted.

If I add "DOMAIN /home/jedc" all I get is an "ANS1071E Invalid domain name entered: '/home/jedc'" error when running the incremental backup.

What am I doing wrong?
I need to loopmount the individual parts of the filesystem to be able to use NFS, and I also need TSM not to move everything around if a new loopmount is added..

 

[smajl]

Are your mount points correctly configured in /etc/fstab? TSM client should be able to use info from it to distinguish what _is_ filesystem and what isn't

 

[JensD]

All the normal mountpoints are configured correctly in fstab, but not the bind mounted ones - those are handled as a part of starting nfs-server.service (via a ExecStartPre command) on my RHEL7 boxes and as an individual init-script to run before starting nfsd on the few RHEL6 boxes I have.

 

[JensD]

I've just tried to add the bind mount to /etc/fstab like this:

/home/jedc /mnt/exports/jedc none bind 0 0

The behaviour remains the same - when /mnt/exports/jedc is bind mounted to /home/jedc, nothing from /home/jedc is backed up.

 

[JensD]

Just a small update.

IBM tried to say "working as intented" in response to my original PMR, but since then I have verified my expectations (ie. a bind mount should not cause any data to be expired or shifted around) when using BA client 6.4.1.0 on RHEL6.

I still see the wrong behaviour on RHEL7 using BA client 7.1.2.2 and the latest patch 7.1.2.3 - the .3 patch had a small other bind mount fix (http://www-01.ibm.com/support/docview.wss?uid=swg1IT08831.

I have yet to try the 7.1.2.3 version on RHEL6, but I'm willing to bet on it also failing to do what I expect in regards to bind mount points..

 

[moon-buddy]

I believe regardless of what system you use, any change in mount point characteristics will trigger a file expiration and re-backup.

This simply means that TSM thinks the files have changed and/or deleted from the system based on its signature as related to the mount point.

 

[JensD]

Yes, but no..

A bind mount is not a real mount in a sense where new data is available.

A bind mount is almost the same as a hard link, but then again not really that - it operates on a different level in the filsystem, and it should not cause any data to shift around.

My tests with the 6.4 BA client does exactly what I expect.

When the bind mount point is mounted the "mount point directory" is expired from TSM when an incremental backup is run, but the data in it is ignored and NOT added under a new filespace since it actually resides and is still available from its original location in the filesystem.

If I unmount the bind mount an rerun an incremental backup the "mount point directory" is added to TSM again as an empty directory.

BA client 6.4 and 7.1 differs on that, and I believe that it's 6.4 that does the right thing - in any way it's a BIG difference between the two versions, and I have not seen any releasenotes or documentation for 7.1 that says it has been changed.

This makes it an error and a major showstopper for us - we are unable to use RHEL7 for a NFS server since it's only in BA version 7.x that has support for RHEL7. It also makes it impossible for me to upgrade any of our RHEL6-based machines from BA client 6.4 to any newer version..

 

[JensD]

Just a small update: IBM has finally acknowledged that this is an error in the 7.1 client and have sent it to their developers.