ufsdump and verification

ufsdump and verification

Post by Andy Harper, KCL Systems Manag » Sun, 12 Mar 1995 03:36:26



I'm just setting up a few Sparcserver 20's running Solaris 2.3 and need to
instigate a regular backup regime.

ufsdump seemed the obvious thing to use but it doesn't seem to like verifying
what it's written. I'm writing to DAT tape with it in single user mode; each
time I use the verify option it gets so far and then dies with a verify
failure. I've tried it from different systems and with different DAT tapes and
still get the same problem.  Could someone please enlightem me as to why this
might occur, and whether this is a bug that has a fix (if so what). What do
others do to backup critical data?

I'm from the old school that says `double check all critical backed up data no
matter how much the hardware claims to be reliable!' so I'm quite unimpressed
by ufsdump's apparent inability to do this and I'm reluctant to entrust my
critical data to it at present. Having said that, I have restored successfully
from DAT tapes that have NOT verified (peculiar that!) but, of course, the day
it doesn't work is the day I'll really need it.

All thoughts welcomed.

Thanks

Andy Harper
Kings College London

 
 
 

ufsdump and verification

Post by Ben Thomps » Thu, 16 Mar 1995 02:31:03




Quote:>I'm just setting up a few Sparcserver 20's running Solaris 2.3 and need to
>instigate a regular backup regime.

>ufsdump seemed the obvious thing to use but it doesn't seem to like verifying
>what it's written. I'm writing to DAT tape with it in single user mode; each
>time I use the verify option it gets so far and then dies with a verify
>failure. I've tried it from different systems and with different DAT tapes and
>still get the same problem.  Could someone please enlightem me as to why this
>might occur, and whether this is a bug that has a fix (if so what). What do
>others do to backup critical data?

Well, unfortunately we still use 2.2.  In 2.2, you cannot verify a backup
of a mounted file system, because after you do the backup it will almost
certainly change.  You must first unmount the filesystems you are trying
to dump.  This will allow you to verify your backups.

Hope that helps!

Ben Thompson

System/Network Administrator
Gamma Biologicals Inc.

 
 
 

ufsdump and verification

Post by Ruth Miln » Thu, 16 Mar 1995 08:27:48




Quote:

>ufsdump seemed the obvious thing to use but it doesn't seem to like verifying
>what it's written. I'm writing to DAT tape with it in single user mode; each
>time I use the verify option it gets so far and then dies with a verify
>failure.

Are you working with a *umounted* filesystem, like the man page says?
Going into single-user mode without a reboot doesn't umount filesystems.

Quote:>I have restored successfully
>from DAT tapes that have NOT verified (peculiar that!)

There's nothing peculiar here, it just means that some file changed
between the time it was written to tape and the time it was verified.
It doesn't necessarily mean there is something bad on the tape (or
the disk).

The only way I have found to verify tapes is to do an interactive restore,
take a minute to hunt for the highest inode you can see listed anywhere
(it doesn't take long to get a feel for the range, even on a large file-
system), and restore that file somewhere (e.g. into /tmp). This forces
ufsrestore to read everything up to that point (hence the need to choose
a high inode).

But this doesn't lend itself well to automatic verification.

Despite this, ufsdump is still your best bet for reliable backups; it
will handle tape and even minor disk errors far better than anything
else. Nothing else I'm aware of offers much hope of verification either.
--
Ruth Milner                            NRAO                  Socorro NM

 
 
 

ufsdump and verification

Post by Chris Schmi » Fri, 17 Mar 1995 13:21:20


Speaking of ufsdump...I'm using a DAT. My backup statement, which works
great, is: ufsdump 0fu /dev/rmt/0n /dev/rdsk/c0t0d0s0.

I have this statement for each of my file systems and back it all up
onto a single type.

However, let's say I pop the tape out until the next time I want to do
a level 0 dump (I'm doing other dumps on a weekly and nightly basis).
Now, I want to do another level 0 dump using that first tape but I
don't want to overwrite my original dump. How do I tell the system to
seek to the end of the last session?

Thanks for the help,

 
 
 

ufsdump and verification

Post by Andy Harper, KCL Systems Manag » Fri, 17 Mar 1995 23:06:58



>>ufsdump seemed the obvious thing to use but it doesn't seem to like verifying
>>what it's written. I'm writing to DAT tape with it in single user mode; each
>>time I use the verify option it gets so far and then dies with a verify
>>failure. I've tried it from different systems and with different DAT tapes and
>>still get the same problem.  Could someone please enlightem me as to why this
>>might occur, and whether this is a bug that has a fix (if so what). What do
>>others do to backup critical data?

Ben Thomson replied:

Quote:> Well, unfortunately we still use 2.2.  In 2.2, you cannot verify a backup
> of a mounted file system, because after you do the backup it will almost
> certainly change.  You must first unmount the filesystems you are trying
> to dump.  This will allow you to verify your backups.

The filesystems being dumped are not mounted; the exceptions are root and /usr
(for some perverse reason, ufsdump exists in /usr rather than in the root file
system so dismounting /usr to back it up loses ufsdump!!!).

In single user mode, which I'm in, only the `necessary' file systems are
mounted (IE root and /usr).

Even if dismounting were to fix the problem, you still have the problem of how
to reliably (I.E. so that the verify option does NOT fail) back up root (and
maybe also /usr).

After talking to sun, I understand there's a product called NETWORKER which
does allow on-line backups reliably; more money of course... they seem to
tacitly admit that ufsdump is a little problematic in this area.

Since backup is such an important part of system management, I find it
mind-numbing that there's no RELIABLE way to do it. To my mind, ufsdump suffers
from the following problems:

1.      Backup data is not written with any kind of in-built redundancy checks
        so that some classes of tape error can be non-fatal (redundancy data
        should allow recovery from simple errors).

2.      If a verify error occurs it should be flagged, but the dump should
        not be considered fatal (optionally) if the tape is otherwise readable.
        This would allow on-line backup (at the system manager's discretion).
        One can argue the merits of on-line versus off-line but some sites
        have no choice (such as myself!)

3.      It appears to offer no protection against the wrong tape being
        inserted. Some kind of labelling mechanism, combined with expiry date
        protection would be a good move (which is in NETWORKER I'm lead to
        believe).

If anyone has successfully overcome the problems of reliable backup of file
systems, particularly of root and /usr, I would be more than happy to here how.

Regards,

Andy Harper
Kings College London

 
 
 

ufsdump and verification

Post by Davin Mil » Fri, 17 Mar 1995 23:41:28


?Speaking of ufsdump...I'm using a DAT. My backup statement, which works
?great, is: ufsdump 0fu /dev/rmt/0n /dev/rdsk/c0t0d0s0.
?
?I have this statement for each of my file systems and back it all up
?onto a single type.
?
?However, let's say I pop the tape out until the next time I want to do
?a level 0 dump (I'm doing other dumps on a weekly and nightly basis).
?Now, I want to do another level 0 dump using that first tape but I
?don't want to overwrite my original dump. How do I tell the system to
?seek to the end of the last session?

Use the mt command:
        mt -f /dev/rmt/0n eom
should take you to the end of the recorded stuff on the tape.  Or else use
the fsf command, to skip a certain number of EOF marks.

See the mt(1) man page for more details.

Davin.
-------------------------------------------------------------------------------


               Fax:       (716) 645-3464
               WWW:       http://www.cs.buffalo.edu/~milun/

 
 
 

ufsdump and verification

Post by Greg Robins » Sat, 18 Mar 1995 13:09:15




: >>ufsdump seemed the obvious thing to use but it doesn't seem to like verifying
: >>what it's written. I'm writing to DAT tape with it in single user mode; each
: >>time I use the verify option it gets so far and then dies with a verify
: >>failure. I've tried it from different systems and with different DAT tapes and
: >>still get the same problem.  Could someone please enlightem me as to why this
: >>might occur, and whether this is a bug that has a fix (if so what). What do
: >>others do to backup critical data?
: >>
: >

: Ben Thomson replied:
: > Well, unfortunately we still use 2.2.  In 2.2, you cannot verify a backup
: > of a mounted file system, because after you do the backup it will almost
: > certainly change.  You must first unmount the filesystems you are trying
: > to dump.  This will allow you to verify your backups.

: The filesystems being dumped are not mounted; the exceptions are root and /usr
: (for some perverse reason, ufsdump exists in /usr rather than in the root file
: system so dismounting /usr to back it up loses ufsdump!!!).

Sounds like AIX...

Heard of amanda?  IT's a network backup system, similar to networker, but
it's free.  ftp.cs.umd.edu:/pub/amanda  I think the dir is correct, have
a look about.  Not sure if it will do what you want, but it's excellent..

Greg.

--


 
 
 

ufsdump and verification

Post by Alain FAUCONN » Wed, 22 Mar 1995 04:26:33



[...]

Quote:>Since backup is such an important part of system management, I find it
>mind-numbing that there's no RELIABLE way to do it. To my mind, ufsdump suffers
>from the following problems:
>1.  Backup data is not written with any kind of in-built redundancy checks
>    so that some classes of tape error can be non-fatal (redundancy data
>    should allow recovery from simple errors).
>2.  If a verify error occurs it should be flagged, but the dump should
>    not be considered fatal (optionally) if the tape is otherwise readable.
>    This would allow on-line backup (at the system manager's discretion).
>    One can argue the merits of on-line versus off-line but some sites
>    have no choice (such as myself!)
>3.  It appears to offer no protection against the wrong tape being
>    inserted. Some kind of labelling mechanism, combined with expiry date
>    protection would be a good move (which is in NETWORKER I'm lead to
>    believe).

This really sounds to me like a perfect description of VMS  Backup
features,  which,  given  the  name of the author of this article,
doesn't quite surprise me ;-)

Yes, one of the very few issues  over  which  Unix  clearly  seems
inferior to VMS is backup tools. I *don't* want to start a new O/S
flame  war !!! I was a VMS guy, now I manage a mix of VMS and Unix
systems  and  I find both environments nice. Each has its areas of
superiority.

Writing a good Unix backup tool, with all the above features  plus
enough parallelism and multiple buffering to be efficient and keep
streamers busy, has been high on my "one day, if I have some spare
time" list. But it's been there for a long time already :-/

_Alain_
--
Alain FAUCONNET    Ingenieur systeme - System Manager     AP-HP/SIM
Public Health Research Labs  91 bld de l'Hopital 75013 PARIS FRANCE

Tel: (+33) 1-40-77-96-19                   Fax: (+33) 1-45-86-80-68
    I've RTFMed. It says: "Refer to your system administrator"
            But... I *am* the system administrator :-]

 
 
 

ufsdump and verification

Post by Andy Harper, KCL Systems Manag » Tue, 04 Apr 1995 04:00:00



>>Since backup is such an important part of system management, I find it
>>mind-numbing that there's no RELIABLE way to do it. To my mind, ufsdump suffers
>>from the following problems:

>>1.      Backup data is not written with any kind of in-built redundancy checks
>>        so that some classes of tape error can be non-fatal (redundancy data
>>        should allow recovery from simple errors).

>>2.      If a verify error occurs it should be flagged, but the dump should
>>        not be considered fatal (optionally) if the tape is otherwise readable.
>>        This would allow on-line backup (at the system manager's discretion).
>>        One can argue the merits of on-line versus off-line but some sites
>>        have no choice (such as myself!)

>>3.      It appears to offer no protection against the wrong tape being
>>        inserted. Some kind of labelling mechanism, combined with expiry date
>>        protection would be a good move (which is in NETWORKER I'm lead to
>>        believe).

> This really sounds to me like a perfect description of VMS  Backup
> features,  which,  given  the  name of the author of this article,
> doesn't quite surprise me ;-)

  Hmm. subtle hint that Alain!  Actually it wasn't intended to be. I've just
  started looking after a number of unix systems and was just a tad startled
  at how bad the backup mechanisms were. I suppose after many years on VMS
  systems, I'ld assumed it was normal to have reliable backups. After all, if
  a backup can't be trusted you might as well chuck it in and go home.. :-(

Quote:> Yes, one of the very few issues  over  which  Unix  clearly  seems
> inferior to VMS is backup tools. I *don't* want to start a new O/S
> flame  war !!! I was a VMS guy, now I manage a mix of VMS and Unix
> systems  and  I find both environments nice. Each has its areas of
> superiority.

  I'ld argue with `a few issues' but I don't want to start an O/S flame war
  either so I'll keep quiet on that one.

Quote:> Writing a good Unix backup tool, with all the above features  plus
> enough parallelism and multiple buffering to be efficient and keep
> streamers busy, has been high on my "one day, if I have some spare
> time" list. But it's been there for a long time already :-/

  Considering the popularity of unix for commerce nowadays, I'm surprised that
  said businesses aren't clammering for this - Would you trust your hard
  earned cash to a bank that didn't back up its data reliably? twenty years on
  and unix still hasn't exhibited any sign of `design' in some of its more
  crucial areas... Amazing...

Andy Harper
Kings College London

 
 
 

1. ufsdump verification on norewind tapes (was: Re: A Tape Backup

: > I use ufsdump regularly and dump about 10 --> 15 filesystems, consisting
: > of incrementals and fulls, onto *1* 5GIG 8mm tape.  It is basically a foreach
: > loop, but the only key is to use the norewind option (ie. /dev/rmt/0n instead
: > of /dev/rmt/0).  Works like a charm.

: Hello!  I'm using ufsdump this way too.  I'd like to ask if it's possible
: to use the 'v' verify option.  My own answer is that it's not possible for
: the norewind tape device file.  So, my next question is, how can one verify
: a just ufsdump-ed set of tapes?  Will the 't' option of ufsrestore do what
: I'd like to do?  Is this the only way I can do it?  Is there a simpler and
: better way?

: Thanks for all the help.

: Alexander Cerna

: > I know...not much help...just more questions.  :-)
: >
: > Peter Sivo
: > Amdahl/Open Enterprise Systems

The no-rewind and verify options work together for me on QIC and 4mm tapes.
Logically, there is no reason they shouldn't -- dump doesn't need to rewind
before a verify, just backspace to the previous tapemark then space forward
over it. See the options on mt, for instance. ... rb

2. ssh and firewall

3. ufsdump verification on norewind tapes (was: Re: A Tape Backup Question )

4. How the script can distingish xterm from vt100 terminal

5. Matrox Mystique ands X.

6. dvips always generates fonts

7. part 2/2 of: running ufsdump under "script ufsdump.log"

8. WARNING in arch/i386/kernel/init_task.c

9. Solaris 8 ufsdump much slower than Solaris 7 ufsdump

10. Why so many ufsdump processes after I type "ufsdump 0f /dev/null /"?

11. part 1/2 of: running ufsdump under "script ufsdump.log"

12. how to do password verification?

13. Digital Rights Management - An idea (limited lease, renting, expiration, verification) NON HARDWARE BASED.