Re: preserve access time with GNU tar

2000-11-23 Thread John R. Jackson

>> How can I pass this option to GNU tar for the /var/mail disk?
>
>Search for atime-preserve in client-src/sendbackup-gnutar.c

Note that if you change the source as Alexandre is recommending, that
will apply to **all** backups on that client, not just /var/mail.

If you just want to do /var/mail, you may need something like:

  ftp://gandalf.cc.purdue.edu/pub/amanda/gtar-wrapper.*

which is a wrapper you point Amanda at to run instead of GNU tar.
It knows what file system is being processed, so can adjust the parameters
accordingly.

>Alexandre Oliva

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]



GNU tar estimates for vfat filesystems (Was: How do I check level 1 sizes?)

2000-11-23 Thread Chris Karakas

"John R. Jackson" wrote:
> 
> >I want to check the level 1 sizes that AMANDA reports.  ...
> 
> First of all, let's be clear here.  It's not Amanda.  It's your dump
> program that is reporting sizes.  Amanda just uses them.
> 

as I wrote in a previous posting, I wanted to wait a little and observe
what is going on. I think I can tell you a little more about my problem
now: It seems that *all* estimates for *vfat* filesystems are wrong, not
just the ones for /dos/f, /dos/n and /dos/o. The vfat filesystems are
mounted at boot time according to the fstab file, which looks like this:

/dev/hda3   /dos/cvfat  
defaults,uid=500,gid=101,umask=002   0   0
/dev/hda5   /dos/dvfat  
defaults,uid=500,gid=101,umask=002   0   0
/dev/hda6   /dos/evfat  
defaults,uid=500,gid=101,umask=002   0   0

etc.

The uid 500 is the user chris and the gid 101 is the group windows. The
AMANDA user, amanda, belongs to the group windows. When I do ls -l for
the /dos directory, I get

drwxrwxr-x  51 chriswindows 16384 &Igr;&agr;&ngr;  1  1970 c
drwxrwxr-x   8 chriswindows 16384 &Igr;&agr;&ngr;  1  1970 d
drwxrwxr-x   8 chriswindows 16384 &Igr;&agr;&ngr;  1  1970 e

etc.

(&Igr;&agr;&ngr; is Jan in greek). The files inside the directories c, d, e etc.
have their normal datestamps.

My suspicion is that GNU tar, which I use in the version 1.12, somehow
cannot compute incrementals right, for filesystems of vfat type that are
mounted the way I described above...(?)

> The first place I would look is /tmp/amanda/sendsize*debug on the client.
> That will show the command used to generate the estimate and everything
> else that went on.
> 
> I assume you do not have "record no" floating around?
> 

No "record no" in the relevant dumptypes. But also no
/tmp/amanda/sendsize*debug here. There is a /var/lib/amanda/debug
directory, though (correctly, since I specified it as the debug
directory in amanda.conf). I have attached the sendsize.debug file from
a somewhat older AMANDA run.
There is no /var/lib/amanda/gnutar-lists/bacchus_dos_f_1.new, but a
/var/lib/amanda/gnutar-lists/bacchus_dos_f_1. There are lines like

775 6935813 ./original/allied/floppy
775 6953074 ./original/allied/floppy/dosodi
775 6953075 ./original/allied/floppy/ibmlan.os2
775 6953076 ./original/allied/floppy/info


but I cannot see anything suspicious in them. The very first line
contains the epoch, 973836145, meaning Fri Nov 10  7:02:25 2000.

The only thing that catches my attention is the order in which the
estimates are printed. For example, it says

calculating for amname '/dos/f', dirname '/dos/f'

and immediately after:

sendsize: getting size via gnutar for /dos/e level 0
sendsize: running "/usr/lib/amanda/runtar --create --directory /dos/e
--listed-incremental /var/lib/amanda/gnutar-lists/bacchus_dos_e_0.new
--sparse --one-file-system --ignore-failed-read --totals --file
/dev/null ."
Total bytes written: 125317120

On that AMANDA run, in amdump.1, I saw:

got result for host bacchus disk /dos/f: 0 -> 213170K, 1 -> 191710K, -1
-> -1K
got result for host bacchus disk /dos/n: 0 -> 779500K, 1 -> 322920K, 2
-> 322840Kgot result for host bacchus disk /dos/o: 0 -> 170520K, 1 ->
114750K, -1 -> -1K

These 3 filesystems were backed up on level 0 one or two days before and
have not been touched since. 

Now, today, in amdump.2, I see:

got result for host bacchus disk /dos/f: 0 -> 213530K, 1 -> 189890K, 2
-> 189540K

AMANDA wanted to bump on level 2, but even that was almost as large as
the level 1! (I see it also for /dos/n in the example above now...) It
_has_ to do something with vfat, GNU tar and mount, or not?

> Are you using dump or GNU tar?  If dump, is /etc/dumpdates accessible to
> the Amanda user and being updated?  If GNU tar, the same questions apply
> to the listed incremental file (and all the subdirectories down to it).
> 

GNU tar. I suppose the listed incremental files are:

-rw-rw   1 amanda   disk 5072 Nov 11 07:17 bacchus_dos_c_0
-rw-rw   1 amanda   disk 5072 Nov 22 04:22 bacchus_dos_c_1
-rw-rw   1 amanda   disk11291 Nov 14 12:03 bacchus_dos_d_0
-rw-rw   1 amanda   disk11291 Nov 22 04:25 bacchus_dos_d_1

etc.

I see no problem here.


> Does amcheck have anything interesting to say?
> 

No, everything seems to be OK.

I am very grateful for any hint. 


-- 
Regards

Chris Karakas
DonĀ“t waste your cpu time - crack rc5: http://www.distributed.net

sendsize: debug 1 pid 18533 ruid 37 euid 37 start time Fri Nov 10 04:26:26 2000
/usr/lib/amanda/sendsize: version 2.4.1p1
calculating for amname '/', dirname '/'
sendsize: getting size via gnutar for / level 0
calculating for amname '/usr/doc', dirname '/usr/doc'
calculating for amname '/usr/local', dirname '/usr/local'
calculating for amname '/usr/man', dirname '/usr/man'
calculating for amname '/usr/src', dirname '/usr/src'
sendsize: getting size vi

Re: Forcing full dump of one directory, makes level 1 dumps fail (on same host)

2000-11-23 Thread David Lloyd


Edwin!

> Whenever I force a full dump of one directory on host 'A' the level 1
> dumps for the same host will fail.

It could be because AMANDA believes you don't have enough tape space...

> I forced a level 0 dump of /home on Tuesday and now all the other dumps
> for Host A fail... e.g. /etc,/var,/u01,...

Interesting. Have you had a look at the various AMANDA log files (mine
are in /tmp/amanda and /usr/local/adm/NCI/ - yours will be similar
except the latter may be slightly different)?

DL
-- 
Don't you find it rather touching to behold
The OS that came in from the cold
Seen for what it is: religion, plus finesse
Countries, creeds, mean nothing - only Linux...



Forcing full dump of one directory, makes level 1 dumps fail (on same host)

2000-11-23 Thread Edwin Chiu

Hi,

Whenever I force a full dump of one directory on host 'A' the level 1
dumps for the same host will fail.

e.g. Level 0 dumps on Host A were all done sunday, one of them failed.

I forced a level 0 dump of /home on Tuesday and now all the other dumps
for Host A fail... e.g. /etc,/var,/u01,...

Using Amanda 2.4.1p1

Regards,
Edwin


begin:vcard 
n:Chiu;Edwin
tel;fax:(416) 260-9620
tel;work:(416) 260-9625 x247
x-mozilla-html:TRUE
org:E-wares Inc.http://www.e-wares.com/linux/dpinguin.gif">;http://www.e-wares.com">Your Partner in e-Services
version:2.1
email;internet:[EMAIL PROTECTED]
title:VP Future Technology
adr;quoted-printable:;;439 Wellington Street West=0D=0ASuite #301;Toronto;Ontario;M5V 1E7;Canada
fn:Edwin Chiu
end:vcard



Re: preserve access time with GNU tar

2000-11-23 Thread Alexandre Oliva

On Nov 23, 2000, Sven Rudolph <[EMAIL PROTECTED]> wrote:

> I guess that GNU tar's --atime-preserve avoids this. Right?

Yep.

> (But this makes differential backup of these files impossible?)

Right.  Resetting the atime causes the ctime to be modified, and
there's no way to reset the ctime.

> How can I pass this option to GNU tar for the /var/mail disk?

Search for atime-preserve in client-src/sendbackup-gnutar.c

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me



preserve access time with GNU tar

2000-11-23 Thread Sven Rudolph

When I save the mail folders (/var/mail/*) with GNU tar the access
time is set.

This makes xbiff believe that the mail was read, so it changes back to
the "unflagged mailbox" picture.

I guess that GNU tar's --atime-preserve avoids this. Right? (But this
makes differential backup of these files impossible?)

How can I pass this option to GNU tar for the /var/mail disk?

Sven



Re: Problem with Amanda-2.4.1p1

2000-11-23 Thread Johannes Niess

Heiko Muenkel <[EMAIL PROTECTED]> writes:

> Hi,
> 
> since last week I've problems on one of our amanda clients. I got the
> following error message:
> 
> FAILURE AND STRANGE DUMP SUMMARY:
>   hol1   /data/slash/www.hannover.de lev 0 FAILED [badly formatted response from 
>hol1]
> 
> I've found no error message in /tmp/amanda/amanda.debug and
> /tmp/amanda/selfcheck.debug. But in /tmp/amanda/sendsize.debug
> I've found the following:
> 
> sendsize: debug 1 pid 17046 ruid 37 euid 37 start time Tue Nov 21 23:00:03 2000
> /tch/local/amanda/libexec/sendsize: version 2.4.1p1
> REQ packet is bogus: bad spindle

Can we see your disklist? I'd check for white space in the wrong
places in the " hol1 /data/slash/www.hannover.de" line.

> sendsize: pid 17046 finish time Tue Nov 21 23:00:03 2000
> 
> 
> Any ideas?
> 
> 
> 
> Heiko