Re: amrecover/amrestore: block size too small
I do too. I'm coming out of 'hibernation' to transfer some of our unit-test-and-multi-OS-build code back out. Installcheck seems to be breathing and useful for me too. On 7/16/19 5:01 AM, Stefan G. Weichinger wrote: > Still believing in filing issues: > > https://github.com/zmanda/amanda/issues/109 > > >
Re: amrecover/amrestore: block size too small
Still believing in filing issues: https://github.com/zmanda/amanda/issues/109
Re: amrecover/amrestore: block size too small
My backup has this as the instruction block, for my first file on the tape
(after the label block):
AMANDA: SPLIT_FILE 2019062422/boot part 1/-1 lev 1 comp
.gz program /
sbin/dump
ORIGSIZE=52
DLE=<
DUMP
/boot
1
krb5
SERVER-FAST
YES
YES
AMANDA
ENDDLE
To restore, position tape at start of file and run:
dd if= bs=512k skip=1 | /bin/gzip -dc | /sbin/restore -xpGf - …
I’m running amanda 3.3.8 so yes, it mentions the block size.
However, you have to already know it (or guess at something bigger?)
to get the block off tape.
I used dd and “more" to look at that info.I store an empty reminder file
(in my recovery temp area)
titledUSE-BS-512k
to remind myself what to use. I had to guess at several sizes & try them,
before
I decided to create that reminder file.
Deb Baddorf
Fermilab
> On Jun 24, 2019, at 7:22 PM, Jon LaBadie wrote:
>
> I sent the following note to Steve. I don't have facilities
> to check if my comments are correct. Anyone care to comment
> or check?
>
> On Wed, Jun 19, 2019 at 07:37:23PM +0200, Stefan G. Weichinger wrote:
> ...
>>
>> $ amrestore --config abt -b 2097152 /dev/nst0 jupi smb_revision
>>
>> seems to work now ... at least it starts searching.
>>
>> I don't know why I have to tell that ... but it seems I have a mismatch:
>>
>> tapetype says 32 kbytes:
>>
>> define tapetype LTO-4 {
>>comment "Created by amtapetype; compression disabled; 2017-10-31
>> sgw"
>>length 698510208 kbytes
>>filemark 0 kbytes
>>speed 36696 kps
>>blocksize 32 kbytes
>> }
>>
>> changer def sets "2 mbytes":
>>
>> define changer robot {
>>tpchanger "chg-robot:/dev/sg1"
>>property "tape-device" "0=tape:/dev/nst0"
>>device-property "BLOCK_SIZE" "2 mbytes"
>>device-property "READ_BLOCK_SIZE" "2 mbytes"
>>property "eject-before-unload" "no"
>>property "use-slots" "1-24"
>>changerfile "/etc/amanda/abt/chg-robot-dev-sg1"
>> }
>>
>> storage def pulls in both:
>>
>> define storage abt {
>>tapepool "abt"
>>tapetype "LTO-4"
>>tpchanger "robot"
>> [..]
>> }
>>
>> Maybe then amrecover would also work (bailed out before as well)
End of included message <<<
>
> I don't think LTO-4 will use a 32K blocksize. Minimum is probably
> over 1M. 32K in tapetype is just what you said via command line
> or letting it default. Amrestore is probably just reading this
> and knowing, or testing, that LT0-4 won't take 32K BS.
>
> Pull off of a tape the first file. It will be named "0.".
> I think it will be 1 tape block in size. But contain < 32K of data.
>
> Pull off the first data file of a DLE and look at the first 32K.
> One of mine ends with this:
>
> To restore, position tape at start of file and run:
>dd if= bs=32k skip=1 | /usr/bin/gzip -d | /usr/libexec/
>amanda/application/amgtar restore [./file-to-restore]+
>
> The "bs=32K" in my command line may be the BS actually used.
>
> Jon
> --
> Jon H. LaBadie j...@jgcomp.com
> 11226 South Shore Rd. (703) 787-0688 (H)
> Reston, VA 20190 (703) 935-6720 (C)
Re: amrecover/amrestore: block size too small
I sent the following note to Steve. I don't have facilities
to check if my comments are correct. Anyone care to comment
or check?
On Wed, Jun 19, 2019 at 07:37:23PM +0200, Stefan G. Weichinger wrote:
...
>
> $ amrestore --config abt -b 2097152 /dev/nst0 jupi smb_revision
>
> seems to work now ... at least it starts searching.
>
> I don't know why I have to tell that ... but it seems I have a mismatch:
>
> tapetype says 32 kbytes:
>
> define tapetype LTO-4 {
> comment "Created by amtapetype; compression disabled; 2017-10-31
> sgw"
> length 698510208 kbytes
> filemark 0 kbytes
> speed 36696 kps
> blocksize 32 kbytes
> }
>
> changer def sets "2 mbytes":
>
> define changer robot {
> tpchanger "chg-robot:/dev/sg1"
> property "tape-device" "0=tape:/dev/nst0"
> device-property "BLOCK_SIZE" "2 mbytes"
> device-property "READ_BLOCK_SIZE" "2 mbytes"
> property "eject-before-unload" "no"
> property "use-slots" "1-24"
> changerfile "/etc/amanda/abt/chg-robot-dev-sg1"
> }
>
> storage def pulls in both:
>
> define storage abt {
> tapepool "abt"
> tapetype "LTO-4"
> tpchanger "robot"
> [..]
> }
>
> Maybe then amrecover would also work (bailed out before as well)
>>> End of included message <<<
I don't think LTO-4 will use a 32K blocksize. Minimum is probably
over 1M. 32K in tapetype is just what you said via command line
or letting it default. Amrestore is probably just reading this
and knowing, or testing, that LT0-4 won't take 32K BS.
Pull off of a tape the first file. It will be named "0.".
I think it will be 1 tape block in size. But contain < 32K of data.
Pull off the first data file of a DLE and look at the first 32K.
One of mine ends with this:
To restore, position tape at start of file and run:
dd if= bs=32k skip=1 | /usr/bin/gzip -d | /usr/libexec/
amanda/application/amgtar restore [./file-to-restore]+
The "bs=32K" in my command line may be the BS actually used.
Jon
--
Jon H. LaBadie j...@jgcomp.com
11226 South Shore Rd. (703) 787-0688 (H)
Reston, VA 20190 (703) 935-6720 (C)
Re: amrecover/amrestore: block size too small
Am 24.06.19 um 22:06 schrieb Debra S Baddorf: > You can also use “dd” to get the whole dump off tape. You would have to > “glue” together > any partial files; I don’t know how to do that (I’ve specified no partial > files). > > “dd” still needs a reasonably correct block size. thanks for the workaround howto but I would prefer to have a fully working amanda setup ;-) I fiddle with the parameters and managed to get amrecover working. Seems one has to relabel and/or edit the tapelist as well. I read the numerous how-to-relabel-postings ... couldn't we get a *tool* doing that? I mean, other software projects improve over time ;-) Another thought: if the blocksize of the tapetype and the blocksize of the changer-definition mismatch: shouldn't there be a warning? Something in amcheck or so ... Right now we get errors in dmesg etc ... not very user-friendly IMO. greets, Stefan
Re: amrecover/amrestore: block size too small
> On Jun 24, 2019, at 7:14 AM, Stefan G. Weichinger wrote: > > > I stil have issues here: > > amrestore --config abt -b 2097152 /dev/nst0 jupi smb_revision > Restoring from tape ABT-401 starting with file 1. > amrestore: 1: skipping split dumpfile: date 20190607213002 host juno > disk vm182 part 1/UNKNOWN lev 0 comp N program /bin/tar > > > [..] > > > amrestore: 12: restoring split dumpfile: date 20190607213002 host jupi > disk smb_revision part 1/UNKNOWN lev 1 comp .gz program /bin/tar crypt > enc client_encrypt /usr/sbin/amcrypt client_decrypt_option -d > filter stderr: > filter stderr: aespipe: write failed > filter stderr: gzip: stdin: decompression OK, trailing garbage ignored > > > What? > > I will try it with "-r"/raw now and try to decrypt later. You can also use “dd” to get the whole dump off tape. You would have to “glue” together any partial files; I don’t know how to do that (I’ve specified no partial files). “dd” still needs a reasonably correct block size. Deb Baddorf
Re: amrecover/amrestore: block size too small
I stil have issues here: amrestore --config abt -b 2097152 /dev/nst0 jupi smb_revision Restoring from tape ABT-401 starting with file 1. amrestore: 1: skipping split dumpfile: date 20190607213002 host juno disk vm182 part 1/UNKNOWN lev 0 comp N program /bin/tar [..] amrestore: 12: restoring split dumpfile: date 20190607213002 host jupi disk smb_revision part 1/UNKNOWN lev 1 comp .gz program /bin/tar crypt enc client_encrypt /usr/sbin/amcrypt client_decrypt_option -d filter stderr: filter stderr: aespipe: write failed filter stderr: gzip: stdin: decompression OK, trailing garbage ignored What? I will try it with "-r"/raw now and try to decrypt later.
Re: amrecover/amrestore: block size too small
Am 19.06.19 um 19:30 schrieb Stefan G. Weichinger:
>
> I get
>
> $ amrestore --config abt /dev/nst0 jupi smb_revision
> ERROR: Error reading Amanda header: block size too small
>
> $ amrestore --config abt -b 32768 /dev/nst0 jupi smb_revision
> ERROR: Error reading Amanda header: block size too small
>
> I don't have to say that I need these restores ...
>
> Never really understood these blocksize issues anyway.
>
> The tapetype used for long says:
>
> define tapetype LTO-4 {
> length 698510208 kbytes
> filemark 0 kbytes
> speed 36696 kps
> blocksize 32 kbytes
> }
>
> How to restore, please?
$ amrestore --config abt -b 2097152 /dev/nst0 jupi smb_revision
seems to work now ... at least it starts searching.
I don't know why I have to tell that ... but it seems I have a mismatch:
tapetype says 32 kbytes:
define tapetype LTO-4 {
comment "Created by amtapetype; compression disabled; 2017-10-31
sgw"
length 698510208 kbytes
filemark 0 kbytes
speed 36696 kps
blocksize 32 kbytes
}
changer def sets "2 mbytes":
define changer robot {
tpchanger "chg-robot:/dev/sg1"
property "tape-device" "0=tape:/dev/nst0"
device-property "BLOCK_SIZE" "2 mbytes"
device-property "READ_BLOCK_SIZE" "2 mbytes"
property "eject-before-unload" "no"
property "use-slots" "1-24"
changerfile "/etc/amanda/abt/chg-robot-dev-sg1"
}
storage def pulls in both:
define storage abt {
tapepool "abt"
tapetype "LTO-4"
tpchanger "robot"
[..]
}
Maybe then amrecover would also work (bailed out before as well)
amrecover/amrestore: block size too small
I get
$ amrestore --config abt /dev/nst0 jupi smb_revision
ERROR: Error reading Amanda header: block size too small
$ amrestore --config abt -b 32768 /dev/nst0 jupi smb_revision
ERROR: Error reading Amanda header: block size too small
I don't have to say that I need these restores ...
Never really understood these blocksize issues anyway.
The tapetype used for long says:
define tapetype LTO-4 {
length 698510208 kbytes
filemark 0 kbytes
speed 36696 kps
blocksize 32 kbytes
}
How to restore, please?
