Amanda-Users

Re: GNU tar versions (was: Backups failing on Solaris 9 with GNU tar)

2005-01-17 04:58:37
Subject: Re: GNU tar versions (was: Backups failing on Solaris 9 with GNU tar)
From: Gene Heskett <gene.heskett AT verizon DOT net>
To: Kurt Raschke <kurt AT raschke DOT net>
Date: Mon, 17 Jan 2005 04:45:18 -0500
On Sunday 16 January 2005 16:57, Gene Heskett wrote:
>On Sunday 16 January 2005 15:47, Kurt Raschke wrote:
>>On Jan 16, 2005, at 4:25 AM, Paul Bijnens wrote:
>>> For the record:
>>> plain gtar 1.12 needs to be patched to handle large files (>
>>> 2GB). plain gtar 1.13 makes bad index-lists which amrecover
>>> cannot handle, as does the rarely used 1.13.9x, which changed the
>>> index-format again in an incompatible way.
>>>
>>> In production environment I use only 1.13.19 or 1.13.25
>>> currently.
>>
>>There is also a tar 1.15 release out now; can anyone comment on its
>>compatibility with AMANDA?  I'm asking mainly because 1.13.25 is
>>getting rather old.
>>
>>-Kurt
>
>I'll find out tonight, I just got 1.15-1 and installed it, then
> added a line to my config driver script telling it where the new
> tar was, and its re-installing 2.4.5b1-20041221 now.  amcheck seems
> to be happy, so tonights run should tell the story.
>
>As they say on the radio, stay tuned for further developements.
>
>Here, gtar was installed in /bin/gtar, and the new tar is
>in /usr/local/bin/tar' so the script I use got a new line:
>----------------
>#!/bin/sh
># since I'm always forgetting to su amanda...
>if [ `whoami` != 'amanda' ]; then
> echo
> echo "!!!!!!!!!!!! Warning !!!!!!!!!!!!"
> echo "Amanda needs to be configured and built by the user amanda,"
> echo "but must be installed by user root."
> echo
> exit 1
>fi
>make clean
>rm -f config.status config.cache
>./configure --with-user=amanda \
> --with-group=disk \
> --with-owner=amanda \
> --with-gnu-ld \
> --prefix=/usr/local \
> --with-tapedev="FILE:/amandatapes" \
> --with-debugging=/tmp/amanda-dbg/ \
> --with-tape-server=coyote.coyote.den \
> --with-amandahosts \
> --with-configdir=/usr/local/etc/amanda \
> --with-gnutar=/usr/local/bin/tar
>
>make
>-----------------
>
>Hopefully this is enough to make it use the newer tar. It logs in
> as:
>
>[amanda@coyote amanda-2.4.5b1-20041221]$ /usr/local/bin/tar
> --version tar (GNU tar) 1.15.1
>
>And I didn't give it anything special when I ran ./configure to
> build it.  Should I have?

Ok, here is what I got:
amdump, no errors
amverify of the backups made, no errors
amrecover seems not to be able to read aamanda.conf, and its asking 
for /usr/local/etc/amanda/DailySet1/amanda.conf.  But that was 
renamed to just /usr/local/etc/amanda/Daily/amanda.conf proably 2 
years ago.
----
[root@coyote data]# amrecover
AMRECOVER Version 2.4.5b1-20041221. Contacting server on 
coyote.coyote.den ...
220 coyote AMANDA index server (2.4.5b1-20041221) ready.
200 Access OK
Setting restore date to today (2005-01-17)
200 Working date set to 2005-01-17.
501 Could not read config 
file /usr/local/etc/amanda/DailySet1/amanda.conf!
amrecover>quit
----------
amrestore seems a bit dangerous:
------------
[root@coyote data]# amrestore
amrestore: Must specify tape-device or holdingfile
amrestore: Usage: amrestore [-b blocksize] [-r|-c] [-p] [-h] [-f 
fileno] [-l label] tape-device|holdingfile [hostname [diskname 
[datestamp [hostname [diskname [datestamp ... ]]]]]]
-----------
And dd seems not to be able to do it either:
----------------
root@coyote data]# dd if=00013.coyote._root.0 bs=32k count=1
AMANDA: FILE 20050117 coyote /root lev 0 comp .gz 
program /usr/local/bin/tar
To restore, position tape at start of file and run:
        dd if=<tape> bs=32k skip=1 | /usr/bin/gzip -dc | 
usr/local/bin/tar -f... -
--------------------
[root@coyote data]#  dd if=00013.coyote._root.0 bs=32k skip=1 
| /usr/bin/gzip -dc | /usr/local/bin/tar -f... -
/usr/local/bin/tar: You must specify one of the `-Acdtrux' options
Try `/usr/local/bin/tar --help' or `/usr/local/bin/tar --usage' for 
more
information.
3+0 records in
2+0 records out
----------------
And did not generate any extra data in the /amandatapes/Dailys/data 
subdir where I was cd'd to at the time.
Adding a x to the tar invocation makes sense though, so:
----------
[root@coyote data]#  dd if=00013.coyote._root.0 bs=32k skip=1 
| /usr/bin/gzip -dc | /usr/local/bin/tar -xf... -
/usr/local/bin/tar: ...: Cannot open: No such file or directory
/usr/local/bin/tar: Error is not recoverable: exiting now
4+0 records in
3+0 records out
------------------
So I'm puzzled as to whether I'm still doing something wrong, or this 
new tar doesn't recognize the '-f... -' for the stdin from a pipe 
option.

Humm, the original gtar doesn't like it either.  Same error, so its 
obviously me.  Removing the ..., which I don't recall was the correct 
usage, and the older gtar is now busy filling that virtual tape 
directory with the contents of the level 0 /root file.  That will be 
a mess to cleanup...

And its reporting some bad timestamps???:
--------------
[root@coyote data]#  dd if=00013.coyote._root.0 bs=32k skip=1 
| /usr/bin/gzip -dc | /bin/gtar -xf -
/bin/gtar: ./.kde/share/apps/RecentDocuments/cdrom.desktop: time stamp 
2020-04-27 15:36:21 is 482063157 s in the future
/bin/gtar: ./.kde/share/apps/RecentDocuments/check_shields.sh.desktop: 
time stamp 2011-01-24 18:39:40 is 189959355s in the future
/bin/gtar: ./.kde/share/apps/RecentDocuments/sndshield.ver.desktop: 
time stamp 2011-01-24 18:48:24 is 189959879 s in the future
/bin/gtar: ./.kde/share/apps/RecentDocuments/soundon.log.desktop: time 
stamp 2011-01-24 18:41:02 is 189959437 s inthe future
/bin/gtar: ./.mcop/random-seed: time stamp 2020-04-28 03:05:10 is 
482104454 s in the future
90544+0 records in
90544+0 records out
-------
Mess cleaned up, now repeat with new tar:
---------
Which is a repeat except it ran into an error rather late because I'd 
already deleted the subdir target for a file in my haste to clean up 
the mess as it was being made.  In both cases the recovered files 
looked perfectly ok.

So I'm of the opinion that this new tar-1.15-1 is just as serviceable 
as the older 1.13-25 I've been using since several years ago now.  At 
least on a linux system since thats all I have here.

How about you Jon, have you tried it on your solaris boxes yet?

But whats the deal with amrecover?  That config dir its asking for 
hasn't existed on this system for many months, and many, many updates 
of amanda's build as I normally stay with the latest 2.4.5 snapshots.

And I'd have to say that its from the latest snapshot that I rebuilt 
just yesterday:
------------
[root@coyote data]# which amrecover
/usr/local/sbin/amrecover
[root@coyote data]# ls -l /usr/local/sbin/amrecover
-rwxr-x---  1 amanda disk 230302 Jan 16 
16:50 /usr/local/sbin/amrecover
-----------
So I'm scratching my head on this one, help anybody?

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.32% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.