Very Computer

The idea being to use Sun's (unix's?)  "script"-cmd to keep a record of
what rolls-off the top of the (single-user-mode) screen when
doing a multi-hour set of level-0 ufsdumps, one per
partition on the machine.

Now, I suppose doing this wouldn't be safe to have the script-log
living (and growing) on a partitfion that is *not* the one
*currently* being ufsdumped.

(Otherwise that partition's ufsdump would be, uh, worthless?
 True?)

So, I'd have to make sure to have at least *two* partitions
mounted, root and, say, "partition-b" -- which I'd arrange to
get ufsdumped *last*.

Then, until it was time to ufsdump partition-b, I could
do all the others under, say, a single

    "script /some-partition-b-dir/ufsdump.log"

, and when those n-1 partitions had been ufsdumped, exit
that script-job, and start another:

    "script /some-ROOT-partition-dir/ufsdump.log"

this time leaving partition-b "quiescent" for *its* ufsdump.

When *that's* done, I cat together the two .log-files,
and I have a record of the whole thing.

QUESTION-1: does this scheme make any sense?

QUESTION-2: would it be similarly safe(?) to run the ufsdumps
via an EMACS *shell*-window, being sure, *before* starting
up EMACS, to:

     cd /some-ROOT-partition-dir/foodir

Being in single-user mode and thus without CDE or X-11, i'd be running emacs'
via its "--no-windows" option.

  (oops: just now tried to test runing emacs like that,
  right now, when cde *is* up -- emacs comes up uses fonts,
  colors, etc, *anyway*!  I used -nw, and then added, as a
  WAG, "-t /dev/cua" too.

  So, how *do* you invoke emacs so that it thinks it's
  back in pre-Sun days, running on a glass-tty?)

----- And something apparently "off the wall": tempfs  

(Oh, I suppose I *could* use tmpfs to keep the growing log,
since if that works as advertised, it touches NO diskk.

But -- I dimly reacll some recent warning, on this newsgroup,
tot NOT use tempfs while ufsdumping -- although I forget the
reason.)

Thanks!

David

Why not?

Quote:> (Otherwise that partition's ufsdump would be, uh, worthless?
>  True?)

Why?

I don't see a problem here.  Are you worried about ufsdump consistency,
or are you worried about being able to retrieve the log file from the
actual ufsdump backup?

Quote:> QUESTION-1: does this scheme make any sense?

Not to me.

Quote:>   So, how *do* you invoke emacs so that it thinks it's
>   back in pre-Sun days, running on a glass-tty?)

'emacs -nw'

Quote:> (Oh, I suppose I *could* use tmpfs to keep the growing log,
> since if that works as advertised, it touches NO diskk.

No, it's not a ram disk.  It could touch any swapfile.  However that
shouldn't be a problem either.

Quote:> But -- I dimly reacll some recent warning, on this newsgroup,
> tot NOT use tempfs while ufsdumping -- although I forget the
> reason.)

I'd want to know the reason rather than accept speculation about a vague
problem.

--

Unix System Administrator                    Taos - The SysAdmin Company
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

About ufsdump consistency, if *while* usfdump is in the middle of
backing-up some (largish) slice, you write *into* that very slice.

Now, I have no idea at all at the data structures that ufsdump
is copying and also creating to write to the dump-tape,
and thus what damage might result from eg some pointer
that when written to the tape no longer points back to part of the
slice that have *already* been saved to the tape, but which
pointer, just before it got saved too, was modified ty
the file-system (due to your writing-to-disk) to point
somewhere *else*, and  it's *that* value that got saved
to tape.

So that when a ufsrestore is done, there's *nothing* on the tape
*points* at that earlier-written data.

(I'm sure that's clear as mud -- you're seeing my confusion.)

Anyway, why else does everyone insist that you go to single-user
and otherwise guarantee a "quiescent" file-system *while*
ufsdumping, if not for safety?

Confused,

David

"write" can mean different things.  I would have no expectation of
problems if (as the OP suggested) you were writing into or appending to
an existing file.  

I would expect problems if files were being created/deleted/moved during
the dump.

Quote:> Anyway, why else does everyone insist that you go to single-user
> and otherwise guarantee a "quiescent" file-system *while*
> ufsdumping, if not for safety?

It is for safety, but the risk level is not very high to me in most
situations.

The OP seemed most concerned with the fact that a log file on the target
filesystem would be written to.  That fact alone doesn't really concern
me, and it doesn't automatically make it "worthless".

It does increase the risk of a problem with the dump.  

I suppose instead of saying that having a single file in use doesn't
really increase my perception of the risk much, I could have stated that
this is a wonderful situation to use 'fssnap' and snap off a consistent
image and dump it instead.  (of course that has other issues if you're
using timestamping, but they too are minimized if the log is the only
thing being written to).

--

Unix System Administrator                    Taos - The SysAdmin Company
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

Heck, one guy from sunservice *strongly* advised me
to, when ufsdumping the boot-disk, to do it via
first booting from the CD!

That does guarantee that everything's "quiescent" --
*super* quiescent!

He also said that any *open* files wouldn't get dumped,
so, he said, it'd be a real no-no to even have a "view"
(vi) sitting in background while ufsdumping that file's
filesystem.

     ----------

Geez, you talk to 5 sunservice-people, you get >> 5 (different) opinions.

Thanks,

David

Yup, pretty much what the ufsdump man page tells you :
     When running ufsdump, the file sys-
     tem must be inactive; otherwise, the output of  ufsdump  may
     be  inconsistent and restoring files correctly may be impos-
     sible. A file system is inactive when it is unmounted or the
     system  is  in  single user mode.

Booting from CD-ROM is the only way you can guarantee that the root
filesystem isn't being written to. Booting into single-user mode will
give you a 99.9% solution (in single user nothing should be writing to /,
but that doesn't mean that something can't).

Using fssnap is a better solution as it gives the best of both words - a
read-only snapshot and a multi-user system.

Quote:> That does guarantee that everything's "quiescent" --
> *super* quiescent!

Yes. Especially if you mount the filesystem read-only.

Quote:> He also said that any *open* files wouldn't get dumped,
> so, he said, it'd be a real no-no to even have a "view"
> (vi) sitting in background while ufsdumping that file's
> filesystem.

Not true as such. Unix doesn't generally have a concept of an "open" file
in the same sense that many other OSes do. The problem comes about when
something gets written to the filesystem whilst the dump is occuring. In
the case of running "view" on a file this would probably only be an issue
if you were backing up the filesystem which contained /var/tmp, where view
writes data when you run it...

Quote:> Geez, you talk to 5 sunservice-people, you get >> 5 (different) opinions.

I suppose we're now up to 6 from 6 :)

  Scott.

Yup, pretty much what the ufsdump man page tells you :
     When running ufsdump, the file sys-
     tem must be inactive; otherwise, the output of  ufsdump  may
     be  inconsistent and restoring files correctly may be impos-
     sible. A file system is inactive when it is unmounted or the
     system  is  in  single user mode.

Booting from CD-ROM is the only way you can guarantee that the root
filesystem isn't being written to. Booting into single-user mode will
give you a 99.9% solution (in single user nothing should be writing to /,
but that doesn't mean that something can't).

Using fssnap is a better solution as it gives the best of both words - a
read-only snapshot and a multi-user system.

Quote:> That does guarantee that everything's "quiescent" --
> *super* quiescent!

Yes. Especially if you mount the filesystem read-only.

Quote:> He also said that any *open* files wouldn't get dumped,
> so, he said, it'd be a real no-no to even have a "view"
> (vi) sitting in background while ufsdumping that file's
> filesystem.

Not true as such. Unix doesn't generally have a concept of an "open" file
in the same sense that many other OSes do. The problem comes about when
something gets written to the filesystem whilst the dump is occuring. In
the case of running "view" on a file this would probably only be an issue
if you were backing up the filesystem which contained /var/tmp, where view
writes data when you run it...

Quote:> Geez, you talk to 5 sunservice-people, you get >> 5 (different) opinions.

I suppose we're now up to 6 from 6 :)

  Scott.

Thanks so much for the, uh, unwelcome but perhaps worklife-saving
news!  

BTW, maybe you could say a bit more about this fssnap;
meanwhile, I'll go google it, or maybe first go look
at blastwave or sunfreeware to see what's there.

Thanks!

David

...

Quote:

>BTW, maybe you could say a bit more about this fssnap;
>meanwhile, I'll go google it, or maybe first go look
>at blastwave or sunfreeware to see what's there.

GOOD LORD!  Please ignore my stupid request --
it's already been answered, and very nicely too!

Sorry.....

David