Everything looks good!!!

With the DAR feature of 3.4, amgtar ask for the data segment from the 
backup stream

amgtar ask for two segment of data:

    restore block 15134720 (29560) to 32509951 (63496)
    restore block 44022821376 (85982073) to 680836734975 (1329759248)

Which is 636831288832 bytes of data

amfetchdump report it send both segment of data
amrecover report that 636831288832 bytes of data was sent to amgtar

So where is the problem?

 1. in tar??
 2. amgtar do not send the correct segment list
      * bug in the algorithm
      * corrupted state file
 3. amidxtaped do no send the data it was asked to send
 4. ...


Can you send me the
/opt/amanda/usr/adm/amanda/top/index/localhost/_data__noel9/20170220213001_0-state.gz
 
file,I will check if amgtar get the correct list of data segment.

Can you do the following test:

  * #keep a copy of /bin/tar
      o cp /bin/tar /bin/tar.orig
  * Temporarily replace /bin/tar by an executable script that do: cat -
     > /holddisk/restore/data
  * # do the amrecover
      o cd /holddisk/restore/noel9
      o amrecover ....
  * #restore original /bin/tar
      o mv /bin/tar.orig /bin/tar
  * ls -al /holddisk/restore/data # its size should be 636831288832 bytes
  * /bin/tar -tvf /holddisk/restore/data  # it should list all files in
    the ./TLE subdir
  * cd /holddisk/restore/noel9
  * /bin/tar -xpGvf /holddisk/restore/data --wildcards ./TLE   # did it
    restore all files
  * /bin/tar -xpGvf /holddisk/restore/data ./TLE # did it restore all files
  * /bin/tar -xpGvf /holddisk/restore/data # did it restore all files
  * /bin/tar -xpvf /holddisk/restore/data # did it restore all files


Jean-Louis


On 22/02/17 12:53 PM, Jean-Francois Malouin wrote:
> * Jean-Francois Malouin <[email protected]> [20170222 
> 12:09]:
>> * Jean-Louis Martineau <[email protected]> [20170222 11:02]:
>>> Jean-Francois,
>>>
>>> Which application are you using?
>> amgtar
>>
>>> Post the debug files, amrecover and the one for the application.
>> I will post them once the amrecover completes.
> They are attached.
>
> I've removed the 500,000 lines which contains
>      amgtar: recover_dump_state_file: 22 /some/path
> in debug file amgtar.20170222114313.debug
>
> The file amrecover-interactive-session.txt contains
> the amrecover session to try to restore from
> DLE localhost:/data_/noel9 the subdir ./TLE
> from the last full.
>
> cheers,
> jf
>
>> Thanks,
>> jf
>>
>>
>>> Jean-Louis
>>>
>>> On 22/02/17 10:52 AM, Jean-Francois Malouin wrote:
>>>> Hi,
>>>>
>>>> I had this buried into another post...
>>>>
>>>> When using amrecover, 'add .' at the prompt of amrecover will not
>>>> descend recursively in the DLE at the current backup working directory:
>>>> after doing 'extract', it just seems restore '.', and that's it.
>>>> Same goes with 'add someDir', the dir 'someDir' will be restore but
>>>> empty.
>>>>
>>>> Same with 'add *' : it will add the matching files and directories in
>>>> the current backup working directory, but again will not do a recursive
>>>> restore.
>>>>
>>>> Makes amrecover a bit useless unless to restore single files in not too
>>>> complicated file hierarchy. In my case though, I have subdirs with
>>>> thousands of files and subdirs: amrecover then becomes useless and I'm
>>>> stuck with restoring the entire DLE with amfetchdump.
>>>>
>>>> That's not the behaviour I had with previous version and maybe even with
>>>> 3.4.1.  Am I doing something wrong or overlooking something simple?
>>>>
>>>> thanks,
>>>> jf

Reply via email to