Am 27.05.22 um 17:30 schrieb Nathan Stratton Treadway:
Ah, so euxvo_crypt is run by the amidxtaped process rather than by the
amrecover process itself.
What does strace show amrecover is doing during this period?
And "ps -ef" shows that the openssl process is still alive (i.e. not
defunct).
On Fri, May 27, 2022 at 15:54:50 +0200, Stefan G. Weichinger wrote:
>
>
> forgot pstree:
>
> -tmux: server-+-bash---amrecover-+-amandad-+-amandad
>
>| | `-amindexd
>
>| |-amandad-+-amandad
>
>
forgot pstree:
-tmux: server-+-bash---amrecover-+-amandad-+-amandad
| | `-amindexd
| |-amandad-+-amandad
| |
`-amidxtaped-+-exuvo_crypt---openssl
Am 27.05.22 um 14:28 schrieb Stefan G. Weichinger:
Am 27.05.22 um 14:05 schrieb Nathan Stratton Treadway:
On Fri, May 27, 2022 at 10:28:09 +0200, Stefan G. Weichinger wrote:
After that both tar and gzip.binary are shown as in ps,
whatever that means.
Okay, that's a little progress in the
Am 27.05.22 um 14:05 schrieb Nathan Stratton Treadway:
On Fri, May 27, 2022 at 10:28:09 +0200, Stefan G. Weichinger wrote:
After that both tar and gzip.binary are shown as in ps,
whatever that means.
Okay, that's a little progress in the investigation.
"" means that the process has
On Fri, May 27, 2022 at 10:28:09 +0200, Stefan G. Weichinger wrote:
> After that both tar and gzip.binary are shown as in ps,
> whatever that means.
Okay, that's a little progress in the investigation.
"" means that the process has exited, but the return code from
the process has not been read
Am 26.05.22 um 12:05 schrieb Stefan G. Weichinger:
Am 26.05.22 um 12:01 schrieb Stefan G. Weichinger:
Am 26.05.22 um 04:10 schrieb Exuvo:
I think i had "/bin/gzip: gzip: stdin: decompression OK, trailing
garbage ignored" before i used -q to zstd which suppresses warnings
and interactivity.
Am 26.05.22 um 12:01 schrieb Stefan G. Weichinger:
Am 26.05.22 um 04:10 schrieb Exuvo:
I think i had "/bin/gzip: gzip: stdin: decompression OK, trailing
garbage ignored" before i used -q to zstd which suppresses warnings
and interactivity.
Maybe I could edit to "gzip -d" somewhere in the
Am 26.05.22 um 04:10 schrieb Exuvo:
I think i had "/bin/gzip: gzip: stdin: decompression OK, trailing
garbage ignored" before i used -q to zstd which suppresses warnings and
interactivity.
Maybe I could edit to "gzip -d" somewhere in the code to also suppress this?
Am 26.05.22 um 04:10 schrieb Exuvo:
From my notes when i was doing recovery testing:
For some reason if i use encryption i get a single spurious error at
the end of amcheckdump or amrecover if you recover the last file written:
application stderr: /usr/bin/tar: Skipping to next header
Am 26.05.22 um 03:48 schrieb Exuvo:
To handle changing device names use ex
/dev/tape/by-id/scsi-HUE12340E22-nst and /dev/tape/by-id/scsi-DEC1234567
Nice hack, thanks. Applied.
From my notes when i was doing recovery testing:
For some reason if i use encryption i get a single spurious error at the end
of amcheckdump or amrecover if you recover the last file written:
application stderr: /usr/bin/tar: Skipping to next header
application stderr: /usr/bin/tar: Exiting
To handle changing device names use ex /dev/tape/by-id/scsi-HUE12340E22-nst and
/dev/tape/by-id/scsi-DEC1234567
Anton "exuvo" Olsson
ex...@exuvo.se
On 2022-05-25 14:50, Stefan G. Weichinger wrote:
Am 25.05.22 um 14:41 schrieb Nuno Dias:
My conf (the relevant parts)
tpchanger "robot"
On Wed, May 25, 2022 at 17:09:22 +0200, Stefan G. Weichinger wrote:
>
> So to me it looks that my dumptype with both compression and
> encryption is the problem.
>
> I use the script provided by Anton "exuvo" Olsson, he shared it in
> earlier threads here.
>
> The current iteration on this
Am 25.05.22 um 16:46 schrieb Stefan G. Weichinger:
The tested DLE is encrypted and compressed. Yes, redundant ... I can
change that in the future.
The first part gets read perfectly, but it seems that the end of the
tarball crashes things somehow.
I remember that error from mailing list
Am 25.05.22 um 16:12 schrieb Nathan Stratton Treadway:
When doing an extract tar does read on to the end of the tar file before
exiting, but "hours and hours" seems like a long time to wait for
that...
Is tar still running (e.g. what does "top" or "ps" show)? If so, what
does strace on the
On Wed, May 25, 2022 at 14:50:00 +0200, Stefan G. Weichinger wrote:
> Currently I have another amrecover running. It restored from tape1
> .. and now I only see these lines in the current debug file
> "amidxtaped.20220525123652.debug":
>
> Wed May 25 14:48:25.078884308 2022: pid 705002:
Am 25.05.22 um 15:35 schrieb Nuno Dias:
That messages seems ok, but usually the "kb" will increase with
the time, the same "kb" everytime seems a little strange,
unfortunately I can't help more than this! I think you need
someone that understand more of amanda.
Never mind, thanks for
That messages seems ok, but usually the "kb" will increase with
the time, the same "kb" everytime seems a little strange,
unfortunately I can't help more than this! I think you need
someone that understand more of amanda.
cheers,
Nuno
On Wed, 2022-05-25 at 14:50 +0200, Stefan G. Weichinger
Am 25.05.22 um 14:41 schrieb Nuno Dias:
My conf (the relevant parts)
tpchanger "robot"
define changer robot {
tpchanger "chg-robot:/dev/changer"
changerfile "/etc/amanda//changer-state"
property"tape-device" "0=tape:/dev/nst0"
property
My conf (the relevant parts)
tpchanger "robot"
define changer robot {
tpchanger "chg-robot:/dev/changer"
changerfile "/etc/amanda//changer-state"
property"tape-device" "0=tape:/dev/nst0"
property "eject-before-unload" "no"
property
Am 25.05.22 um 12:17 schrieb Nuno Dias:
I have "tapedev" in /etc/amanda/amanda-client.conf but is
commented, maybe was used a long time ago, but right now is not
necessary with my configuration.
And yes I do not choose any device or changer when I execute
amrecover.
OK, great.
My
I have "tapedev" in /etc/amanda/amanda-client.conf but is
commented, maybe was used a long time ago, but right now is not
necessary with my configuration.
And yes I do not choose any device or changer when I execute
amrecover.
Cheers,
NUno
On Wed, 2022-05-25 at 11:58 +0200, Stefan G.
Hi,
I have a similar configuration and works as expected.
The only thing different is
amrecover_changer "/dev/changer"
where /dev/changer is a sym link to /dev/sg11 (The Robot)
When I recover something I do not define anything and the
changer and tapes devices are obtain in the CONF of
At a customer I decided to do some recovery testing.
We use the chg-robot changer there, with one tape drive.
See below:
* tapetype
* changer
* taperscan
* storage
* amrecover_changer
(I could also show the whole config, but don't want to flood the list ...)
Amdumps work fine.
Recovery
25 matches
Mail list logo
