----- Original Message -----
From: David Fitch <[EMAIL PROTECTED]>
To: Les Stott <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, January 07, 2002 10:52 PM
Subject: Re: [SLUG] Troubles with Tar and backups


> just some ideas for you...
>
> On Mon, Jan 07, 2002 at 12:44:50PM +1100, Les Stott wrote:
> > The variable TAPEDEV is /dev/tape. The variable ERRFILE is
> > /var/log/backup/backup-err.log.3.
>
> so aren't you attempting to backup a changing file? (ie. your
> error log at least and possibly others under /var/log)
> does that work?

Yes i am aware of changing files but thats what the "ignore-failed-read"
switch is for. If tar comes across a file it cannot read then it usually
exits with an error code of 2. However if you tell tar to ignore failed
reads it skips over files that it cant read and continues on.
>
> > If i watch it run manually it works no problems. However i try to read
the
> > tape back or restore i get "unexpected end of file", "tar exitting from
> > unrecoverable errors".
> > On closer investigation i find the following error:
> >
> > /root/scripts/FullBackup.les: line 42: 31663 Broken pipe
>
> so is the line 42? :

Yes the line is 42.

>
> >             tar -cvf $TAPEDEV --exclude "./proc/*" --exclude
> > "./var/spool/squid/*" --exclude
> > "./tmp/*" --ignore-failed-read --totals --verify . 2>>$ERRFILE
>
> presumably that's all on one line in your script?
> (what's the ".les" extension mean?)

Yes that is all one line and it is line 42. The .les extension means nothing
it is just the name of the script file. The original script was just called
FullBackup. When i made some changes i simply saved into a new file i.e
Fullbackup.les.

>
> You sure you're excluding what you think you're excluding
> (the tar info page makes it sound fairly complicated)?

Yes i believe so. I have tested the exclusions and the directories that i am
excluding are being excluded.

>
> have a read of the "read-full-records" (or blocking factor) option
> and see if that applies to you as well.

-B, --read-full-blocks - reblock as we read (for reading 4.2BSD pipes). I
don't think this applies as i am not using BSD and as far as i am aware tar
on redhat does not need this. I could be wrong though.

>
> Don't know what 141 means either sorry.

I have a feeling that it is not an erro code from one error, possibly a
combination of two error codes.

It is very difficult to find anything on the net in regards to error codes.
I did however come across a similar issue that said that one of the
processes in the command could be receiving a term signal of 13 (128 + 13 =
141) SIGPIPE. Apparrently this could happen if the process after the pipe
closes its STDIN before the original process is finished.
I am not sure whether it is absolutely correct but it may have something to
do with it.

> Dave.
>

Thanks for your reply. If you have any other help for me i would appreciate
it.

Regards,

Les Stott
Systems Administrator
Rentokil Initial
[EMAIL PROTECTED]
(02) 9370 9348


This email is confidential. If you are not the intended recipient, you must
not disclose
or use the information contained in it. If you have received this in error,
please
advise the sender by return email and delete the material from your
computer.

Rentokil Initial Pty Ltd ABN 98 000 034 597 does not warrant that any
attachments are free from viruses or any other defects. You assume all
liability for any loss, damage or other consequences which may arise from
opening or using the attachments.


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Reply via email to