Sad News!!!
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 the Embassy and the Police here but they're not helping issues at all they asked us to wait for 3weeks but we can't wait till then and our flight leaves in few hours from now but we're having problems settling the hotel bills and the hotel manager won't let us leave until we settle the hotel bills,you can speak with him through this number +447024058752 OR +447024032708 we are freaked out at the moment ... Well I really need your financially assistance Please let me know if you can help us out? you can wire the money to me through westernunion all you need is Name on my passport and location below. Receiver's Name:John Blinka Location:10 Fish Street Hill London, EC3R 6DB, United Kingdom Amount:$2,450 I'll def refund your cash as soon as i get home. Reply
Re: [Amanda-users] amrecover 3.1.1 issue
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 can't restore it. Can you post the complete log.timestatmp.0, the amdump.? log file and the dumper.*.debug file. Jean-Louis
Re: [Amanda-users] amrecover 3.1.1 issue
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 file. You're right - this suggests something very wrong in the original backup. That said, I'll adjust Amanda::DB::Catalog to not die on such logfiles. Dustin -- Open Source Storage Engineer http://www.zmanda.com
[Amanda-users] amrecover 3.1.1 issue
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 was sent by richard.t@gmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +--
[Amanda-users] 3.2.0 beta1 release
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 via Backup Central. |Forward SPAM to ab...@backupcentral.com. +--
Re: [Amanda-users] amrecover 3.1.1 issue
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 when that particular DLE was dumped: 7998 driver: result time 666.284 from dumper2: DONE 02-00019 1290 33 0 [sec 0.295 kb 33 kps 111.8 orig-kb 1290] it was compressed from 1290k to 33k! In fact, all of your dumps are compressing to virtually nothing. I don't think bzip2 is doing the job for you. Does bzip2 need an argument to compress stdin? I think this is the core of your problem. I'm not sure why the taper wrote 'sec -1.', when the taper run actually took 0.045 seconds, but that's secondary to the problem, and has, I believe, been remedied in newer versions. Dustin -- Open Source Storage Engineer http://www.zmanda.com
[Amanda-users] amrecover 3.1.1 issue
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. +--
[SECURITY ALERT] Vulnerability in Amanda-3.1.2 - Upgrade to 3.1.3
-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 Amanda-3.1.3, which is released today. It is a patch release in the 3.1.x series, and contains the fix for this security vulnerability as well as fixes for several other significant bugs in 3.1.2. This upgrade should be considered a high priority upgrade. Updated images and tarballs are available at - http://www.amanda.org - https://sourceforge.net/project/showfiles.php?group_id=120 - http://www.zmanda.com/download-amanda.php A permanent copy of this alert is at - http://www.amanda.org/secalert-3-1-2.php The MD5 sum for the release tarball is f72fa06d4f90f7997b17ded1d7b4314e Dustin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyrazUACgkQdiVAPX8NFbFtLwCfW+Sb1MRoPTU9KSMaIud3Pai2 Ol0AoOKUknQQs20TqBImE231GzDKuUCN =oT6b -END PGP SIGNATURE-
[no subject]
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 writing block:
Mysterious short write on tape device: Tried 2097152, got 1052672
hertz /gauss/export/users-s lev 0 FLUSH while ejecting volume: Can't open
tape device /dev/rmt/0cbn: Device busy
I understand why I got
hertz /gauss/export/users-s lev 0 FAILED [too many taper retries]
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.
I have taperflush=100 and so amanda should eject the current tape and put in
the next tape, but for some reason I get Device busy
hertz /gauss/export/users-s lev 0 FLUSH while ejecting volume: Can't open
tape device /dev/rmt/0cbn: Device busy
I have
define changer c4 {
tpchanger chg-robot:/dev/changer/0
changerfile chg-zd-mtx-state
property tape-device 0=tape:/dev/rmt/0cbn
property eject-before-unload true
property eject-delay 5
property unload-delay 5
property use-slots 1-30
property load-poll 0s poll 5s until 120s
}
I had this error a while back and then it just stopped. I started getting the
error again for the last several days.
Any ideas why what could cause this.
Robert
_
Robert P. McGraw, Jr.
Manager, Computer SystemEMAIL: rmcg...@purdue.edu
Purdue UniversityROOM: MATH-807
Department of Mathematics PHONE: (765) 494-6055
150 N. University Street
West Lafayette, IN 47907-2067
3.2.0beta2 tomorrow - last call!
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
Re:
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 bigger than your tape drive can handle (1M). As for the device-busy error, do you get this error if you don't see the Mysterious short write? Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: 3.2.0 beta1 release
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 solve this issue. I'd recommend that. I consider BSD and BSDUDP authentications to be legacy backward-compatibility modes. TCP/IP is the wave of the future! (also, SSL which incidentally looks like it will wait until Amanda-3.3). 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. As for options to configure, major ones (and other goodies) are documented at http://wiki.zmanda.com/index.php/Installation/Installing_Amanda_Source Good; now I can get rid of a lot of stuff I don't need. -- Charles Curley /\ASCII Ribbon Campaign Looking for fine software \ /Respect for open standards and/or writing? X No HTML/RTF in email http://www.charlescurley.com/ \No M$ Word docs in email Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB
Re: 3.2.0 beta1 release
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 tomorrows beta2 announcement - 3.2.0beta1 does not exhibit the security vulnerability in 3.1.2, and 3.2.0beta2 will not, either. As for options to configure, major ones (and other goodies) are documented at http://wiki.zmanda.com/index.php/Installation/Installing_Amanda_Source Good; now I can get rid of a lot of stuff I don't need. Ah, cool - thanks! Dustin -- Open Source Storage Engineer http://www.zmanda.com
