ADSM-L

[ADSM-L] NFS Backups with -snapshotroot slightly insane?

2010-08-05 12:01:49
Subject: [ADSM-L] NFS Backups with -snapshotroot slightly insane?
From: "Allen S. Rout" <asr AT UFL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 5 Aug 2010 12:00:22 -0400
We've got substantial NFS infrastructure over here, and we're
gradually migrating to NASland.  We're not pleased with NDMP, so we're
doing proxy backups, and have found a pocket of insane behavior.

This is RHEL 5.5, against an EMC NSG8.  I've duplicated the behavior
with TSM client versions 5.5.2 and 6.2.1


I'll start with a distilled example, and then talk about how I got
there.

Start with nothing NFS mounted.  Then:

mount nfs-server:/export/homes  /mnt/homes

dsmc incr /homes -snapshotroot /mnt/homes

[ an incremental happens.  Whee! ]

Then:

mount nfs-server:/export/homes/someuser  /mnt/someuser

dsmc incr /homes -snapshotroot /mnt/homes

'someuser' gets expired out of the backup.


I can read files from /mnt/someuser/blah and /mnt/homes/someuser/blah
while this is going on; consequently, both the NFS server and client
are capable of dealing with the double-mounted space.  It's just TSM's
logic.  I'm currently re-running the experiment without the
snapshotroot to exclude that.

I got here because, after setting up a new proxy machine, I chanced to
log into it as me, not just as root.  Next incr I ran, I saw it
expring all my stuff, which was a shock.  So I started trying to
remove variables from the equation.  I was willing to blame it all on
the automounter, but then I turned that off and still got the problem
with static mounts.

The namespace the world sees is the '/homes/' one (actually '/h/', but
who's counting?)  and we wanted to use snapshotroot to permit us to
advertise that namespace, for simplicity of restores.


Anyone inclined to confirm?



- Allen S. Rout

<Prev in Thread] Current Thread [Next in Thread>
  • [ADSM-L] NFS Backups with -snapshotroot slightly insane?, Allen S. Rout <=