I'm writing this with tears in my eyes,my family and I came down here
to England for a short vacation and i was mugged at gun point last
night at the park of the hotel where we lodged,all cash and credit
card were stolen off us but luckily for us we still have our passports
with us.
I've been to
mezzie wrote:
Mon Oct 4 09:18:28 2010: amidxtaped: critical (fatal): '[sec -1.00 kb 32
kps -32.00 orig-kb 1290]' at
/usr/lib/perl5/site_perl/5.8.8/Amanda/DB/Catalog.pm line 677
The value of '-1' show that something is corrupted, the backup image is
probably not valid, that's why you
On Tue, Oct 5, 2010 at 9:29 AM, Jean-Louis Martineau
martin...@zmanda.com wrote:
The value of '-1' show that something is corrupted, the backup image is
probably not valid, that's why you can't restore it.
Can you post the complete log.timestatmp.0, the amdump.? log file and the
dumper.*.debug
Hi again,
Thanks for the replies. I am not sure how to attach a file here but here's a
link to the file.
http://www.mediafire.com/?3abb5pekl4ete95
The logs here are on a different date than the original post but I have
verified that it is still happening for the files attached.
Thanks!
This is exciting, I am very much interested in amvault. We are currently using
3.1.2 and was not aware of amvault when I wrote our offsite backup using
amanda. I will try this out.
+--
|This was sent by richard.t@gmail.com
On Tue, Oct 5, 2010 at 11:39 AM, mezzie amanda-fo...@backupcentral.com wrote:
The logs here are on a different date than the original post but I have
verified that it is still happening for the files attached.
So it looks like mvsu.edu:/home/tk20/fileshighered is a problematic DLE.
Looking at
Thank you! I will let you know if this problem persist tomorrow. I have
reverted my setting to not use bzip2.
+--
|This was sent by richard.t@gmail.com via Backup Central.
|Forward SPAM to ab...@backupcentral.com.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The Amanda development team has discovered a security vulnerability
introduced
in Amanda-3.1.2. The vulnerability affects both Amanda servers and
clients,
and could lead to remote execution of code as the Amanda user.
The problem is fixed in
Over the last several nights I have gotten the following amdump error.
The next 4 tapes Amanda expects to use are: D01013, D01014, D01015, D01016.
FAILURE DUMP SUMMARY:
hertz /gauss/export/users-s lev 0 FAILED [too many taper retries]
hertz /gauss/export/users-s lev 0 partial taper: Error
We're planning another beta tomorrow, so if you have anything you'd
like to see fixed in that beta, let me know ASAP. That includes
manpage typos and other actual nitpicks :)
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
On Tue, Oct 5, 2010 at 1:33 PM, McGraw, Robert P rmcg...@purdue.edu wrote:
hertz /gauss/export/users-s lev 0 partial taper: Error writing block:
Mysterious short write on tape device: Tried 2097152, got 1052672
as amanda hit the end of tape.
.. and you're using a block size (2M) that's
On Mon, 4 Oct 2010 22:58:29 -0500
Dustin J. Mitchell dus...@zmanda.com wrote:
On Mon, Oct 4, 2010 at 10:30 PM, Charles Curley
charlescur...@charlescurley.com wrote:
I plan to go back to tcp and auth=bsdtcp once I get this issue
solved. Of course it could be that making those changes will
On Tue, Oct 5, 2010 at 5:01 PM, Charles Curley
charlescur...@charlescurley.com wrote:
Done. I also upgraded to amanda-3.2.0beta1.svn.3489.tar.gz, per today's
announcement. I just ran 15 amchecks in a row, then an amdump, and no
problems.
Great!
I should be clear - and I'll reiterate in
13 matches
Mail list logo
