9 nov 2010 kl. 12.33 skrev Jean-Louis Martineau:
> What's the time difference between the first and last line in the
> amandad.debug file?
> Is it bigger than your etimeout setting? If so, increase etimeout
Tnx.
Format seems to be
seconds.milliseconds message
and diff between last and first line is 6522 seconds, which seems like a too
long time to wait for a estimate value.
How do I dryrun this, i e running a gtar with the same flags, to compute the
size of a backup?
/Klas
>
> Jean-Louis
>
> Klas Heggemann wrote:
>> Hi list.
>>
>> We're trying backup snapshots of some zfs filesystems on a OpenSolaris host.
>> Client is running amanda 2.6.1p2, server is running 2.5.3 (with some
>> kerberos fixes added) on a Solaris 10.
>>
>> Backup of this client is via ssh and keys. The client is not build with
>> kerberos.
>> Backup is with gnutar (/Usr/sfw/bin/gtar). ssh is Solaris ssh. No firewalls
>> are involved.
>>
>>
>> However the client fails o communicate with the server. It seems to
>> calculate the size right.
>> This is from the amandad.debug file:
>>
>> OPTIONS features=ffffffff9ffeffffffff7f;
>> /.zfs/snapshot/daily.0 1 SIZE 39529810
>> /.zfs/snapshot/daily.0 2 SIZE 39529810
>> /opt/.zfs/snapshot/daily.0 1 SIZE 3968010
>> /opt/.zfs/snapshot/daily.0 2 SIZE 3968010
>> /sandbox/.zfs/snapshot/daily.0 1 SIZE 10
>> /sandbox/.zfs/snapshot/daily.0 2 SIZE 10
>> /sandbox/klas/.zfs/snapshot/daily.0 1 SIZE 71922300
>> /sandbox/klas/.zfs/snapshot/daily.0 2 SIZE 71922300
>> /sandbox/klas2/.zfs/snapshot/daily.0 1 SIZE 38611950
>> 1289263081.214946: amandad: security_stream_seterr(8074e80, write error to:
>> Bad file number)
>> 1289263081.214961: amandad: security_seterror(handle=8074d30,
>> driver=fef3a688 (SSH) error=write error to: Bad file number)
>> 1289263137.443175: amandad: sending PREP pkt:
>> <<<<<
>>
>>
>> (I notice that last fs is not repeated like the other ones are.)
>> The server will log:
>>
>>
>> client /sandbox/klas2/.zfs/snapshot/daily.0
>> lev 0 FAILED [disk /sandbox/klas2/.zfs/snapshot/daily.0, all
>> estimate timed out]
>> client /sandbox/klas/.zfs/snapshot/daily.0
>> lev 0 FAILED [disk /sandbox/klas/.zfs/snapshot/daily.0, all
>> estimate timed out]
>> client /sandbox/.zfs/snapshot/daily.0
>> lev 0 FAILED [disk /sandbox/.zfs/snapshot/daily.0, all estimate
>> timed out]
>> client /opt/.zfs/snapshot/daily.0
>> lev 0 FAILED [disk /opt/.zfs/snapshot/daily.0, all estimate timed
>> out]
>> client /.zfs/snapshot/daily.0
>> lev 0 FAILED [disk /.zfs/snapshot/daily.0, all estimate timed out]
>>
>>
>> I guess something is broken in the ssh communication between server and
>> client.
>> Has anyone seen anything like this before and have some idea about what is
>> going wrong? Could it be real timeouts when calculations take more time then
>> expected?
>>
>>
>>
>> Klas Heggemann
>> sys adm at csc kth .se
>>
>>
>>
>>
>
