Hi Dustin 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Dustin J. Mitchell
> Sent: Monday, September 27, 2010 7:19 PM
> To: Titl Erich
> Cc: [email protected]
> Subject: Re: FW: amrecover bug?
> 
> On Mon, Sep 27, 2010 at 12:05 PM, Titl Erich 
> <[email protected]> wrote:
> > Here for your reference the outcome of amfetchdump does not 
> look good
> >
> > subversion:/backup# amrecover
> 
> that's amrecover.

:-(
I tried amfetchdump on the client first, so this is a remnant of the
original message.

Here are the results of amfetchdump on the server

amanda:/amanda-holding$ /usr/sbin/amfetchdump DailySet1 subversion.ruf.ch
/data
10 volume(s) needed for restoration
The following volumes are needed: amanda-0009 amanda-0010 amanda-0001
amanda-0002 amanda-0003 amanda-0004 amanda-0005 amanda-0006 amanda-0007
amanda-0008
Press enter when ready

amfetchdump: 12: restoring split dumpfile: date 20100915010002 host
subversion.ruf.ch disk /data part 1/UNKNOWN lev 1 comp N program /sbin/dump
amfetchdump: 9: restoring split dumpfile: date 20100916010001 host
subversion.ruf.ch disk /data part 1/UNKNOWN lev 1 comp N program /sbin/dump
amfetchdump: 11: restoring split dumpfile: date 20100917010002 host
subversion.ruf.ch disk /data part 1/UNKNOWN lev 1 comp N program /sbin/dump
amfetchdump: 13: restoring split dumpfile: date 20100918010001 host
subversion.ruf.ch disk /data part 1/UNKNOWN lev 0 comp N program /sbin/dump
amfetchdump: 10: restoring split dumpfile: date 20100921010002 host
subversion.ruf.ch disk /data part 1/UNKNOWN lev 1 comp N program /sbin/dump
amfetchdump: 13: restoring split dumpfile: date 20100921082312 host
subversion.ruf.ch disk /data part 1/UNKNOWN lev 1 comp N program /bin/tar
amfetchdump: 6: restoring split dumpfile: date 20100922010002 host
subversion.ruf.ch disk /data part 1/UNKNOWN lev 2 comp N program /bin/tar
amfetchdump: 3: restoring split dumpfile: date 20100923010002 host
subversion.ruf.ch disk /data part 1/UNKNOWN lev 2 comp N program /bin/tar
amfetchdump: 4: restoring split dumpfile: date 20100924010002 host
subversion.ruf.ch disk /data part 1/UNKNOWN lev 2 comp N program /bin/tar
amfetchdump: 13: restoring split dumpfile: date 20100925010002 host
subversion.ruf.ch disk /data part 1/UNKNOWN lev 0 comp N program /bin/tar

So some older versions still are dumps whereas the newer are tar files. 

> 
> >> Is there any extra data in the dumpfile?
> >
> > Not that I know of. During amrecover I can observe the data 
> stream and 
> > I _hope_ it is not garbled to an extent that it is not 
> processable. It 
> > takes the amount of time I would expect to extract the file 
> and send 
> > it across the network to the client.
> >
> > On the server I can extract the respective file easily and 
> also feed 
> > it successfully to tar (I have not tried dump/restore anymore).
> 
> Meaning with 'mt' and 'dd'?  That's good to know!

Yes, I reported this in my earlier mail. 

Here are the files amfetchdump extracted on the server.

-rw------- 1 amandabackup disk    22839296 2010-09-27 18:52
subversion.ruf.ch._data.20100915010002.1
-rw------- 1 amandabackup disk    25919488 2010-09-27 18:52
subversion.ruf.ch._data.20100916010001.1
-rw------- 1 amandabackup disk    77889536 2010-09-27 18:52
subversion.ruf.ch._data.20100917010002.1
-rw------- 1 amandabackup disk 13443792896 2010-09-27 19:22
subversion.ruf.ch._data.20100918010001.0
-rw------- 1 amandabackup disk    24969216 2010-09-27 19:22
subversion.ruf.ch._data.20100921010002.1
-rw------- 1 amandabackup disk 13324156928 2010-09-27 19:53
subversion.ruf.ch._data.20100921082312.1
-rw------- 1 amandabackup disk    13991936 2010-09-27 19:53
subversion.ruf.ch._data.20100922010002.2
-rw------- 1 amandabackup disk    16416768 2010-09-27 19:53
subversion.ruf.ch._data.20100923010002.2
-rw------- 1 amandabackup disk    21495808 2010-09-27 19:53
subversion.ruf.ch._data.20100924010002.2
-rw------- 1 amandabackup disk 14045052928 2010-09-27 20:28
subversion.ruf.ch._data.20100925010002.0

And here is the partially tar list of the latest layer 0 tar archive, the
one amrecover tried to fetch

amanda:/amanda-holding$ tar tf subversion.ruf.ch._data.20100925010002.0 |
more
./
./amanda/
./lost+found/
./svn/
./svn/.ssh/
./svn/backup/
./svn/repositories/
./svn/repositories/RT_DevCom/
./svn/repositories/RT_DevCom/conf/
./svn/repositories/RT_DevCom/db/
./svn/repositories/RT_DevCom/db/locks/
./svn/repositories/RT_DevCom/db/locks/090/
./svn/repositories/RT_DevCom/db/locks/104/
./svn/repositories/RT_DevCom/db/locks/151/
./svn/repositories/RT_DevCom/db/locks/60e/
...

As you can see, the svn directory exists (amrecover pretended it was not
there)

Right now I am trying to extract the contents from the above tart file, it
will take some time, but I am confident it will work correctly. Will report
later.

cheers

Erich

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to