On Mon, Nov 12, 2018 at 13:56:33 -0500, Chris Nighswonger wrote:
> backup@scriptor:~ amadmin campus info host dev
>
> Current info for host dev:
> Stats: dump rates (kps), Full: 6015.9, 5898.2, 5771.4
> Incremental: 1658.2, 1456.6, 343.4
> compressed size, Full:
On Mon, Nov 12, 2018 at 1:50 PM Nathan Stratton Treadway
wrote:
> On Mon, Nov 12, 2018 at 13:28:15 -0500, Chris Nighswonger wrote:
> > I found the long overdue culprit... It was a windows client using the ZWC
> > community client. The ZWC service had hung (not an uncommon problem) and
> > Amanda
On Mon, Nov 12, 2018 at 13:28:15 -0500, Chris Nighswonger wrote:
> On Sat, Nov 10, 2018 at 5:03 PM Nathan Stratton Treadway
> wrote:
>
> > On Sat, Nov 10, 2018 at 11:39:58 -0500, Chris Nighswonger wrote:
> > > (3 filesystems overdue. The most being overdue 17841 days.)
> > >
> > > Not sure
On Sat, Nov 10, 2018 at 5:03 PM Nathan Stratton Treadway
wrote:
> On Sat, Nov 10, 2018 at 11:39:58 -0500, Chris Nighswonger wrote:
> > (3 filesystems overdue. The most being overdue 17841 days.)
> >
> > Not sure what's up with the overdues. There were none prior to breaking
> up
> > the DLEs.
On Sunday 11 November 2018 15:36:52 Nathan Stratton Treadway wrote:
> On Sun, Nov 11, 2018 at 05:25:29 -0500, Gene Heskett wrote:
> > > > amanda@coyote:/amandatapes/Dailys/data$ /usr/local/sbin/amadmin
> > > > Daily balance
> > > >
> > > > due-date #fsorig MB out MB balance
> > > >
On Sun, Nov 11, 2018 at 05:25:29 -0500, Gene Heskett wrote:
> > > amanda@coyote:/amandatapes/Dailys/data$ /usr/local/sbin/amadmin
> > > Daily balance
> > >
> > > due-date #fsorig MB out MB balance
> > > --
> > > 11/10 Sat1 7912
On Saturday 10 November 2018 13:55:30 Nathan Stratton Treadway wrote:
[...]
> > > > due-date #fsorig MB out MB balance
> > > > --
> > > > 10/30 Tue5 0 0 ---
> > > > 10/31 Wed1 17355 8958-45.3%
>
On Sat, Nov 10, 2018 at 11:39:58 -0500, Chris Nighswonger wrote:
> I think that is output from one of Gene's systems, but here is the latest
> from mine after DLE balancing has been through one successful run. (The
> next run will take place Monday morning @ 0200).
>
> backup@scriptor:~ amadmin
On Saturday 10 November 2018 13:55:30 Nathan Stratton Treadway wrote:
> On Sat, Nov 10, 2018 at 12:48:15 -0500, Gene Heskett wrote:
> > On Saturday 10 November 2018 10:47:03 Nathan Stratton Treadway wrote:
> > > On Tue, Oct 30, 2018 at 15:51:36 -0400, Gene Heskett wrote:
> > > > I just changed
On Sat, Nov 10, 2018 at 12:48:15 -0500, Gene Heskett wrote:
> On Saturday 10 November 2018 10:47:03 Nathan Stratton Treadway wrote:
>
> > On Tue, Oct 30, 2018 at 15:51:36 -0400, Gene Heskett wrote:
> > > I just changed the length of the dumpcycle and runs percycle up to
> > > 10, about last
On Saturday 10 November 2018 10:47:03 Nathan Stratton Treadway wrote:
> On Tue, Oct 30, 2018 at 15:51:36 -0400, Gene Heskett wrote:
> > I just changed the length of the dumpcycle and runs percycle up to
> > 10, about last friday while I was makeing the bump* stuff more
> > attractive, but the
On Sat, Nov 10, 2018 at 10:57 AM Nathan Stratton Treadway <
natha...@ontko.com> wrote:
> On Tue, Oct 30, 2018 at 15:51:36 -0400, Gene Heskett wrote:
> > I just changed the length of the dumpcycle and runs percycle up to 10,
> > about last friday while I was makeing the bump* stuff more
On Tue, Oct 30, 2018 at 15:51:36 -0400, Gene Heskett wrote:
> I just changed the length of the dumpcycle and runs percycle up to 10,
> about last friday while I was makeing the bump* stuff more attractive,
> but the above command returns that the are 5 filesystens out of date:
> su amanda -c
On Thursday 01 November 2018 09:09:36 Nathan Stratton Treadway wrote:
> On Thu, Nov 01, 2018 at 08:21:55 -0400, Gene Heskett wrote:
> > And an amcheck fusses with 3.3.7p1 reinstalled:
> >
> > amcheck-server: Bogus line in the tapelist file: 20181101030104
> > Dailys-28 reuse BLOCKSIZE:32
On Thursday 01 November 2018 06:53:19 Gene Heskett wrote:
> 3.4.3 is still broken, 3.3.7p1 being installed now.
Because 337p1 squawks about a bogus line in the tapelist, I put 3.5.1
back in.
Someone ask how small it had to be to trigger this bug.
On Thu, Nov 01, 2018 at 08:21:55 -0400, Gene Heskett wrote:
> And an amcheck fusses with 3.3.7p1 reinstalled:
>
> amcheck-server: Bogus line in the tapelist file: 20181101030104 Dailys-28
> reuse BLOCKSIZE:32 POOL:Daily STORAGE:Daily CONFIG:Daily
>
> Should I nuke that line before it runs?
Ah,
On Wed, Oct 31, 2018 at 6:30 PM Debra S Baddorf wrote:
> We may have found an answer for Gene’s problem.
> Has the original poster, Chris Nighswonger found an answer?
>
> Deb
>
>
Indeed! Enough to get me set off in what seems to be a right direction.
Thanks to everyone for the kind assistance.
On Wed, Oct 31, 2018 at 5:32 PM Nathan Stratton Treadway
wrote:
>
> Am I correct that you actually ran two separate amdump runs within the
> calendar day of 10/30 (with the first "balance" command executed between
> the runs)? That would explain why all 39 DLEs are now showing as due on
> the
On Thursday 01 November 2018 06:53:19 Gene Heskett wrote:
> On Thursday 01 November 2018 01:50:31 Gene Heskett wrote:
> > On Wednesday 31 October 2018 22:40:58 Nathan Stratton Treadway wrote:
> > > On Wed, Oct 31, 2018 at 13:26:40 -0400, Gene Heskett wrote:
> > > > That makes more sense than
On Thursday 01 November 2018 01:50:31 Gene Heskett wrote:
> On Wednesday 31 October 2018 22:40:58 Nathan Stratton Treadway wrote:
> > On Wed, Oct 31, 2018 at 13:26:40 -0400, Gene Heskett wrote:
> > > That makes more sense than anything else I've found. Now, I have
> > > 3.3.7p1. 3.4.3, and 3.5.1
On Wednesday 31 October 2018 22:40:58 Nathan Stratton Treadway wrote:
> On Wed, Oct 31, 2018 at 13:26:40 -0400, Gene Heskett wrote:
> > That makes more sense than anything else I've found. Now, I have
> > 3.3.7p1. 3.4.3, and 3.5.1 which I've been running about that long.
> > So lets install 3.4.3
On Wed, Oct 31, 2018 at 13:26:40 -0400, Gene Heskett wrote:
> That makes more sense than anything else I've found. Now, I have 3.3.7p1.
> 3.4.3, and 3.5.1 which I've been running about that long.
> So lets install 3.4.3 for tonight. Building now, apparently had not been
> done before. and on the
On Wednesday 31 October 2018 14:52:46 Debra S Baddorf wrote:
> “ Those datestamps are obviously wrong, should be 20181031 "
>
> The two DLE’s that you showed, with datestamp “wrong”, are among the
> “too small” disks you are talking about. So it seems that the
> datestamp probably isn’t
On Wed, Oct 31, 2018 at 12:07:06 -0400, Gene Heskett wrote:
> root@coyote:/amandatapes/Dailys# ls -l data/
> total 18143556
> -rw--- 1 amanda amanda 32768 Oct 31 03:03 0.Dailys-27
> -rw--- 1 amanda amanda 70603 Oct 31 03:03 1.shop._root.0
> -rw--- 1 amanda amanda
We may have found an answer for Gene’s problem.
Has the original poster, Chris Nighswonger found an answer?
Deb
> On Oct 30, 2018, at 1:32 PM, Debra S Baddorf wrote:
>
> Is this the first backup run for a long while? If so, then they are all DUE,
> so amanda feels it has to schedule them
On Wed, Oct 31, 2018 at 08:25:39AM -0400, Chris Nighswonger wrote:
> So, looking at this more, it may be self-inflicted. Last week I changed
> blocksize to 512k, and began amrmtape and amlabel with the oldest tape
> first and working backward day by day. I run backups 5 nights per week with
> a
On Wed, Oct 31, 2018 at 08:29:08 -0400, Chris Nighswonger wrote:
> FWIW, here is the output of amadmin balance before last nights run and
> again this morning. No overdues, so I guess that's good. I'm not
> experienced enough to make much of the balance percentages, but am now
> wondering if I
On Wed, Oct 31, 2018 at 02:13:27PM -0400, Nathan Stratton Treadway wrote:
> On Wed, Oct 31, 2018 at 14:38:43 +, Jose M Calhariz wrote:
> > I bet this DLEs are very small and that you have done the upgrade of
> > the amand server between 20 and 20+tapecycle ago.
> >
> > There is a bug in
On Wed, Oct 31, 2018 at 18:52:46 +, Debra S Baddorf wrote:
> "Those datestamps are obviously wrong, should be 20181031"
>
> The two DLE's that you showed, with datestamp "wrong", are among the
> "too small" disks you are talking about. So it seems that the
> datestamp probably isn't wrong?
“ Those datestamps are obviously wrong, should be 20181031 "
The two DLE’s that you showed, with datestamp “wrong”, are among the “too small”
disks you are talking about. So it seems that the datestamp probably isn’t
wrong?
These sets are being missed?
(Not completely following, cuz it’s
On Wed, Oct 31, 2018 at 14:38:43 +, Jose M Calhariz wrote:
> I bet this DLEs are very small and that you have done the upgrade of
> the amand server between 20 and 20+tapecycle ago.
>
> There is a bug in recent amanda server that if a DLE is very small it
> will not update properly the
On Wednesday 31 October 2018 10:38:43 Jose M Calhariz wrote:
> On Wed, Oct 31, 2018 at 08:39:43AM -0400, Nathan Stratton Treadway
wrote:
> > On Wed, Oct 31, 2018 at 07:59:02 -0400, Gene Heskett wrote:
> > > yadda yadda. So just where the hell do I look for these?
> > >
On Wednesday 31 October 2018 10:37:11 Nathan Stratton Treadway wrote:
> On Wed, Oct 31, 2018 at 08:50:55 -0400, Gene Heskett wrote:
> > On Wednesday 31 October 2018 08:39:43 Nathan Stratton Treadway wrote:
> > > On Wed, Oct 31, 2018 at 07:59:02 -0400, Gene Heskett wrote:
> > > > yadda yadda. So
On Wed, Oct 31, 2018 at 08:39:43AM -0400, Nathan Stratton Treadway wrote:
> On Wed, Oct 31, 2018 at 07:59:02 -0400, Gene Heskett wrote:
> > yadda yadda. So just where the hell do I look for these?
> > root@coyote:/amandatapes/Dailys# su amanda -c "/usr/local/sbin/amadmin
> > Daily due"|grep
On Wed, Oct 31, 2018 at 08:50:55 -0400, Gene Heskett wrote:
> On Wednesday 31 October 2018 08:39:43 Nathan Stratton Treadway wrote:
>
> > On Wed, Oct 31, 2018 at 07:59:02 -0400, Gene Heskett wrote:
> > > yadda yadda. So just where the hell do I look for these?
> > >
On Wednesday 31 October 2018 08:34:21 Nathan Stratton Treadway wrote:
> On Wed, Oct 31, 2018 at 08:18:47 -0400, Gene Heskett wrote:
> > that link from tapelist.last_write -> 27062 is dead, there is no
> > 27062 file to be found. WTH is that? And how can that be causeing
> > the erroneous amadmin
On Wednesday 31 October 2018 08:39:43 Nathan Stratton Treadway wrote:
> On Wed, Oct 31, 2018 at 07:59:02 -0400, Gene Heskett wrote:
> > yadda yadda. So just where the hell do I look for these?
> > root@coyote:/amandatapes/Dailys# su amanda -c
> > "/usr/local/sbin/amadmin Daily due"|grep Overdue
>
On Wed, Oct 31, 2018 at 07:59:02 -0400, Gene Heskett wrote:
> yadda yadda. So just where the hell do I look for these?
> root@coyote:/amandatapes/Dailys# su amanda -c "/usr/local/sbin/amadmin
> Daily due"|grep Overdue
> Overdue 21 days: shop:/usr/local
> Overdue 21 days: shop:/var/amanda
>
On Wed, Oct 31, 2018 at 08:18:47 -0400, Gene Heskett wrote:
> that link from tapelist.last_write -> 27062 is dead, there is no 27062
> file to be found. WTH is that? And how can that be causeing the
> erroneous amadmin due's.
(You successfully moved your server to Amanda 3.5.x, right?)
The
FWIW, here is the output of amadmin balance before last nights run and
again this morning. No overdues, so I guess that's good. I'm not
experienced enough to make much of the balance percentages, but am now
wondering if I should work at breaking up the large DLEs into smaller
subsets as several
So, looking at this more, it may be self-inflicted. Last week I changed
blocksize to 512k, and began amrmtape and amlabel with the oldest tape
first and working backward day by day. I run backups 5 nights per week with
a cycle of 13 tapes (see below). I would have thought that this would have
On Wednesday 31 October 2018 07:02:53 Nathan Stratton Treadway wrote:
> On Wed, Oct 31, 2018 at 06:32:41 -0400, Gene Heskett wrote:
> > I'll see if I can find the logs, I assume on the clients marked
> > guilty?
>
> Personally I'd probably start with "amstatus" on the server to see if
> it said
On Wednesday 31 October 2018 06:32:41 Gene Heskett wrote:
> On Tuesday 30 October 2018 17:56:33 Gene Heskett wrote:
> > On Tuesday 30 October 2018 16:45:50 Nathan Stratton Treadway wrote:
> > > On Tue, Oct 30, 2018 at 15:51:36 -0400, Gene Heskett wrote:
> > > > I just changed the length of the
On Wed, Oct 31, 2018 at 06:32:41 -0400, Gene Heskett wrote:
> I'll see if I can find the logs, I assume on the clients marked guilty?
Personally I'd probably start with "amstatus" on the server to see if it
said anything about the DLEs in question, then maybe look into the
amdump.1 log file (the
On Tuesday 30 October 2018 17:56:33 Gene Heskett wrote:
> On Tuesday 30 October 2018 16:45:50 Nathan Stratton Treadway wrote:
> > On Tue, Oct 30, 2018 at 15:51:36 -0400, Gene Heskett wrote:
> > > I just changed the length of the dumpcycle and runs percycle up to
> > > 10, about last friday while
On Tuesday 30 October 2018 16:45:50 Nathan Stratton Treadway wrote:
> On Tue, Oct 30, 2018 at 15:51:36 -0400, Gene Heskett wrote:
> > I just changed the length of the dumpcycle and runs percycle up to
> > 10, about last friday while I was makeing the bump* stuff more
> > attractive, but the above
On Tue, Oct 30, 2018 at 16:27:29 -0400, Gene Heskett wrote:
> On Tuesday 30 October 2018 15:31:59 Nathan Stratton Treadway wrote:
>
> > On Tue, Oct 30, 2018 at 15:29:37 -0400, Nathan Stratton Treadway wrote:
> > > On a different track of investigation, the output of "amadmin
> > > CONFIG
On Tue, Oct 30, 2018 at 15:51:36 -0400, Gene Heskett wrote:
> I just changed the length of the dumpcycle and runs percycle up to 10,
> about last friday while I was makeing the bump* stuff more attractive,
> but the above command returns that the are 5 filesystens out of date:
> su amanda -c
On Tuesday 30 October 2018 15:31:59 Nathan Stratton Treadway wrote:
> On Tue, Oct 30, 2018 at 15:29:37 -0400, Nathan Stratton Treadway wrote:
> > On a different track of investigation, the output of "amadmin
> > CONFIG balance" might show something useful (though off hand it
> > seems unlikely
>
On Tuesday 30 October 2018 15:29:37 Nathan Stratton Treadway wrote:
> On Tue, Oct 30, 2018 at 14:20:55 -0400, Chris Nighswonger wrote:
> > Why in the world does Amanda plan level 0 backups for all entries in
> > a DLE for the same run This causes all sorts of problems.
> >
> > Is there any
On Tuesday 30 October 2018 14:32:14 Debra S Baddorf wrote:
> Is this the first backup run for a long while? If so, then they are
> all DUE, so amanda feels it has to schedule them all, now.
>
> Is this the first backup ever? Ditto above.
>
> Did you perhaps run “amadminforce *” which
On Tue, Oct 30, 2018 at 15:29:37 -0400, Nathan Stratton Treadway wrote:
> On a different track of investigation, the output of "amadmin CONFIG
> balance" might show something useful (though off hand it seems unlikely
Also, "amadmin CONFIG due".
On Tue, Oct 30, 2018 at 14:20:55 -0400, Chris Nighswonger wrote:
> Why in the world does Amanda plan level 0 backups for all entries in a DLE
> for the same run This causes all sorts of problems.
>
> Is there any solution for this? I've read some of the creative suggestions,
> but it seems a
On Tuesday 30 October 2018 14:20:55 Chris Nighswonger wrote:
> Why in the world does Amanda plan level 0 backups for all entries in a
> DLE for the same run This causes all sorts of problems.
>
If all dle's are "new", never been backed up by amanda before, this is
normal. Most start out
Is this the first backup run for a long while? If so, then they are all DUE,
so amanda feels it has to schedule them all, now.
Is this the first backup ever? Ditto above.
Did you perhaps run “amadminforce *” which forces a level 0 on
all disks.
Did you specify “strategy noinc”
Why in the world does Amanda plan level 0 backups for all entries in a DLE
for the same run This causes all sorts of problems.
Is there any solution for this? I've read some of the creative suggestions,
but it seems a bunch of trouble.
Kind regards,
Chris
0 19098649k waiting for dumping
56 matches
Mail list logo
