hi all,
I am having problem with amrecover..
amrecover DailySet1
AMRECOVER Version 2.5.1p3. Contacting server on server.com ...
[request failed: timeout waiting for ACK]
the amrecover debug file was:
amrecover: debug 1 pid 12565 ruid 0 euid 0: start at Tue Oct 30 16:35:10
2007
Reading conf
this is the logs on dumper on server:
dumper: connect_portrange: connect from 0.0.0.0.5 failed: Connection
timed out
dumper: connect_portrange: connect to 202.53.250.159.37782 failed:
Connection timed out
dumper: stream_client: Could not bind to port in range 5 - 50100.
dumper:
I'm a long-time Amanda user, currently 2.5.1, under Mandriva 2007, and
regularly perform backups; but have not needed to recover data for some
while. Now I do :(
I'm sure amrecover used to work, but may not have done since I upgraded to
2.5.1. Anyway:
[EMAIL PROTECTED] recover]# amrecover
This bug is fixed in 2.5.3alpha, but the patch was not backported to
2.5.2p1.
Can you try the attached patch?
Jean-Louis
Jean-Francois Malouin wrote:
Hi,
With amanda-2.5.2p1 I did an archive a few days ago and trying to
restore it caused me a few problems: amfetchdump tells me that
there is
On another backup list I monitor, there was an instance of someone who
had their system change time on October 28th. Two issues came out of
this. One is that they may have failed to patch their system for the
2007 statutory changes in daylight savings time (it should change on
Nov. 4th for
Tony van der Hoff wrote:
I'm a long-time Amanda user, currently 2.5.1, under Mandriva 2007, and
regularly perform backups; but have not needed to recover data for some
while. Now I do :(
I'm sure amrecover used to work, but may not have done since I upgraded to
2.5.1. Anyway:
[EMAIL
On Tue, Oct 30, 2007 at 12:21:32PM -0400, Chris Hoogendyk wrote:
Daylight Savings time laws changed affective Spring 2007 in the U.S. and
Australia. I don't know what the situation is for other countries. There
were patches to be applied according to your operating system. I applied
Actually, the time period to avoid is Sunday morning from 0100 to 0300, since
you will get hit as described below, except that the period of Fall danger is
from 0100 to 0200 (all of these entries will get run twice). Fall DST causes
the clocks to reset at 0200 back to 0100, so that period gets
You're absolutely right for the jurisdictions and time zones we are
familiar with. And I like your idea of commenting the crontab.
I think my note got tangled in the original post on the other list where
the person posting was from the Czech Republic. They switched at 3:00am
on October 28th,
Amanda users,
I may have missed it in the mailing list... I know that
encryption came available in 2.5.0, either server side
or client side, or the channel (though I think encrypting
on the client provides an encrypted channel by default, true ?)
Anyway, I was wondering and haven't seen... how
Brian Cuttler wrote:
Amanda users,
I may have missed it in the mailing list... I know that
encryption came available in 2.5.0, either server side
or client side, or the channel (though I think encrypting
on the client provides an encrypted channel by default, true ?)
Anyway, I was wondering
In my (admittedly limited) experience with encryption and compression, the rule
of thumb has always been to compress first (removing exploitable redundancy and
pattern repetitions) and then encrypt. It also has the advantage that you are
encrypting less volume and reducing the exploitable
Good crypto will produce relatively random output data. Compressing prior
to encrypting if storing encrypted is typically a must.
--On October 30, 2007 6:06:09 PM -0500 [EMAIL PROTECTED] wrote:
In my (admittedly limited) experience with encryption and compression,
the rule of thumb has
BACKGROUND INFO: I have Amanda 2.5.2p1 running on Ubuntu linux 6.10,
configured to backup several large (300Gb +) filesystems spanning
several tapes. I have a robot changer, LTO1 tapes (100Gb capacity) and
I used:
tape_splitsize 3Gb
fallback_splitsize 256m
(An unrelated issue: I
14 matches
Mail list logo
