On Wed, 04 Aug 2004 00:04:05 +0000, Akop Pogosian wrote:
> Alan Coopersmith <alanc@alum.calberkeley.org> wrote:
>> "Nigel P. Longbottom" <not@all.valid> writes in comp.sys.sun.admin:
>> |I suppose my real point was a dig at Sun support...
>> |...not to backup while filesystems are mounted...
>
>> ..."*ufsdump* of a mounted filesystem is not reliable due to the way it
>> scans the UFS structure then dumps the data, going in below the
>> filesystem level and may get very confused if the filesystem layout
>> changes between the read of the UFS structures and the read of the
>> data. To backup a filesystem without unmounting, you can mirror it...
>
> But how do you know the file system data structures on the disk are in a
> consistent state at the moment when you're detaching the mirror?
> Shouldn't the file system be unmounted first before detaching the
> mirror?

That is an interesting question. I expected to see a note in the
metadetach man page explicity saying that a sync is done before the mirror
is actually detached, to ensure that these system data structures on
the mirror disk are consistent. There is no such explicit note. It would
only make sense (to me) if there was a sync. Can anyone confirm?

--
Juhan Leemet
Logicognosis, Inc.

Akop Pogosian wrote:
>
> Alan Coopersmith <alanc@alum.calberkeley.org> wrote:
> > "Nigel P. Longbottom" <not@all.valid> writes in comp.sys.sun.admin:
> > |I suppose my real point was a dig at Sun support. My initial query was about
> > |backup rates to tape but I ended up being told that the problem was due to
> > |mounted filesystems. With the competition in UNIX markets, I would say Sun
> > |is damaging itself by saying not to backup while filesystems are mounted
> > |(and they were adamant about this). I've been doing this for years
> > |(obviously while the filesystems are quiet i.e. Oracle is shut down and the
> > |servers are not active 24x7) and have no problems when restoring from these
> > |backups in a Disaster Recovery exercise.
>
> > It's been a long time (almost 9 years) since I worked in Sun tech support
> > answering questions about backups, but I think the answer we gave then
> > is still basically true today - and is close to, but more detailed than
> > what you seem to have been told. The party line then was not "don't do
> > backups of mounted filesystems", but was actually "*ufsdump* of a mounted
> > filesystem is not reliable due to the way it scans the UFS structure
> > then dumps the data, going in below the filesystem level and may get
> > very confused if the filesystem layout changes between the read of the
> > UFS structures and the read of the data. To backup a filesystem without
> > unmounting, you can mirror it, then break the mirror temporarily, backup
> > the mirror and then resync, or use a different backup utility that is
>
> But how do you know the file system data structures on the disk are in
> a consistent state at the moment when you're detaching the mirror?

you know this when you issued a lockfs(1M) -f /filesystem
before doing the detach.

---
frankB

> Shouldn't the file system be unmounted first before detaching the
> mirror?
>
> -akop

Alan Coopersmith wrote:
[...]
> what you seem to have been told. The party line then was not "don't do
> backups of mounted filesystems", but was actually "*ufsdump* of a mounted
> filesystem is not reliable due to the way it scans the UFS structure
> then dumps the data, going in below the filesystem level and may get
> very confused if the filesystem layout changes between the read of the
> UFS structures and the read of the data. To backup a filesystem without

this is actually quite correct, ufsdump goes directly to the raw device
when scanning the filesystem meta data, which are usually on a mounted
filesystem held in the buffer cache for the most recent changes and
the buffer cache gets written from time to tome out to disk, thus ufsdump
likely can live in the past when doing a backup of the mounted filesystem
and thus it's manpage already states this possibility,

> unmounting, you can mirror it, then break the mirror temporarily, backup
> the mirror and then resync, or use a different backup utility that is

dont forgott to issue lockfs(1M) -f to flush the filesystems meta data
and in case logging is enabled to roll the log prior to breaking the mirror.

---
frankB

> designed to cope with change, such as Solstice Backup/Legato Networker."
> The biggest change I know of since then is the addition of ufs snapshots
> as yet another option.
>
> --
> __________________________________________________ ______________________
> Alan Coopersmith * alanc@alum.calberkeley.org * Alan.Coopersmith@Sun.COM
> http://www.csua.berkeley.edu/~alanc/ * http://blogs.sun.com/alanc/
> Working for, but definitely not speaking for, Sun Microsystems, Inc.

Frank Batschulat <frank.batschulat@IHATESPAM.Sun.COM> writes in comp.sys.sun.admin:
|dont forgott to issue lockfs(1M) -f to flush the filesystems meta data
|and in case logging is enabled to roll the log prior to breaking the mirror.

Right - I had forgotten about that in the years since I've had to do this.

--
__________________________________________________ ______________________
Alan Coopersmith * alanc@alum.calberkeley.org * Alan.Coopersmith@Sun.COM
http://www.csua.berkeley.edu/~alanc/ * http://blogs.sun.com/alanc/
Working for, but definitely not speaking for, Sun Microsystems, Inc.