Alan Cheski <Alan_Cheski AT GULF DOT CA> writes:

> I have a Solaris 2.6 V3 ADSM client that I tried using a loopback
> filesystem on. I found that ADSM wouldn't do an incremental backup of the
> loopback filesystem or the filesystem that it loops back to. I created
> files in the loopback filesystem that causes the to be created in the
> original filesystem. But after a couple incrementals, the files were not
> backed up. As soon as I unmounted the loopback filesystem and did another
> incremental, the files in the original filesystem were finally backed up.
> Has anyone noticed this and/or found a way to resolve this? If I don't use
> loopback filesystem mounts, then I need to use soft-links which I would
> rather not do.

Absolutely! I've seen this problem and it's still on-going as far as
I'm concerned.

We have discs UFS mounted as:

/export/disk01, /export/disk02, /export/disk03, etc.

Inside /export/disk03 we could have a directory called 'Project' which
would then be remounted (LOFS) as '/Project'.

The V3 R1 L0.4 client backs up /Project and NOT /export/disk03/Project
(although it -will- back up the rest of /export/disk03).

I see this as a simple case of the programmers of the b/a client using
the wrong field out of /etc/vfstab!

There's a fixtest client (V3 R1 L0.3 T2 - otherwise known as
IP21297T2) that just backs up *everything* (LOFS, NFS, you name it -
it does it) and I'm using that until some newer client (V3 R1 L0.5?)
comes out that fixes the above properly. The IP21297T2 client is for
5.5.1 though but you can quote that when you phone IBM >:)

While they're at it, they had better fix the problem with files >2GB.

I'll be interested to hear how you get on.

Dominic Froud
--
Postmaster/Unix Systems Analyst,
Postmaster/Unix Systems Analyst,
Elsevier Science, Oxford, England.