On Mon, Nov 12, 2018 at 1:50 PM Nathan Stratton Treadway <[email protected]>
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 was missing backups from it. If I had been paying attention to the
> > nightly reports, I would have investigated it sooner. However, it does
> beg
> > the question: That DLE is NOT 49 years overdue... So where in the world
> did
> > the planner get that idea from?
>
> Again, that 1969 date is the "no data saved" timestamp. You can see
> this mostly-directly by doing "amadmin campus info [HOST] [DEV]" on that
> DLE... or completely-directly by looking at the
> .../campus/curinfo/[HOST]/[DEV]/info
> file (where the "seconds since the epoch" timestamp will show up as "-1"
> instead of a number in the range around 1542048289).
>
>
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: 66.9%, 67.4%, 67.8%
Incremental: 71.3%, 68.0%, 67.4%
Dumps: lev datestmp tape file origK compK secs
0 19691231 0 -1 -1 -1
That timestamp is a bit odd, but...
(I don't know off hand why Amanada would have saved a "no data recorded"
> status rather than still having a record of the last time ZWC ran
> sucessfully -- perhaps the last successful dump went to a volume that
> has since been overwritten, and so the entry had to be deleted from the
> info database without anything new replacing it?)
>
>
This makes the most sense. This client has been offline for two cycles.
Chris
