On Sat, Dec 19, 2020 at 03:32:07 -0500, Gene Heskett wrote:
> But the problem is not fixed:
>
> FAILURE DUMP SUMMARY:
> rpi4 /usr/lib lev 0 partial taper: source server crc (efe0c707:1538583893)
> and input server crc (fa79e777:1538583893)
> differ)
(This is back to the CRC error, so I'll
On Friday 18 December 2020 23:15:38 Nathan Stratton Treadway wrote:
> On Fri, Dec 18, 2020 at 19:31:52 -0500, Gene Heskett wrote:
> > That likely won't happen again if at all, as I doubled the size of a
> > vtape, specifically to stop that. I'm only using around half of a 2T
> > drive for 60
On Fri, Dec 18, 2020 at 19:31:52 -0500, Gene Heskett wrote:
> That likely won't happen again if at all, as I doubled the size of a
> vtape, specifically to stop that. I'm only using around half of a 2T
> drive for 60 vtapes. But I see it is growing.
>
> /dev/sde1 1.8T 1.1T 617G 65%
On Friday 18 December 2020 19:08:17 Nathan Stratton Treadway wrote:
> On Fri, Dec 18, 2020 at 02:56:55 -0500, Gene Heskett wrote:
> > But that after amanda script worked and I have uptodate indices and
> > config files in that vtape now. [...] so a/o vtape Dailys-25 I have
> > what I think is a
On Fri, Dec 18, 2020 at 02:56:55 -0500, Gene Heskett wrote:
> But that after amanda script worked and I have uptodate indices and
> config files in that vtape now. [...] so a/o vtape Dailys-25 I have
> what I think is a good backup again.
Great!
Since you commented out the section of the "if"
On Friday 18 December 2020 17:27:50 Nathan Stratton Treadway wrote:
> However, off hand it seems like the warning message you were getting
> is an indication that the paremeter is just not implemented yet in
> your version of the shadow utilties, so if you don't want to
> investigate that side of
On Fri, Dec 18, 2020 at 16:23:47 -0500, Gene Heskett wrote:
> On Friday 18 December 2020 15:06:14 Nathan Stratton Treadway wrote:
>
> > On Fri, Dec 18, 2020 at 14:44:07 -0500, Gene Heskett wrote:
> > > On Friday 18 December 2020 14:33:03 Nathan Stratton Treadway wrote:
> > > > ls -l
On Friday 18 December 2020 15:09:19 Nathan Stratton Treadway wrote:
> ls -lc /etc/login.defs /etc/default/su
-rw-r--r-- 1 root root20 Dec 17 10:27 /etc/default/su
-rw-r--r-- 1 root root 10496 Aug 7 2019 /etc/login.defs
Thanks Nathan.
Copyright 2019 by Maurice E. Heskett
Cheers, Gene
On Friday 18 December 2020 15:06:14 Nathan Stratton Treadway wrote:
> On Fri, Dec 18, 2020 at 14:44:07 -0500, Gene Heskett wrote:
> > On Friday 18 December 2020 14:33:03 Nathan Stratton Treadway wrote:
> > > ls -l /etc/login.defs /etc/defaults/su
> >
> > ls: cannot access '/etc/defaults/su': No
On Fri, Dec 18, 2020 at 15:03:07 -0500, Nathan Stratton Treadway wrote:
> What do you get from these commands?:
> $ ls -l /etc/login.defs /etc/default/su
>
> $ dpkg -S /etc/login.defs
>
> $ dpkg -S /etc/default/su
>
> $ apt-cache policy login
>
Ooops, should have included this one
On Fri, Dec 18, 2020 at 14:44:07 -0500, Gene Heskett wrote:
> On Friday 18 December 2020 14:33:03 Nathan Stratton Treadway wrote:
>
> > ls -l /etc/login.defs /etc/defaults/su
> ls: cannot access '/etc/defaults/su': No such file or directory
> -rw-r--r-- 1 root root 10496 Aug 7 2019
On Fri, Dec 18, 2020 at 14:42:45 -0500, Gene Heskett wrote:
> On Friday 18 December 2020 14:33:03 Nathan Stratton Treadway wrote:
>
> > grep ALWAYS_SET_PATH /etc/login.defs /etc/default/*
> etc/login.defs:ALWAYS_SET_PATH yes
> grep: /etc/default/grub.d: Is a directory
>
On Friday 18 December 2020 14:33:03 Nathan Stratton Treadway wrote:
> ls -l /etc/login.defs /etc/defaults/su
ls: cannot access '/etc/defaults/su': No such file or directory
-rw-r--r-- 1 root root 10496 Aug 7 2019 /etc/login.defs
Copyright 2019 by Maurice E. Heskett
Cheers, Gene Heskett
--
On Friday 18 December 2020 14:33:03 Nathan Stratton Treadway wrote:
> grep ALWAYS_SET_PATH /etc/login.defs /etc/default/*
etc/login.defs:ALWAYS_SET_PATH yes
grep: /etc/default/grub.d: Is a directory
/etc/default/su:ALWAYS_SET_PATH yes
grep: /etc/default/tdm.d: Is a directory
grep:
On Fri, Dec 18, 2020 at 13:38:21 -0500, Gene Heskett wrote:
> On Friday 18 December 2020 10:53:55 Nathan Stratton Treadway wrote:
>
> > On Fri, Dec 18, 2020 at 01:10:10 -0500, Gene Heskett wrote:
> > > On Thursday 17 December 2020 23:03:59 Nathan Stratton Treadway wrote:
> > > > What do
> > > >
On Friday 18 December 2020 10:53:55 Nathan Stratton Treadway wrote:
> On Fri, Dec 18, 2020 at 01:10:10 -0500, Gene Heskett wrote:
> > On Thursday 17 December 2020 23:03:59 Nathan Stratton Treadway wrote:
> > > (You can check this by running something simple via su, e.g.
> > > $ su amanda -c
On Fri, Dec 18, 2020 at 01:10:10 -0500, Gene Heskett wrote:
> On Thursday 17 December 2020 23:03:59 Nathan Stratton Treadway wrote:
> > (You can check this by running something simple via su, e.g.
> > $ su amanda -c "echo test message"
> > )
> Which generates the error.
okay, check.
> > What
On Friday 18 December 2020 03:03:39 Gene Heskett wrote:
> On Friday 18 December 2020 01:09:02 Gene Heskett wrote:
> > On Thursday 17 December 2020 22:23:16 Nathan Stratton Treadway wrote:
> > > On Thu, Dec 17, 2020 at 01:58:27 -0500, Gene Heskett wrote:
> > > > Here is the completed output of
On Friday 18 December 2020 01:09:02 Gene Heskett wrote:
> On Thursday 17 December 2020 22:23:16 Nathan Stratton Treadway wrote:
> > On Thu, Dec 17, 2020 at 01:58:27 -0500, Gene Heskett wrote:
> > > Here is the completed output of that command:
> > > root@coyote:~$ su amanda -c
On Thursday 17 December 2020 22:23:16 Nathan Stratton Treadway wrote:
> On Thu, Dec 17, 2020 at 01:58:27 -0500, Gene Heskett wrote:
> > Here is the completed output of that command:
> > root@coyote:~$ su amanda -c "/usr/local/sbin/amstatus Daily"
>
> [...]
>
> > taped : 78 13416m
On Thursday 17 December 2020 23:03:59 Nathan Stratton Treadway wrote:
> On Thu, Dec 17, 2020 at 10:38:58 -0500, Gene Heskett wrote:
> > On Thursday 17 December 2020 09:24:58 Richard Sass wrote:
> > > Gene:
> > >
> > > BUT Whats line 2 above, I've wasted a year looking for that, it
> > > does not
On Thursday 17 December 2020 22:23:16 Nathan Stratton Treadway wrote:
> On Thu, Dec 17, 2020 at 01:58:27 -0500, Gene Heskett wrote:
> > Here is the completed output of that command:
> > root@coyote:~$ su amanda -c "/usr/local/sbin/amstatus Daily"
>
> [...]
>
> > taped : 78 13416m
On Thu, Dec 17, 2020 at 10:38:58 -0500, Gene Heskett wrote:
> On Thursday 17 December 2020 09:24:58 Richard Sass wrote:
>
> > Gene:
> >
> > BUT Whats line 2 above, I've wasted a year looking for that, it does
> > not grep in the whole src code tree.
> >
> > configuration error - unknown item
On Thu, Dec 17, 2020 at 01:58:27 -0500, Gene Heskett wrote:
> Here is the completed output of that command:
> root@coyote:~$ su amanda -c "/usr/local/sbin/amstatus Daily"
[...]
> taped : 78 13416m 13308m (100.81%) (100.81%)
> tape 1 : 79 24046m 24046m (
An aside:One thing you might do first is to save the few backups that are
still good.
If there are still some. There were, a few messages ago.
If there are 5 still good, then set your tapenum to 60-5=55
and quickly do
amadmin no-reuse tapename
for all the still-good backups.
On Thursday 17 December 2020 12:37:43 Stefan G. Weichinger wrote:
> Am 17.12.20 um 16:38 schrieb Gene Heskett:
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905564
> >
> > Its of no help on this stretch install.
> > gene@coyote:~$ sudo -i
> > [sudo] password for gene:
> > root@coyote:~$
Am 17.12.20 um 16:38 schrieb Gene Heskett:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905564
Its of no help on this stretch install.
gene@coyote:~$ sudo -i
[sudo] password for gene:
root@coyote:~$ su amanda -c "geany bak-indices-configs"
configuration error - unknown item
On Thursday 17 December 2020 09:24:58 Richard Sass wrote:
> Gene:
>
> BUT Whats line 2 above, I've wasted a year looking for that, it does
> not grep in the whole src code tree.
>
> configuration error - unknown item 'ALWAYS_SET_PATH' (notify
> administrator)
>
> Perhaps this will help
>
>
-
From: owner-amanda-us...@amanda.org On
Behalf Of Gene Heskett
Sent: Thursday, December 17, 2020 1:58 AM
To: amanda-users@amanda.org
Subject: Re: Amrecover hangs after restore
On Wednesday 16 December 2020 21:38:12 Nathan Stratton Treadway wrote:
> On Wed, Dec 16, 2020 at 16:41:39 -0500, G
On Thursday 17 December 2020 07:50:25 Gene Heskett wrote:
> On Thursday 17 December 2020 06:48:16 Gene Heskett wrote:
>
> And this is a revolting development.
>
> NO newer amanda than 3.5.1 will actually build on this debian stretch.
> Mostly -dev dependencies that will not install because of the
On Thursday 17 December 2020 06:48:16 Gene Heskett wrote:
And this is a revolting development.
NO newer amanda than 3.5.1 will actually build on this debian stretch.
Mostly -dev dependencies that will not install because of the crypt
updates since. So I did build it and reinstalled it. The
On Thursday 17 December 2020 06:34:53 Gene Heskett wrote:
> On Thursday 17 December 2020 06:03:44 Gene Heskett wrote:
>
> Another detail that might be useful, I kept many of the amanda-4.0
> releases when a fellow named Mitchel was working on it in 2012,
> quitting when the last one didn't work.
On Thursday 17 December 2020 06:03:44 Gene Heskett wrote:
Another detail that might be useful, I kept many of the amanda-4.0
releases when a fellow named Mitchel was working on it in 2012, quitting
when the last one didn't work. so I am going to make and install about
the next to the last one,
On Thursday 17 December 2020 04:45:01 Stefan G. Weichinger wrote:
> Am 16.12.20 um 17:16 schrieb Gene Heskett:
> > I wrote all that back in the 2004 time frame, long before I had a
> > pulmonary embolism at age 79 that cost me a few IQ points. Lets
> > just say that its one hell of a scary way
On Thursday 17 December 2020 04:58:54 Stefan G. Weichinger wrote:
> Am 16.12.20 um 22:41 schrieb Gene Heskett:
> > So here is the that script--
> >
> > #!/bin/bash
>
> I put it up at:
>
> https://github.com/stefangweichinger/amanda-helpers/blob/master/genes_
>helper.sh
>
> So if someone wants
Am 16.12.20 um 22:41 schrieb Gene Heskett:
So here is the that script--
#!/bin/bash
I put it up at:
https://github.com/stefangweichinger/amanda-helpers/blob/master/genes_helper.sh
So if someone wants to go the github way of improving it, that is
possible now.
Am 16.12.20 um 17:16 schrieb Gene Heskett:
I wrote all that back in the 2004 time frame, long before I had a
pulmonary embolism at age 79 that cost me a few IQ points. Lets just
say that its one hell of a scary way to die, which over 98% of people
do, but I survived.
Sorry to hear about the
On Thursday 17 December 2020 01:58:27 Gene Heskett wrote:
> On Wednesday 16 December 2020 21:38:12 Nathan Stratton Treadway wrote:
> > On Wed, Dec 16, 2020 at 16:41:39 -0500, Gene Heskett wrote:
> > > So here is the that script--
> >
> > Okay, a couple things:
> > >
On Wednesday 16 December 2020 21:38:12 Nathan Stratton Treadway wrote:
> On Wed, Dec 16, 2020 at 16:41:39 -0500, Gene Heskett wrote:
> > So here is the that script--
>
> Okay, a couple things:
> > PARTS_WRITTEN=`${AM_SBIN_DIR}/amstatus $CONFIGNAME | grep taped |
> > awk -F: '{print $2}' | awk
On Wed, Dec 16, 2020 at 16:41:39 -0500, Gene Heskett wrote:
> So here is the that script--
>
Okay, a couple things:
> PARTS_WRITTEN=`${AM_SBIN_DIR}/amstatus $CONFIGNAME | grep taped | awk -F:
> '{print $2}' | awk '{print $1}'`
If you run "amstatus" manually, what does your "taped"
On Wednesday 16 December 2020 16:05:15 Nathan Stratton Treadway wrote:
> On Wed, Dec 16, 2020 at 15:37:32 -0500, Gene Heskett wrote:
> > On Wednesday 16 December 2020 12:23:28 Nathan Stratton Treadway wrote:
> > > On Wed, Dec 16, 2020 at 09:42:47 -0500, Gene Heskett wrote:
> > > > You reminded me
On Wed, Dec 16, 2020 at 15:37:32 -0500, Gene Heskett wrote:
> On Wednesday 16 December 2020 12:23:28 Nathan Stratton Treadway wrote:
>
> > On Wed, Dec 16, 2020 at 09:42:47 -0500, Gene Heskett wrote:
> > > You reminded me of that, so its now done. We'll see if that fixes
> > > it.
> >
> > (Note
On Wednesday 16 December 2020 12:23:28 Nathan Stratton Treadway wrote:
> On Wed, Dec 16, 2020 at 09:42:47 -0500, Gene Heskett wrote:
> > You reminded me of that, so its now done. We'll see if that fixes
> > it.
>
> (Note that putting in the quote characters should prevent the shell
> from
On Wed, Dec 16, 2020 at 09:42:47 -0500, Gene Heskett wrote:
> You reminded me of that, so its now done. We'll see if that fixes it.
(Note that putting in the quote characters should prevent the shell from
aborting due to the syntax error, but it won't fix the underlying
problem that the contents
On Wednesday 16 December 2020 10:12:52 Stefan G. Weichinger wrote:
> Am 16.12.20 um 15:42 schrieb Gene Heskett:
> > On Wednesday 16 December 2020 05:14:14 Stefan G. Weichinger wrote:
> >> https://github.com/stefangweichinger/amanda-helpers
> >>
> >> ;-)
> >>
> >> not much content so far.
> >
> >
Am 16.12.20 um 15:42 schrieb Gene Heskett:
On Wednesday 16 December 2020 05:14:14 Stefan G. Weichinger wrote:
https://github.com/stefangweichinger/amanda-helpers
;-)
not much content so far.
As I see. What does it take to get commit perms?
well ...
That needs the whole "how to use
On Wednesday 16 December 2020 05:19:54 Stefan G. Weichinger wrote:
> Am 14.12.20 um 20:04 schrieb Gene Heskett:
> > On Monday 14 December 2020 09:51:20 Stefan G. Weichinger wrote:
> >> Am 14.12.20 um 13:57 schrieb Gene Heskett:
> >>> 1. take your Replyto: back out of your headers so I can reply
On Wednesday 16 December 2020 05:14:14 Stefan G. Weichinger wrote:
> Am 14.12.20 um 22:13 schrieb Nathan Stratton Treadway:
> >>> So, what's on line 135 of the bak-indices-configs script?
> >>
> >> That is a very long if else fi thing, wordwrap off:
> >>
Am 14.12.20 um 20:04 schrieb Gene Heskett:
On Monday 14 December 2020 09:51:20 Stefan G. Weichinger wrote:
Am 14.12.20 um 13:57 schrieb Gene Heskett:
1. take your Replyto: back out of your headers so I can reply to the
list. To reply to the list I have to do a reply all, then swap the
To: and
Am 14.12.20 um 22:13 schrieb Nathan Stratton Treadway:
So, what's on line 135 of the bak-indices-configs script?
That is a very long if else fi thing, wordwrap off:
---
if [ $PARTS_WRITTEN -gt 0 ]; then
if [ $DUMMY -eq 1 ] ; then
Seems like
On Mon, Dec 14, 2020 at 14:04:40 -0500, Gene Heskett wrote:
> On Monday 14 December 2020 11:32:56 Nathan Stratton Treadway wrote:
>
> > On Sun, Dec 13, 2020 at 03:05:16 -0500, Gene Heskett wrote:
> > > ./bak-indices-configs: line 135: [: -gt: unary operator expected
> >
> > There does seem to be
On Monday 14 December 2020 09:51:20 Stefan G. Weichinger wrote:
> Am 14.12.20 um 13:57 schrieb Gene Heskett:
> > 1. take your Replyto: back out of your headers so I can reply to the
> > list. To reply to the list I have to do a reply all, then swap the
> > To: and CC: lines in kmail. Or just
On Monday 14 December 2020 11:32:56 Nathan Stratton Treadway wrote:
> On Sun, Dec 13, 2020 at 03:05:16 -0500, Gene Heskett wrote:
> > ./bak-indices-configs: line 135: [: -gt: unary operator expected
>
> There does seem to be an error message coming from the amstatus
> program which we can
On Sun, Dec 13, 2020 at 03:05:16 -0500, Gene Heskett wrote:
> ./bak-indices-configs: line 135: [: -gt: unary operator expected
There does seem to be an error message coming from the amstatus program
which we can investigate later, but as far as your own script not doing
the coping I think that
Am 14.12.20 um 13:57 schrieb Gene Heskett:
1. take your Replyto: back out of your headers so I can reply to the
list. To reply to the list I have to do a reply all, then swap the To:
and CC: lines in kmail. Or just delete your .at address, so only the
list gets a copy.
Oh. Sorry. Better now?
On Monday 14 December 2020 04:12:02 Stefan G. Weichinger wrote:
> Am 13.12.20 um 09:05 schrieb Gene Heskett:
> > amstatus: bad status on taper SHM-WRITE (dumper): 20
> > at /usr/local/share/perl/5.24.1/Amanda/Status.pm line 918, <$fd>
> > line 3142.
> >
> > Parts written = >> dd.report.Dailys-17
Am 13.12.20 um 09:05 schrieb Gene Heskett:
amstatus: bad status on taper SHM-WRITE (dumper): 20
at /usr/local/share/perl/5.24.1/Amanda/Status.pm line 918, <$fd> line
3142.
Parts written = >> dd.report.Dailys-17
./bak-indices-configs: line 135: [: -gt: unary operator expected
Aside from
On Friday 04 December 2020 02:52:41 Stefan G. Weichinger wrote:
> Am 03.12.20 um 19:22 schrieb Debra S Baddorf:
> > I recall something about “the decompress is done where the compress
> > was done” and also “now all decompression happens on the server.”
> >
> > It might be worth making the same
Am 03.12.20 um 19:22 schrieb Debra S Baddorf:
I recall something about “the decompress is done where the compress was done”
and also “now all decompression happens on the server.”
It might be worth making the same wrapper be in place on both the client and
the server?
(couldn’t hurt)
Good
> On Dec 3, 2020, at 1:46 AM, Stefan G. Weichinger wrote:
>
>
> Am 01.12.20 um 13:44 schrieb Stefan G. Weichinger:
>
>> With the simple wrapper in place amrecover correctly runs through (*and*
>> pigz is used for the amdump and the amrecover step).
>> Tomorrow, when the admin there will
On Thu, Dec 03, 2020 at 16:58:34 +0100, Stefan G. Weichinger wrote:
> Ah, I forgot that. I have "-p4".
> Will retry asap. Thanks for the reminder.
You mean you currently have an explicit "-p4" on the command line
contained in the wrapper script?
If -p1 does work, it would be interesting to know
Am 03.12.20 um 15:08 schrieb Nathan Stratton Treadway:
On Thu, Dec 03, 2020 at 08:46:00 +0100, Stefan G. Weichinger wrote:
Am 01.12.20 um 13:44 schrieb Stefan G. Weichinger:
With the simple wrapper in place amrecover correctly runs through
(*and* pigz is used for the amdump and the amrecover
On Thu, Dec 03, 2020 at 08:46:00 +0100, Stefan G. Weichinger wrote:
>
> Am 01.12.20 um 13:44 schrieb Stefan G. Weichinger:
>
> >With the simple wrapper in place amrecover correctly runs through
> >(*and* pigz is used for the amdump and the amrecover step).
> >
> >Tomorrow, when the admin there
Am 01.12.20 um 13:44 schrieb Stefan G. Weichinger:
With the simple wrapper in place amrecover correctly runs through (*and*
pigz is used for the amdump and the amrecover step).
Tomorrow, when the admin there will insert a specific tape for me, I
will test that from the tape I used for the
Am 01.12.20 um 09:41 schrieb Stefan G. Weichinger:
Am 01.12.20 um 01:27 schrieb Nathan Stratton Treadway:
Off hand I can't really say why that would the case, but one theory that
comes to mind is the fact that gzip normally doesn't spawn it's own
subprocesses but pigz does. A way to test that
Am 01.12.20 um 01:27 schrieb Nathan Stratton Treadway:
On Mon, Nov 30, 2020 at 15:35:36 +0100, Stefan G. Weichinger wrote:
Am 30.11.20 um 00:40 schrieb Nathan Stratton Treadway:
https://github.com/madler/pigz/issues/80
As I mentioned before I'm not familiar with pigz myself, but skimming
On Mon, Nov 30, 2020 at 15:35:36 +0100, Stefan G. Weichinger wrote:
> Am 30.11.20 um 00:40 schrieb Nathan Stratton Treadway:
> https://github.com/madler/pigz/issues/80
As I mentioned before I'm not familiar with pigz myself, but skimming
through those Github issues (76 and 80), I would guess that
Am 30.11.20 um 00:40 schrieb Nathan Stratton Treadway:
On Thu, Nov 26, 2020 at 11:12:45 +0100, Stefan G. Weichinger wrote:
I was able to amrestore correctly .. no "-r", no skipping.
(Did you try this while the real pigz binary was in place, or only after
you replaced it with "gzip"?)
I
On Thu, Nov 26, 2020 at 11:12:45 +0100, Stefan G. Weichinger wrote:
> Am 25.11.20 um 22:39 schrieb Debra S Baddorf:
>
> >>the theory is good, sure. I will test the restore aside from amrecover
> >>tomorrow.
> >
> >
> >If so, remember to ???throw out??? the first block of the file, which will
>
On Thu, Nov 26, 2020 at 11:25:40 +0100, Stefan G. Weichinger wrote:
> Am 25.11.20 um 20:57 schrieb Nathan Stratton Treadway:
> >On Wed, Nov 25, 2020 at 14:34:17 -0500, Nathan Stratton Treadway wrote:
> >>Also, do you see the same defunct pigz process that Jason reported in
> >>his original post?
>
> Stefan G Weichinger writes:
> I hit this pigz issue as well today.
> Did you solve this?
I never have. For what I've been doing, it's worked to simply Ctrl-C at
that point since the files I need have been restored. But I imagine
that doesn't work in all situations.
- J<
Am 26.11.20 um 11:25 schrieb Stefan G. Weichinger:
Then test with that patched binary.
Managed to build and use that beta binary.
Rerun of same amrecover run now.
Now the "trailing junk" message does not show up, but things seem to
hang anyway.
It doesn't get to the 2nd tape ...
I seed
Am 25.11.20 um 20:57 schrieb Nathan Stratton Treadway:
On Wed, Nov 25, 2020 at 14:34:17 -0500, Nathan Stratton Treadway wrote:
Also, do you see the same defunct pigz process that Jason reported in
his original post?
Am 30.05.18 um 20:21 schrieb Jason L Tibbitts III:
root 2690 9.1 0.0
Am 25.11.20 um 22:39 schrieb Debra S Baddorf:
the theory is good, sure. I will test the restore aside from amrecover
tomorrow.
If so, remember to “throw out” the first block of the file, which will choke
the zip program.
dd-skip=1 etc
I was able to amrestore correctly .. no "-r",
Am 25.11.20 um 22:39 schrieb Debra S Baddorf:
>> short reply, as it is late here already:
>>
>> the theory is good, sure. I will test the restore aside from amrecover
>> tomorrow.
>
>
> If so, remember to “throw out” the first block of the file, which will choke
> the zip program.
> dd
> On Nov 25, 2020, at 3:30 PM, Stefan G. Weichinger wrote:
>
> Am 25.11.20 um 20:57 schrieb Nathan Stratton Treadway:
>> On Wed, Nov 25, 2020 at 14:34:17 -0500, Nathan Stratton Treadway wrote:
>>> Also, do you see the same defunct pigz process that Jason reported in
>>> his original post?
>>
Am 25.11.20 um 20:57 schrieb Nathan Stratton Treadway:
> On Wed, Nov 25, 2020 at 14:34:17 -0500, Nathan Stratton Treadway wrote:
>> Also, do you see the same defunct pigz process that Jason reported in
>> his original post?
>
> Am 30.05.18 um 20:21 schrieb Jason L Tibbitts III:
>> root 2690
On Wed, Nov 25, 2020 at 14:34:17 -0500, Nathan Stratton Treadway wrote:
> Also, do you see the same defunct pigz process that Jason reported in
> his original post?
Am 30.05.18 um 20:21 schrieb Jason L Tibbitts III:
> root 2690 9.1 0.0 317692 11020 pts/0S+ 12:38 1:43 |
On Wed, Nov 25, 2020 at 20:07:23 +0100, Stefan G. Weichinger wrote:
> So maybe pigz needs some additional option at decompression, or some
> fix, or amanda needs some patch to correctly handle the behavior or pigz
> in the process.
>
> I *know* I could use amrestore. But amrecover should work,
Am 25.11.20 um 19:32 schrieb Charles Curley:
> I vaguely recall that the problems I had with pigz were at compression
> time. If so, and if your problem was also at compression time, you may
> be SOL.
I assume no: my current recovery *test* (fortunately no emergency) tries
to restore a level 1
On Wed, 25 Nov 2020 18:44:10 +0100
"Stefan G. Weichinger" wrote:
> Tried it.
>
> Does not work to only edit that dumptype, amrecover seems to read the
> meta-info/header of the dump on tape.
>
> Same failure.
Drat.
>
> I'd also prefer to benefit of the parallelity of pigz at compression
>
Am 25.11.20 um 18:37 schrieb Stefan G. Weichinger:
> Am 25.11.20 um 18:26 schrieb Charles Curley:
>> On Wed, 25 Nov 2020 18:06:09 +0100
>> "Stefan G. Weichinger" wrote:
>>
>>> Am 30.05.18 um 20:21 schrieb Jason L Tibbitts III:
>>
>> ...
>>
[... time passes and I see a byte count
Am 25.11.20 um 18:26 schrieb Charles Curley:
> On Wed, 25 Nov 2020 18:06:09 +0100
> "Stefan G. Weichinger" wrote:
>
>> Am 30.05.18 um 20:21 schrieb Jason L Tibbitts III:
>
> ...
>
>>>
>>> [... time passes and I see a byte count increasing ...]
>>>
>>> /usr/bin/pigz: pigz: warning: : trailing
On Wed, 25 Nov 2020 18:06:09 +0100
"Stefan G. Weichinger" wrote:
> Am 30.05.18 um 20:21 schrieb Jason L Tibbitts III:
...
> >
> > [... time passes and I see a byte count increasing ...]
> >
> > /usr/bin/pigz: pigz: warning: : trailing junk was ignored
> > ```
> >
I've had problems with
Am 30.05.18 um 20:21 schrieb Jason L Tibbitts III:
I'm trying to understand what's supposed to happen when amrecover gets
to the end of the backup. Currently I'm running amanda 3.5.1 as
packaged by Fedora. (We only lightly patch it, and as far as I can tell
none of the patches should be
I'm trying to understand what's supposed to happen when amrecover gets
to the end of the backup. Currently I'm running amanda 3.5.1 as
packaged by Fedora. (We only lightly patch it, and as far as I can tell
none of the patches should be relevant to amrecover.)
Basically, I do a simple recovery
I'm not finding my precise problem in logs of other fixes, so :
amrecover hangs after one answers the set owner/mode? question.
It HAS actually done the restore (as long as it wasn't planning to want a
second tape).
The amrecover.debug file ends in
gzip: stdout: broken pipe
If it's
So looking into some logs I see a problem that looks like its whats causing everything to break.
Inside of the log amidxtaped.20040804140128.debug, I am seeing some gzip errors. I have included a snippet of the log below which includes the error towards the bottom. Anyone know whats going on!?
--On Wednesday, August 04, 2004 15:06:13 -0700 Kris Vassallo [EMAIL PROTECTED] wrote:
So looking into some logs I see a problem that looks like its whats
causing everything to break.
Inside of the log amidxtaped.20040804140128.debug, I am seeing some gzip
errors. I have included a snippet of
Ok, well I found the problem.. the broken pipe in the log file was me ctrl-c ing amrecover because it was taking way too long. What I found out was happening was that my actual backup file on the tape was 144 GB, so tar was taking forever to go through the tar file to find the actual file
I am still trying to get amrecover to work, but now I have a different issue which is that amrecover is hanging. I am recovering files on the client which is the same machine as the server and I am using a disk-tar backup. Here is what I typed in...
amrecover add .bash_profile
Added
91 matches
Mail list logo
