dump-users

Re: [Dump-users] how to restore multi-volume dump ?

[Stelian P. <st...@po...>]

On Mon, Dec 08, 2003 at 03:31:06PM -0500, Slawomir Orlowski wrote:

> Hello there,
> 
> I have problem with restore, I hope that somebody will help me.
> 
> I have done backup of /dev/hda (/usr partition about 1.3Gb) on three CD-R's.
> DAT=`date +%Y%m%d`
> /sbin/dump 0uBf 600000
> /var/spool/backup/hda2_usr0_$DAT,/var/spool/backup/hda2_usr1_$DAT,/var/spool
> /backup/hda2_usr2_$DAT /dev/hda2
> 
> unfortunately I do not know how to restore files from them.
> 
> It is easy to restore, if needed file is on first CD:
> 
> mount /mnt/cdrom
> restore if /mnt/cdrom/hda2_usr0_2003111009
> 
> but if it is on another CD, how to mount next volume etc etc..
> 
> How to proceed?

Do it in the same way (start with the first file). If the file
is not on the first volume, restore will ask for the next volume,
and you will be given the chance to type in the full pathname
of the second dump file, etc.

Stelian.
-- 
Stelian Pop <st...@po...>

[Dump-users] how to restore multi-volume dump ?

[Slawomir O. <orl...@ho...>]

Hello there,

I have problem with restore, I hope that somebody will help me.

I have done backup of /dev/hda (/usr partition about 1.3Gb) on three CD-R's.
DAT=`date +%Y%m%d`
/sbin/dump 0uBf 600000
/var/spool/backup/hda2_usr0_$DAT,/var/spool/backup/hda2_usr1_$DAT,/var/spool
/backup/hda2_usr2_$DAT /dev/hda2

unfortunately I do not know how to restore files from them.

It is easy to restore, if needed file is on first CD:

mount /mnt/cdrom
restore if /mnt/cdrom/hda2_usr0_2003111009

but if it is on another CD, how to mount next volume etc etc..

How to proceed?
Any help will be appreciated.

Best Regards
Slawomir Orlowski

[Dump-users] Cannot find file dump list

[James R. <ja...@kr...>]

Hi,

    I'm getting the following message when restoring.

$ restore -iv
Verify tape and initialize maps
Input is from a local tape
Tape block size is 32
Dump   date: Fri Dec  5 00:12:05 2003
Dumped from: Tue Oct 28 15:21:11 2003
Level 1 dump of /store on orca:/dev/md0
Label: orca
restore: Cannot find file dump list

The tape was created using a command like this:
ssh orca dump -u -0 /store -f - | dd ibs=512 obs=512 of=/dev/tape conv=sync

DDS4 tape drive
Linux x86 with a heavily upgraded Redhat 6.2 distro
restore 0.4b34 (using libext2fs 1.34 of 25-Jul-2003)
Tape block size 512 bytes. Density code 0x26 (DDS-4 or QIC-4GB).

Is there a way to recover this?
I tried...

	dd bs=512 if=/dev/tape of=temp.bin
	restore -iv -f temp.bin

...but got the same results.
 
James

Re: [Dump-users] Re: Dump deprecation FAQ

[Kenneth P. <sh...@se...>]

--On Sunday, November 30, 2003 10:25 PM +0100 Stelian Pop 
<st...@po...> wrote:

> I imagine it has been funny when they ported Solaris to Intel
> hardware. :)

I had a Sun 386i running SunOS 4. You should have seen all the ifdef's in 
the kernel headers to deal with the fact that not only was the endianness 
different, but bit fields were assigned by the 386 compiler in the opposite 
direction from SPARC. (All the hardware was dealt with as structs of bit 
fields.)

[Dump-users] Re: Dump deprecation FAQ

[Stelian P. <st...@po...>]

On Sun, Nov 30, 2003 at 04:13:28PM +0100, Dragan Krnic wrote:

> >> > Wrt to the filesystem data, ext2/ext3 metadata is in little 
> >> > endian no matter what the host endianess is, so there is 
> >> > nothing to be done.
> >> 
> >> Don't be so pessimistic. There's always a way out.
> >
> > I am not pessimistic. "nothing to be done" means 
> > "no efforts are needed" here.
> 
> I misread you on this one.

:)

> Some other file systems, HP's HFS and Sun's UFS, are very
> similar to ext2. They differ in name and magic mostly and 
> in where the superblock starts. 

Yeah, this must be because all those filesystems must be
derived from the original UNIX one.

However, I'd say there is a big possibility that those filesystem
have evolved in separate directions, implementing uncompatible
extensions...

> I compiled my hfsdump under 
> Solaris and it worked with few changes, but of course it 
> was unusable on HP side and vice versa, because one is
> big-endian and the other is small-endian.

Yup, this is because HP and Sun make both the hardware and the
software.

I imagine it has been funny when they ported Solaris to Intel
hardware. :)

Stelian.
-- 
Stelian Pop <st...@po...>

[Dump-users] Re: Dump deprecation FAQ

[Dragan K. <dk...@ly...>]

>> > Wrt to the filesystem data, ext2/ext3 metadata is in little 
>> > endian no matter what the host endianess is, so there is 
>> > nothing to be done.
>> 
>> Don't be so pessimistic. There's always a way out.
>
> I am not pessimistic. "nothing to be done" means 
> "no efforts are needed" here.

I misread you on this one.

Some other file systems, HP's HFS and Sun's UFS, are very
similar to ext2. They differ in name and magic mostly and 
in where the superblock starts. I compiled my hfsdump under 
Solaris and it worked with few changes, but of course it 
was unusable on HP side and vice versa, because one is
big-endian and the other is small-endian.

Thanks for the replies.

Cheers
Dragan

[Dump-users] Re: Dump deprecation FAQ

[Stelian P. <st...@po...>]

On Sun, Nov 30, 2003 at 11:05:35AM +0100, Dragan Krnic wrote:

> >> in a previous posting you mentioned that dump uses the
> >> host endianness...
> >
> > I don't recall having said that.
> > ...
> > In fact dump writes the data in the platform endianness 
> 
> You just said it again :-)

Sorry I misread you. I thought you implied that I said dump was
in little endian format because most of today's platforms are
and that we don't care about big endian ones.
> 
> > Wrt to the filesystem data, ext2/ext3 metadata is in little 
> > endian no matter what the host endianess is, so there is 
> > nothing to be done.
> 
> Don't be so pessimistic. There's always a way out.

I am not pessimistic. "nothing to be done" means "no efforts are
needed" here.

> What about xfsdump? Of course, one can use xfsrestore to 
> recover xfsdump to an ext2/ext3, but is its format 
> compatible to your dump's format?

I have no idea, in fact I didn't even know that XFS had its own
dump/restore tools :)

Stelian.
-- 
Stelian Pop <st...@po...>

[Dump-users] Re: Dump deprecation FAQ

[Dragan K. <dk...@ly...>]

>> in a previous posting you mentioned that dump uses the
>> host endianness...
>
> I don't recall having said that.
> ...
> In fact dump writes the data in the platform endianness 

You just said it again :-)

> Wrt to the filesystem data, ext2/ext3 metadata is in little 
> endian no matter what the host endianess is, so there is 
> nothing to be done.

Don't be so pessimistic. There's always a way out.
What about xfsdump? Of course, one can use xfsrestore to 
recover xfsdump to an ext2/ext3, but is its format 
compatible to your dump's format?

Cheers
Dragan

[Dump-users] Re: Dump deprecation FAQ

[Stelian P. <st...@po...>]

On Sat, Nov 29, 2003 at 08:55:21PM +0100, Dragan Krnic wrote:

> Hi Stellian,
> 
> in a previous posting you mentioned that dump uses the
> host endianness, meaning mostly it is small-endian,
> because there are few big-endian processors today.

I don't recall having said that.

> I find it a bit awkward and it breaks the compatibility
> between platforms of different endianness.
> 
> Is there a way to bridge the gap?

In fact dump writes the data in the platform endianness and
there is code in restore which tries to detect if the
machine on which the restore is done has a different endianess,
and if this is the case, it does the conversions.

This applies to the dump own metadata (the dump header etc).
Wrt to the filesystem data, ext2/ext3 metadata is in little endian
no matter what the host endianess is, so there is nothing to be done.
This is often the case for filesystems because they are designed
to be read on any machine, big endian or little endian.

Stelian.
-- 
Stelian Pop <st...@po...>

[Dump-users] Re: Dump deprecation FAQ

[Dragan K. <dk...@ly...>]

Hi Stellian,

in a previous posting you mentioned that dump uses the
host endianness, meaning mostly it is small-endian,
because there are few big-endian processors today.
I find it a bit awkward and it breaks the compatibility
between platforms of different endianness.

Is there a way to bridge the gap?

I tried reading Linux dump on an HP system. It didn't work.
I tried HP dump and vxdump on a Linux. It didn't work either.

Of course, your dump/restore sources can at least be built on 
the target platform, but I guess one would still have to fix 
a lot of binary reads to reverse the endianness on a big-endian
system.

Was it ever a problem? Is there a provision for dealing
with endianness in dump?

Cheers
Dragan

PS: It's not an accademic issue that bothers me. I'm about 
to release a reiserfsdump/restore and I used ntohX family
of routines to keep the big-endianness even though I did
it on an Intel Linux. It was much easier to debug when
bytes are ordered most-significant-first.(left to right).
Now I would like to make it compatible with your dump and
am scratching my head how to do it. Any idea?

Re: [Dump-users] Solved: Problems spanning tapes with dump (summary)

[Tom H. <tr...@ti...>]

Mike Castle wrote:

>On Fri, Nov 21, 2003 at 10:29:33AM -0800, Tom Haws wrote:
>  
>
>>detected by dump, it calls the script, which does an rsh back to the 
>>host with the tapedrive, rewinds the tape there (causing our autochanger 
>>in sequential mode to load the next tape), sleeps a couple of minutes, 
>>then exits with a return code of zero.  This allows dump to resume, 
>>without trying to contact anyone, and all is fine.
>>    
>>
>
>
>A 'sleep 2 minutes' approach always scares me.  No matter how long you make
>the delay, sometime there is going to be a case where it's not long enough
>and things will crash.
>
>Would a better solution be to make use of mt status on the drive
>periodically and when it's done changing the tape, exit?   By making the
>call to mt status something like every 10 seconds, you might actually
>return in less than 2 minutes in most cases, and increase throughput!  :->
>
>Obviously you'd want to put limits on how many times you run mt status so
>you can detect that things went really bad.
>
>mrc
>
Yeah, I know what you mean with a sleep.  One day, it just won't be 
enough.  One good thing is that the "mt -t rewoffl" does not return 
until the tape is rewound and the next one is loaded (the autochanger 
hardware must not release the command until it obeys the sequential mode 
programming in it?), and my sleep comes after that, so it's kind of like 
insurance.

I like your idea of doing some checking, and I might incorporate that in 
the future, but for now, I'm just so relieved to get a backup that I 
don't want to touch it!

-Tom

-- 
_______________________________________________________________________
Tom Haws               Manager, Systems Administration
tr...@ti...      Timberline Forest Inventory Consultants
Tel: (250) 562-2628    1579 9th Ave, Prince George, B.C. Canada V2L 3R8
Fax: (250) 562-6942    http://www.timberline.ca
_______________________________________________________________________

Re: [Dump-users] Solved: Problems spanning tapes with dump (summary)

[Mike C. <da...@ix...>]

On Fri, Nov 21, 2003 at 10:29:33AM -0800, Tom Haws wrote:
> detected by dump, it calls the script, which does an rsh back to the 
> host with the tapedrive, rewinds the tape there (causing our autochanger 
> in sequential mode to load the next tape), sleeps a couple of minutes, 
> then exits with a return code of zero.  This allows dump to resume, 
> without trying to contact anyone, and all is fine.


A 'sleep 2 minutes' approach always scares me.  No matter how long you make
the delay, sometime there is going to be a case where it's not long enough
and things will crash.

Would a better solution be to make use of mt status on the drive
periodically and when it's done changing the tape, exit?   By making the
call to mt status something like every 10 seconds, you might actually
return in less than 2 minutes in most cases, and increase throughput!  :->

Obviously you'd want to put limits on how many times you run mt status so
you can detect that things went really bad.

mrc
-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

[Dump-users] Solved: Problems spanning tapes with dump (summary)

[Tom H. <tr...@ti...>]

Thanks to everyone who responded to my problem with dump not spanning 
tapes.  I have found a solution, and it basically involves using the -F 
<script> parameter when dump is invoked.  When the End Of  Tape is 
detected by dump, it calls the script, which does an rsh back to the 
host with the tapedrive, rewinds the tape there (causing our autochanger 
in sequential mode to load the next tape), sleeps a couple of minutes, 
then exits with a return code of zero.  This allows dump to resume, 
without trying to contact anyone, and all is fine.

Here is a more detailed summary:

Problem:

- DLT autochanger on a Solaris host
- the Solaris host with the autochanger backs up all remote hosts in a 
cron script, by doing an rsh to the remote host and then using ufsdump 
there to back up that host's filesystems
- Solaris hosts spanned tapes fine, by using the "-l" switch to ufsdump. 
 The tape would just rewind, the autochanger would load the next tape, 
and ufsdump would resume.
- Linux dump was dying when it hit the End Of Tape:

DUMP: End of tape detected
 DUMP: Closing /dev/rmt/0hn
 DUMP: Volume 1 completed at: Sat Nov 15 00:11:02 2003
 DUMP: Volume 1 5814360 blocks (5678.09MB)
 DUMP: Volume 1 took 0:34:39
 DUMP: Volume 1 transfer rate: 2796 kB/s
 DUMP: Change Volumes: Mount volume #2
 DUMP: fopen on /dev/tty fails: No such device or address
 DUMP: The ENTIRE dump is aborted.

Solution:

- For the Linux machine, invoke dump with the -F option, like this (this 
is run from the Solaris machine, hence the rsh):

---------------------------------------------snip--------------------------------------
linux_backup()
{
# Version 1.1: added this function
#set -x
# Begin the backup

# Version 1.2: Not sure if this is needed, but the man page says it may be:
export RMT="/usr/sbin/rmt"

for OBJECT in $OBJECTS
do
        echo "TFIC: ------------------------------------------" >> 
$logfile 2>&1
        echo "TFIC: Level ${backup_level} backup of $OBJECT, to 
${TAPEHOST}:${TAPEDRIVE}"
                 >> $logfile 2>&1

        # Now actually to the dump.
        # Version 1.2: Linux dump died trying to change to the next tape
        # so the -F <script> parameter was added on 18 Nov/03
        # The script rewinds the tape device on TAPEHOST, then sleep 
120, then exit 0.
        rsh -n $OBJECTHOST /usr/sbin/dump \
                -a -F /opt/adm/scripts/fix_linux_tape_change \
                -${backup_level} -u -f ${TAPEHOST}:${TAPEDRIVE} \
                $OBJECT                 >> $logfile 2>&1

        # Check for sucessful completion
        # Don't bail though, since the next one might work
        if [[ $? != 0 ]]
        then
                echo "TFIC: ERROR! Problem with backup of $OBJECT, to 
${TAPEHOST}:$TAPEDRIVE, at " `date`
    >> $logfile 2>&1
                export PROBLEM="true"
        fi
done

}
---------------------------------------------snip--------------------------------------

- The /opt/adm/scripts/fix_linux_tape_change lives on the linux host, 
and is called when dump recognizes EOT:

---------------------------------------------snip--------------------------------------

#!/bin/bash
#-----------------------------------------------------------------------------
# Script:       /opt/adm/scripts/fix_linux_tape_change
# Date:         18 November, 2003
# By:           Tom Haws
#
# Version:      1.0
#
# This script is called by the dump command in the nightly backups, via the
# -F parameter. It is called when dump detects EOT.
# It is an attempt to fix dump from aborting when it wants to ask for           
# the next tape.
#
# The error was: DUMP: fopen on /dev/tty fails: No such device or address
#
# This script rewinds and takes the tape offline on TAPEHOST, which             
# causes the autochanger to load the next tape.  It then waits a period         
# of time, then exits with a 0 exit code.  According to the man page,           
# the 0 return code will cause dump to not ask the operator for a tape...
#
# /opt/adm/scripts/TAPEHOST is a file containing the hostname of the            
# host that has the tapedrive, and is created as a part of the calling
# backup script.
#-----------------------------------------------------------------------------

export WAIT="120"

export TAPEHOST=`cat /opt/adm/scripts/TAPEHOST`
rsh ${TAPEHOST} mt -t /dev/rmt/0 rewoffl
sleep ${WAIT}
exit 0


---------------------------------------------snip--------------------------------------

Thanks again to everyone who helped.
-Tom

-- 
_______________________________________________________________________
Tom Haws               Manager, Systems Administration
tr...@ti...      Timberline Forest Inventory Consultants
Tel: (250) 562-2628    1579 9th Ave, Prince George, B.C. Canada V2L 3R8
Fax: (250) 562-6942    http://www.timberline.ca
_______________________________________________________________________

Re: [Dump-users] Problems spanning tapes with dump

[Tom H. <tr...@ti...>]

>
>
>>Linux machine, like this:
>>
>>      rsh -n $OBJECTHOST /usr/sbin/dump \
>>              -${backup_level} -u -f ${TAPEHOST}:${TAPEDRIVE} \
>>              $OBJECT                 >> $logfile 2>&1
>>    
>>
>
>Why -n ? Without -n I think it will work.
>
>Stelian.
>  
>
Ohmigawd, maybe you're right.  I've just always used the -n when talking 
to my Solaris hosts, and that got copied over to my linux_backup() 
function in my script.  Here's the -n switch from the Solaris rsh man page:

-n        Redirect the input of rsh  to /dev/null. You some-
               times   need  this  option  to  avoid  unfortunate
               interactions between  rsh   and  the  shell  which
               invokes  it.   For example, if you are running rsh
               and  invoke  a  rsh   in  the  background  without
               redirecting  its  input away from the terminal, it
               will block even if no  reads  are  posted  by  the
               remote command.  The -n option will prevent this.

At any rate, I have now solved the problem by using the -F <script> 
parameter to dump, so I'll post that seperately.  

-Thanks for your help,
-Tom


-- 
_______________________________________________________________________
Tom Haws               Manager, Systems Administration
tr...@ti...      Timberline Forest Inventory Consultants
Tel: (250) 562-2628    1579 9th Ave, Prince George, B.C. Canada V2L 3R8
Fax: (250) 562-6942    http://www.timberline.ca
_______________________________________________________________________

Re: [Dump-users] Problems spanning tapes with dump

[Stelian P. <st...@po...>]

On Thu, Nov 20, 2003 at 02:39:25PM -0800, Tom Haws wrote:

> Maybe I'll just try an "rsh ${TAPEHOST} mt -t /dev/rmt/0 rewoffl" before 
> the sleep in my fix_linux_tape_change script, and see if that fixes it. 

In fact you should launch the 'mt revoffl' *from* the fix_linux_tape_change
script.

Stelian.
-- 
Stelian Pop <st...@po...>

Re: [Dump-users] Problems spanning tapes with dump

[Stelian P. <st...@po...>]

On Thu, Nov 20, 2003 at 09:31:35AM -0800, Tom Haws wrote:

> Linux machine, like this:
> 
>       rsh -n $OBJECTHOST /usr/sbin/dump \
>               -${backup_level} -u -f ${TAPEHOST}:${TAPEDRIVE} \
>               $OBJECT                 >> $logfile 2>&1

Why -n ? Without -n I think it will work.

Stelian.
-- 
Stelian Pop <st...@po...>

Re: [Dump-users] Problems spanning tapes with dump

[David G. <dj...@dr...>]

> Maybe I'll just try an "rsh ${TAPEHOST} mt -t /dev/rmt/0 rewoffl" before 
> the sleep in my fix_linux_tape_change script, and see if that fixes it. 
>
On my DDS autoloader I need to do a mt eject.

David Gesswein
http://www.pdp8.net/  -- Run an old computer with blinkenlights.
                         Have any PDP-8 stuff you're willing to part with?

Re: [Dump-users] Problems spanning tapes with dump

[Tom H. <tr...@ti...>]

Thanks for your reply, Eric.

Eric Jensen wrote:

>Hi,
>   Dump is indeed expecting to have a tty to talk to.  A couple of
>things you might try, neither of which I've attempted:
>
>1.  Run "expect", and use it to talk to dump.  I've never used it, but
>    my understanding is that it's made for exactly this sort of thing.=20
>
>2.  Try using this facility, described in the dump man page:
>
>     -F script
>         Run script at the end of each tape. The device name and the cur=
=81=AD
>         rent volume number are passed on the command line.  The script
>         must return 0 if dump should continue without asking the user t=
o
>         change the tape, 1 if dump should continue but ask the user
>         to change the tape.  Any other exit code will cause dump to
>         abort.  For security reasons, dump reverts back to the real use=
r
>         ID and the real group ID before running the script.
>
>Seems like you could have a simple script that would just wait however
>long it will take your changer to change the tape (plus some safety
>margin), and then return 0, so that dump would continue.  So this could
>just be
>
>#!/bin/sh
>
>sleep 5m
>exit 0
>
>and you should be set.  You probably don't even need the exit line,
>since sleep ought to return zero if it executes successfully (I think).
>
>
>I've never tried this, but it looks like what you need.  Let us know if
>it works.
>
>Thanks,
>
>Eric
>
Yes, I tried exactly that already. Great minds thinking alike and all=20
that, hey? Mine slept for 2 minues, then did an exit 0.

This had mixed results. Dump was satisfied, and did not complain about=20
needing to talk to a device, but unfortunately, the tape did not rewind=20
either. It just stayed at the the EOT mark, so when dump started up=20
again, there was no tape to write to. Here's the output:

DUMP: End of tape detected
DUMP: Closing /dev/rmt/0hn
DUMP: Volume 1 completed at: Wed Nov 19 10:02:51 2003
DUMP: Volume 1 12319800 blocks (12031.05MB)
DUMP: Volume 1 took 1:10:02
DUMP: Volume 1 transfer rate: 2931 kB/s
DUMP: Launching /opt/adm/scripts/fix_linux_tape_change
DUMP: Volume 2 started with block 12319771 at: Wed Nov 19 10:04:51 2003
DUMP: Volume 2 begins with blocks from inode 1799313
DUMP: EOT detected at start of the tape!
DUMP: The ENTIRE dump is aborted.

What should happen is that when the tape drive recognizes an EOT, it=20
rewinds the tape and loads the next one (it is in sequential mode, not=20
random mode). The Solaris man page shows this for the ufsdump "-l" option=
:

l Autoload. When the end-of-tape is reached before
the dump is complete, take the drive offline and
wait up to two minutes for the tape drive to be
ready again. This gives autoloading (stackloader)
tape drives a chance to load a new tape. If the
drive is ready within two minutes, continue. If it
is not, prompt for another tape and wait.

Maybe I'll just try an "rsh ${TAPEHOST} mt -t /dev/rmt/0 rewoffl" before=20
the sleep in my fix_linux_tape_change script, and see if that fixes it.=20
(Actually, I just tried that manually, since the tape was at the end=20
from last night's aborted attempt anyway, and the autochanger loaded the=20
next tape, so here's hoping....)

I'll post the results tomorrow.

-Tom

--=20
_______________________________________________________________________
Tom Haws               Manager, Systems Administration
tr...@ti...      Timberline Forest Inventory Consultants
Tel: (250) 562-2628    1579 9th Ave, Prince George, B.C. Canada V2L 3R8
Fax: (250) 562-6942    http://www.timberline.ca
_______________________________________________________________________

Re: [Dump-users] Problems spanning tapes with dump

[Eric J. <eje...@sw...>]

Hi,
   Dump is indeed expecting to have a tty to talk to.  A couple of
things you might try, neither of which I've attempted:

1.  Run "expect", and use it to talk to dump.  I've never used it, but
    my understanding is that it's made for exactly this sort of thing. 

2.  Try using this facility, described in the dump man page:

     -F script
         Run script at the end of each tape. The device name and the cur­
         rent volume number are passed on the command line.  The script
         must return 0 if dump should continue without asking the user to
         change the tape, 1 if dump should continue but ask the user
         to change the tape.  Any other exit code will cause dump to
         abort.  For security reasons, dump reverts back to the real user
         ID and the real group ID before running the script.

Seems like you could have a simple script that would just wait however
long it will take your changer to change the tape (plus some safety
margin), and then return 0, so that dump would continue.  So this could
just be

#!/bin/sh

sleep 5m
exit 0

and you should be set.  You probably don't even need the exit line,
since sleep ought to return zero if it executes successfully (I think).


I've never tried this, but it looks like what you need.  Let us know if
it works.

Thanks,

Eric

[Dump-users] Problems spanning tapes with dump

[Tom H. <tr...@ti...>]

Hi,

We have used a Sun DLT autoloader for years on our Solaris machines, 
using ufsdump to back up all the machines at our site.  We have now 
switched to a RedHat Linux 9 machine as our main fileserver, and I am 
having problems getting it to span tapes when I use dump for the backup. 
This is getting very critical, since I haven't had a good backup since 
the new system was installed a week ago.

Here's the setup:

-Sun Solaris machine with DLT autoloader
-the Sun machine runs a script in cron that starts a dump command on the 
Linux machine, like this:

       rsh -n $OBJECTHOST /usr/sbin/dump \
               -${backup_level} -u -f ${TAPEHOST}:${TAPEDRIVE} \
               $OBJECT                 >> $logfile 2>&1

Everything works fine, but when the Linux machine hits the end of tape, 
it gets this:

 DUMP: End of tape detected
 DUMP: Closing /dev/rmt/0hn
 DUMP: Volume 1 completed at: Sat Nov 15 00:11:02 2003
 DUMP: Volume 1 5814360 blocks (5678.09MB)
 DUMP: Volume 1 took 0:34:39
 DUMP: Volume 1 transfer rate: 2796 kB/s
 DUMP: Change Volumes: Mount volume #2
 DUMP: fopen on /dev/tty fails: No such device or address
 DUMP: The ENTIRE dump is aborted.

It's like dump has to send something to the operator, and can't.  In 
Solaris ufsdump, the "-l" switch takes care of that, and all ufsdump 
does is wait for the autochanger to load the next tape (the autochanger 
is in sequential mode), and continues on.

I downloaded the latest dump from http://dump.sourceforge.net, and I am 
using dump-0.4b34-1.

Am I missing something here?  Can you get dump to span tapes from a 
script?  HELP!  This is really getting critical...

-TIA
-Tom

-- 
_______________________________________________________________________
Tom Haws               Manager, Systems Administration
tr...@ti...      Timberline Forest Inventory Consultants
Tel: (250) 562-2628    1579 9th Ave, Prince George, B.C. Canada V2L 3R8
Fax: (250) 562-6942    http://www.timberline.ca
_______________________________________________________________________

Re: [Dump-users] dump and xfsdump

[Stelian P. <st...@po...>]

On Tue, Oct 21, 2003 at 03:01:08PM -0400, Kevin wrote:

> Anyone know if it is possible to use dump and
> xfsdump on the same tape without issues?

I don't see why it wouldn't be. Just use the same block size
(-b option in both usfdump and dump).

Stelian.
-- 
Stelian Pop <st...@po...>

[Dump-users] dump and xfsdump

[Kevin <ke...@mp...>]

Anyone know if it is possible to use dump and
xfsdump on the same tape without issues?

Thanks,
/KRM

keyserver: http://pgp.mit.edu/

Re: [Dump-users] Help needed to change a Solaris dump script to RedHat Linux

[Stelian P. <st...@po...>]

On Fri, Oct 17, 2003 at 01:46:36PM -0400, dfp10 wrote:

> Hello!
> I have been using the following script on Solaris for many years> I would like 
> to use a ported list on RHlinux9 but I am having trouble in finding equivalent 
> Linux commands. (Feel free to use it on Solaris!).

Let's see...

> 
> #!/bin/sh
> # @(#) backup-script 1.2 95/09/15
> #
> # simple dump script /usr/bin/ufsscript  to do full dump of an entire system
> #
> # edit the following to suit your configuration
> #
> TAPE=/dev/rmt/0mbn   # this should be the non-rewinding tape device

use /dev/nst0 under Linux.

> 
> # use this for 2.3 GB 8mm drives
> #DUMPPARM="0ubdsf 126 54000 6000"
> 
> # use this for 5GB (4mm & 8mm) drives
> # DUMPPARM="0ubdsf 126 54000 13000"
> # same but COMPRESSED
> DUMPPARM="0ubdsf 126 54000 26000"
> # DUMPPARM="0ubdsf 126 50800 740"
> # DUMPPARM="0cfu"
> # run from a shell tool or a cron. By default it backs up the entire 
> # system. For incremental backups replace the DUMPPARM line with
> # DUMPPARM="xubdsf 126 nnnnnn nnnnn" 

Those are usable as is, although you may want to replace
the -d/-s combination with a simple -b.

> # the x in place of 0 means incremental dump, or only the stuff
> # thats changed since the last since the last incremental dump was
> # done. Take a full (level 0)and save it in case of hd cashes. 
> # Periodically run an incremental or a full dump (depending on the 
> # amount of data change on the machine
> # to dump specific filesystems, set FILESYS to a list of
> # the devices you want to dump. If FILESYS is null, all
> # ufs filesystems listed in /etc/vfstab will be dumped.
>  FILESYS=""
> 
> # to print useful recovery information (disk layout, dump list)
> # set PRINTER to the name of the printer you wish to spool
> # the output to. If PRINTER is null, no output will be produced
> PRINTER=parsons
> 
> #-----  shouldn't have to modify anything below here -----
> getfs() {
>   if [ -z "$FILESYS" ]; then
>     FILESYS=`awk '$1 !~ /^#/ && $4 == "ufs" {print $2}' </etc/vfstab`
>   fi
> }

Use ext2 ou ext3 as search item into /etc/fstab

> 
> getrootdisk() {
>   ROOTDISK=`awk '$1 !~ /^#/ && $3 == "/" {print $2}' </etc/vfstab |
>   sed -e 's/$s./s2/'`
> }

s/vfstab/fstab/

> 
> # start of actual process
> PATH=/usr/bin:/usr/sbin:/sbin; export PATH
> echo "Dump started at `date`"
> mt -f $TAPE rewind
> getfs
> for i in $FILESYS
> do
>   echo "Starting $i at `date`"
>   ufsdump $DUMPPARM $TAPE $i >/dev/null

s/ufsdump/dump/

>   echo ufsdump $DUMPPARM $TAPE $i
>   echo "Finished $i at `date`"
> done
> 
> # if [ -n "$PRINTER" ];
> # then
> #  (
>   echo "Dump done on `date`" 
>   echo ""
>   echo "Tape contains the following partitions, in sequence"
>   for i in $FILESYS
>   do
>     echo $i
>   done
>   echo ""
>   getrootdisk
>   prtvtoc $ROOTDISK
> #   ) | lp -d$PRINTER
> # unexpected end of file at last line
>  fi
> # report errors to screen
> iostat -En
> ********************************

Damn, didn't see you already started the job :)

> STARTING to port to Linux:
> #!/bin/sh
> # @(#) backup-script 
> # /sbin/ext3script.tot Modified for RedHat9
> # simple dump script /usr/bin/ufsscript  to do full dump of an entire system
> # edit the following to suit your configuration
> 
> TAPE=/dev/nst0   # this should be the non-rewinding tape device
> # use this for 2.3 GB 8mm drives
> #DUMPPARM="0ubdsf 126 54000 6000"
> # use this for 5GB (4mm & 8mm) drives
> # DUMPPARM="0ubdsf 126 54000 13000"
> # same but COMPRESSED
> #DUMPPARM="0ubdsf 126 54000 26000"
> # DUMPPARM="0ubdsf 126 50800 740"
> # DUMPPARM="0cfu"
> ***I have not yet found good equivalents in the following:
> 
> DUMPPARM="0b 64" #u=update dump dates cannot be used ,b<=64kb 

Yes -u can be used

and b can be > 64kb in more recent versions of dump.

> 
> # to dump specific filesystems, set FILESYS to a list of
> # the devices you want to dump. If FILESYS is null, all
> # ext3 ufs filesystems listed in /etc/fstab /etc/vfstab will be dumped.
> 
>  FILESYS=""    #/,/data,/home,/opt,/spare,/usr,/usr/local,/var"
> *** I cannot get a read of ext3 in fstab or a comma seperated list of file 
> systems

Hmm, why ?

> 
> # to print useful recovery information (disk layout, dump list)
> #dfp10 set PRINTER to the name of the printer you wish to spool
> # the output to. If PRINTER is null, no output will be produced
> PRINTER=parsons
> #-----  shouldn't have to modify anything below here -----
> getfs() {
>   if [ -z "$FILESYS" ]; then
>     FILESYS=`awk '$1 !~ /^#/ && $4 == "ext3" {print $2}' </etc/fstab`
>   fi
> }
> getrootdisk() {
>   ROOTDISK=`awk '$1 !~ /^#/ && $3 == "/" {print $2}' </etc/fstab |
>   /bin/sed -e 's/$s./s2/'`
> }
> 
> # start of actual process
> PATH=/usr/bin:/usr/sbin:/sbin; export PATH
> echo "Dump started at `/bin/date`"
> /bin/mt -f $TAPE rewind
> 
> getfs
> 
> for i in $FILESYS
> do
>   echo "Starting $i at `/bin/date`"
>   /sbin/dump -$DUMPPARM -f $TAPE $i >/dev/null
>   echo dump $DUMPPARM $TAPE $i
>   echo "Finished $i at `/bin/date`"
> done
> 
> # if [ -n "$PRINTER" ];
> # then
> #  (
>   echo "Dump done on `/bin/date`" 
>   echo ""
>   echo "Tape contains the following partitions, in sequence"
>   for i in $FILESYS
>   do
>     echo $i
>   done
>   echo ""
>   getrootdisk
> *** the prtvtoc found in linux vxtools does not work in the same way as the 
> Solaris prtvtoc
> 
>  /usr/bin/prtvtoc $ROOTDISK # prtvtoc is ? a linux equivalent

I dont know what prvtoc is supposed to do.

> #   ) | lp -d$PRINTER
> # unexpected end of file at last line
>  fi
> # report errors to screen
> iostat -En
> ********************************************
> I will appreciate your suggestions and will post any final working script.
> Thanks

Please break the script in small functions and post only the part that
doesn't work  in the future.

Stelian.
-- 
Stelian Pop <st...@po...>

[Dump-users] Help needed to change a Solaris dump script to RedHat Linux

[dfp10 <df...@wa...>]

Hello!
I have been using the following script on Solaris for many years> I would like 
to use a ported list on RHlinux9 but I am having trouble in finding equivalent 
Linux commands. (Feel free to use it on Solaris!).

#!/bin/sh
# @(#) backup-script 1.2 95/09/15
#
# simple dump script /usr/bin/ufsscript  to do full dump of an entire system
#
# edit the following to suit your configuration
#
TAPE=/dev/rmt/0mbn   # this should be the non-rewinding tape device

# use this for 2.3 GB 8mm drives
#DUMPPARM="0ubdsf 126 54000 6000"

# use this for 5GB (4mm & 8mm) drives
# DUMPPARM="0ubdsf 126 54000 13000"
# same but COMPRESSED
DUMPPARM="0ubdsf 126 54000 26000"
# DUMPPARM="0ubdsf 126 50800 740"
# DUMPPARM="0cfu"
# run from a shell tool or a cron. By default it backs up the entire 
# system. For incremental backups replace the DUMPPARM line with
# DUMPPARM="xubdsf 126 nnnnnn nnnnn" 
# the x in place of 0 means incremental dump, or only the stuff
# thats changed since the last since the last incremental dump was
# done. Take a full (level 0)and save it in case of hd cashes. 
# Periodically run an incremental or a full dump (depending on the 
# amount of data change on the machine
# to dump specific filesystems, set FILESYS to a list of
# the devices you want to dump. If FILESYS is null, all
# ufs filesystems listed in /etc/vfstab will be dumped.
 FILESYS=""

# to print useful recovery information (disk layout, dump list)
# set PRINTER to the name of the printer you wish to spool
# the output to. If PRINTER is null, no output will be produced
PRINTER=parsons

#-----  shouldn't have to modify anything below here -----
getfs() {
  if [ -z "$FILESYS" ]; then
    FILESYS=`awk '$1 !~ /^#/ && $4 == "ufs" {print $2}' </etc/vfstab`
  fi
}

getrootdisk() {
  ROOTDISK=`awk '$1 !~ /^#/ && $3 == "/" {print $2}' </etc/vfstab |
  sed -e 's/$s./s2/'`
}

# start of actual process
PATH=/usr/bin:/usr/sbin:/sbin; export PATH
echo "Dump started at `date`"
mt -f $TAPE rewind
getfs
for i in $FILESYS
do
  echo "Starting $i at `date`"
  ufsdump $DUMPPARM $TAPE $i >/dev/null
  echo ufsdump $DUMPPARM $TAPE $i
  echo "Finished $i at `date`"
done

# if [ -n "$PRINTER" ];
# then
#  (
  echo "Dump done on `date`" 
  echo ""
  echo "Tape contains the following partitions, in sequence"
  for i in $FILESYS
  do
    echo $i
  done
  echo ""
  getrootdisk
  prtvtoc $ROOTDISK
#   ) | lp -d$PRINTER
# unexpected end of file at last line
 fi
# report errors to screen
iostat -En
********************************
STARTING to port to Linux:
#!/bin/sh
# @(#) backup-script 
# /sbin/ext3script.tot Modified for RedHat9
# simple dump script /usr/bin/ufsscript  to do full dump of an entire system
# edit the following to suit your configuration

TAPE=/dev/nst0   # this should be the non-rewinding tape device
# use this for 2.3 GB 8mm drives
#DUMPPARM="0ubdsf 126 54000 6000"
# use this for 5GB (4mm & 8mm) drives
# DUMPPARM="0ubdsf 126 54000 13000"
# same but COMPRESSED
#DUMPPARM="0ubdsf 126 54000 26000"
# DUMPPARM="0ubdsf 126 50800 740"
# DUMPPARM="0cfu"
***I have not yet found good equivalents in the following:

DUMPPARM="0b 64" #u=update dump dates cannot be used ,b<=64kb 

# to dump specific filesystems, set FILESYS to a list of
# the devices you want to dump. If FILESYS is null, all
# ext3 ufs filesystems listed in /etc/fstab /etc/vfstab will be dumped.

 FILESYS=""    #/,/data,/home,/opt,/spare,/usr,/usr/local,/var"
*** I cannot get a read of ext3 in fstab or a comma seperated list of file 
systems

# to print useful recovery information (disk layout, dump list)
#dfp10 set PRINTER to the name of the printer you wish to spool
# the output to. If PRINTER is null, no output will be produced
PRINTER=parsons
#-----  shouldn't have to modify anything below here -----
getfs() {
  if [ -z "$FILESYS" ]; then
    FILESYS=`awk '$1 !~ /^#/ && $4 == "ext3" {print $2}' </etc/fstab`
  fi
}
getrootdisk() {
  ROOTDISK=`awk '$1 !~ /^#/ && $3 == "/" {print $2}' </etc/fstab |
  /bin/sed -e 's/$s./s2/'`
}

# start of actual process
PATH=/usr/bin:/usr/sbin:/sbin; export PATH
echo "Dump started at `/bin/date`"
/bin/mt -f $TAPE rewind

getfs

for i in $FILESYS
do
  echo "Starting $i at `/bin/date`"
  /sbin/dump -$DUMPPARM -f $TAPE $i >/dev/null
  echo dump $DUMPPARM $TAPE $i
  echo "Finished $i at `/bin/date`"
done

# if [ -n "$PRINTER" ];
# then
#  (
  echo "Dump done on `/bin/date`" 
  echo ""
  echo "Tape contains the following partitions, in sequence"
  for i in $FILESYS
  do
    echo $i
  done
  echo ""
  getrootdisk
*** the prtvtoc found in linux vxtools does not work in the same way as the 
Solaris prtvtoc

 /usr/bin/prtvtoc $ROOTDISK # prtvtoc is ? a linux equivalent
#   ) | lp -d$PRINTER
# unexpected end of file at last line
 fi
# report errors to screen
iostat -En
********************************************
I will appreciate your suggestions and will post any final working script.
Thanks
Don
************************************
Donald F. Parsons MB.BS, Ph.D
Res.Physician, Wadsworth B745, NYS Dept.Health
Prof.Biometry & Statistics, Un.Albany
df...@te...

Re: [Dump-users] Dump deprecation FAQ

[Stelian P. <st...@po...>]

On Wed, Oct 01, 2003 at 10:30:38PM +0300, Antonios Christofides wrote:

> OK, the permissions are fine. I put the FAQ here:
>     http://dump.sourceforge.net/isdumpdeprecated.html
> and I added a link at dump's home page (http://dump.sourceforge.net/).

Great! Thanks.

Stelian.
-- 
Stelian Pop <st...@po...>