Re: Community ZWC Issue

[Chris Nighswonger]

Well, at this point, given the near zero "community" support for the
"community" edition of ZWC, I'm going to move away from it for my M$
systems and utilize Windows 10's backup utility to push client backups to
my file server and let Amanda pick them up from there. I'm really not
concerned about bare metal capabilities with the M$ clients. Since ZWC and
the OS backup utility both rely on VSS, I'm pretty much getting the same
thing AFAICT.

On Tue, Mar 27, 2018 at 3:43 PM, Chris Nighswonger <
cnighswon...@foundations.edu> wrote:

> Yes. Here is a DLE from my dislist:
>
> admin-asst-1.foo.bar "C:/Documents and Settings" {
>   zwc-compress
>   estimate server
>   exclude "C:\\Documents and Settings\\*\\Local Settings\\Temp"
>
> }
>
>
> On Tue, Mar 27, 2018 at 1:20 PM, Paddy Sreenivasan <
> paddy.sreeniva...@gmail.com> wrote:
>
>> Have you configured the DLE the same way i.e, using scriptor.foo.bar as
>> hostname in both cases?
>>
>> On Tue, Mar 27, 2018 at 3:05 AM, Chris Nighswonger <
>> cnighswon...@foundations.edu> wrote:
>>
>>> Has Zamanda abandoned ZWC?
>>>
>>> On Thu, Mar 22, 2018, 9:09 AM Chris Nighswonger <
>>> cnighswon...@foundations.edu> wrote:
>>>
 Ping.


 On Sun, Mar 18, 2018 at 1:34 PM, Chris Nighswonger <
 cnighswon...@foundations.edu> wrote:

> No takers? To be sure someone who works on the ZWC can comment on what
> sorts of issues might cause this change in behavior.
>
> Kind regards,
>
> Chris
>
> On Mar 14, 2018 3:24 PM, "Chris Nighswonger" <
> cnighswon...@foundations.edu> wrote:
>
>> Thanks Paddy. I also had to restart the ZWC service to make the log
>> level change effective.
>>
>> So maybe someone who works on the ZWC code can explain what operation
>> might account for the following differences in log entries. Both are from
>> the same machine. The backup began failing with the 18/1/2018 run. I 
>> wonder
>> if ZWC is doing some sort of name resolution here which suddenly began to
>> fail? On the client, nslookup results are correct both ways (see below).
>> This same failure occurs on all of my ZWC installs.
>>
>> ZWC working fine:
>>
>> 4424:384:17/1/2018:12:59:36:548::CZWCJobHandler : Entering
>> ExecuteValidateServerJob
>> 4424:384:17/1/2018:12:59:36:548::CZWCJobHandler : Server address to
>> be validated from the list of authentic server = 192.168.x.x
>> 4424:384:17/1/2018:12:59:36:548::CZWCJobHandler : Server name =
>> scriptor.foo.bar
>> 4424:384:17/1/2018:12:59:36:548::CZWCJobHandler : Authentic Server
>> name = scriptor.foo.bar
>> 4424:384:17/1/2018:12:59:36:548::CZWCJobHandler : Leaving
>> ExecuteValidateServerJob
>>
>> ZWC borking:
>>
>> 5692:12004:14/3/2018:14:54:9:706::CZWCJobHandler : Entering
>> ExecuteValidateServerJob
>> 5692:12004:14/3/2018:14:54:9:706::CZWCJobHandler : Server address to
>> be validated from the list of authentic server = 192.168.x.x
>> 5692:12004:14/3/2018:14:54:9:706::CZWCJobHandler : Server name =
>> 192.168.x.x
>> 5692:12004:14/3/2018:14:54:9:706::CZWCJobHandler : Authentic Server
>> name = scriptor.foo.bar
>> 5692:12004:14/3/2018:14:54:9:706::CZWCJobHandler : Server Validation
>> Failed - Server 192.168.x.x With IP 192.168.x.x is not registered
>> 5692:12004:14/3/2018:14:54:9:706::CZWCJobHandler : Leaving
>> ExecuteValidateServerJob
>> 5692:12004:14/3/2018:14:54:9:706::CZWCJobHandler:: Exiting
>> ExecuteJob with status = 65535
>>
>> Client-side nslookup:
>>
>> PS C:\Program Files\Zmanda\Zmanda Client for Windows Community
>> Edition(x64)\bin> nslookup 192.168.x.x
>> Server:  UnKnown
>> Address:  192.168.y.y
>>
>> Name:scriptor.foo.bar
>> Address:  192.168.x.x
>>
>> PS C:\Program Files\Zmanda\Zmanda Client for Windows Community
>> Edition(x64)\bin> nslookup scriptor.foo.bar
>> Server:  UnKnown
>> Address:  192.168.x.x
>>
>> Name:scriptor.foo.bar
>> Address:  192.168.x.x
>>
>> PS C:\Program Files\Zmanda\Zmanda Client for Windows Community
>> Edition(x64)\bin>
>>
>> Kind regards,
>> Chris
>>
>>
>> On Fri, Mar 9, 2018 at 10:46 AM, Paddy Sreenivasan <
>> paddy.sreeniva...@gmail.com> wrote:
>>
>>>
>>>1. Open the ZWC Config Utility: Start Menu → All Programs →
>>>Zmanda → Zmanda Client for Windows → ZWC Config Utility
>>>2. Select the Logging tab
>>>3. Set Log Level to 5
>>>4. Click Save
>>>5. Click Exit
>>>
>>>
>>>
>>> On Fri, Mar 9, 2018 at 5:59 AM, Chris Nighswonger <
>>> cnighswon...@foundations.edu> wrote:
>>>
 Jean-Louis can you help with this? Is there a way to up the
 verbosity level of the ZWC log?


 On Tue, Feb 27, 2018 at 10:43 AM, Chris Nighswonger <
 

Re: odd cleanup after spontaneous system reboot

[Debra S Baddorf]

> On Mar 30, 2018, at 12:52 PM, Chris Hoogendyk  wrote:
> 
> My Amanda server spontaneously rebooted at 1:09am this morning. After 
> checking services, one of the first things I did was to check up on Amanda, 
> which should have been running at that hour. Since the system rebooted, there 
> are no /tmp debug files. However, the holding disk has stuff that was being 
> backed up – not much, since I have fast LTO7 tapes that it gets pushed out to.
> 
> I did an `amcheck daily`, which in older versions would tell me I needed to 
> run amcleanup (I'm running Amanda 3.4.5 on Ubuntu 14.04 Server LTS). That 
> told me that there were 0 problems found. Then I ran `amcleanup daily`, 
> expecting it to spawn off and send an email report. Instead, I got:
> 
>   amcleanup: no unprocessed logfile to clean up
>   amcleanup: /usr/local/etc/amanda/daily/log/amdump exists, renaming it
>   amcleanup: /usr/local/sbin/amcleanupdisk stderr: amcleanupdisk: Invalid 
> header type: -2 (UNKNOWN)
> 
> What do you make of this? What should I do, aside from just proceeding with 
> ongoing backups?
> 
> It seems I will have no records of what did get backed up last night before 
> the reboot. It should have been substantial, since backups started around 
> 10:30pm last night.
> 
> 
> -- 
> ---
> 
> Chris Hoogendyk
> 
> -
>   O__   Systems Administrator
>  c/ /'_ --- Biology & Geosciences Departments
> (*) \(*) -- 315 Morrill Science Center
> ~~ - University of Massachusetts, Amherst
> 
> 
> 

Since there was an amdump file,  there is probably a log.* file too.   Go to 
that directory,  and try an
“amtoc”  to see what files it already dumped to tape/vtape.
I like to configure the command   “   amtoc  -i -t -a  ./log.yyymmnn  “  
but there are a number of flags
available for the command.

Deb Baddorf
Fermilab