Re: amrecover fails with "TypeError in method 'debug'..."
On Sun, 2012-04-29 at 18:20 +, Kervin L. Pierre wrote: > Hi, > Look for an email from me in the archives, with subject, "Re: Recovery Help Request [RESOLVED]", from April 13th, 2012. For good measure, you might also want to look in the archives for a message with subject, "Re: amrecover failure [RESOLVED]", on April 26th, 2012. Both sets of emails, bugs, and fixes apply to 3.3.1 stable, which apparently isn't all that stable. I sincerely hope they'll push out a 3.3.2, with the patches applied for these known, show-stopper, bugs. Best of luck. Regards, > I'm following the simple recovery example from the wiki... > http://wiki.zmanda.com/index.php/GSWA/Recovering_Files > > Worked though all the issues but now I'm at the 'extract' and I'm getting an > error... > > amrecover - amidxtaped closed the connection > amrecover - can't talk to tape server: (null) > > Further inspection of /var/log/messages gives... > > amidxtaped[2784]: TypeError in method 'debug', argument 1 of type 'char *' > > I've found someone had run into this issue before 'June 2011'... > http://archives.zmanda.com/amanda-archives/viewtopic.php?t=6929&sid=f2141406dc79480edd30a1200443e9a6 > > They mentioned patching a Perl script but I haven't found the one they're > referring to. > > Does anyone have instructions on how to fix or workaround this issue? > > I'm using 3.3.1 built from source on an update to date Amazon Linux install. > > Best regards, > Kervin > > Adevsoft Inc > Business Software Development > http://adevsoft.com/ > > > > -- Greg Copeland Copeland Computer Consulting
Re: amrecover failure
On Thu, 2012-04-26 at 12:12 -0400, Chris Hoogendyk wrote: > The debug files should be in /tmp/amanda/server/ with the date-time stamp in > the place of the "*". > Of course, if you commented out debugging, you can always uncomment it and > then run amrecover again > to get the debug files. > Found them. Thanks. Making note for future reference. > What version of Amanda? What OS? What kind of tape? > > The issue is now resolved but for reference its CentOS 6.2, 64-bit. Amanda version 3.3.1. Thanks, -- Greg Copeland Copeland Computer Consulting
Re: amrecover failure [RESOLVED]
On Thu, 2012-04-26 at 09:54 -0600, Steven Backus wrote:
Thanks to Steven Backus and Jean-Louis for the win. This excerpt was
sent to me by Steven and did fix my issue.
I manually applied it to the perl module from my source build directory
and then simply copied it into production. Of course, I made backups
before I changed anything. I already had the required swig version
installed.
After installation, the restore was fast and painless.
This mailing list and those who contribute are by far one of Amanda's
greatest strengths.
Cheers,
> 1. Install swig-1.3.40.
>
> 2. Apply this patch, but not to Header.swg, to Header.pm
>
> diff --git a/perl/Amanda/Header.swg b/perl/Amanda/Header.swg
> index a7d391b..28cb4e8 100644
> --- a/perl/Amanda/Header.swg
> +++ b/perl/Amanda/Header.swg
> @@ -151,7 +151,11 @@ sub from_string {
> sub get_dle {
> my $self = shift;
>
> -return Amanda::Header::HeaderXML->new($self->{'dle_str'});
> +if ($self->{'dle_str'}) {
> + return Amanda::Header::HeaderXML->new($self->{'dle_str'});
> +} else {
> + return undef;
> +}
> }
>
> Steve
--
Greg Copeland
Copeland Computer Consulting
amrecover failure
Trying to recover a file via amrecover. I set the host and disk. I add the file in question. I confirm the tape is in the drive. I tell it to extract. I get: Got no header and data from server, check in amidxtaped.*.debug and amandad.*.debug files on server Any help? I have no idea where to begin. I can't seem to find the debug files in question. I wonder if this might be because in order to get Amanda to run in the first place, per my previous recovery, I had to comment out debugging output. Two recovery attempts and two times Amanda has failed to deliver. I have used Amanda years ago and only recently started using it again. I never had issues in the past. Something seems to have gone terribly wrong with Amanda since days gone by. Help, -- Greg Copeland Copeland Computer Consulting
Re: Recovery Help Request [RESOLVED]
Just a quick follow up. I wanted to share the file in question was
successfully recovered without further problems. The trick is to comment
out all of the debugging statements in the index server (amidxtaped).
Change these lines:
debug("CTL << $chopped");
Into these lines:
#debug("CTL << $chopped");
Reference, as suggested by Steven Backus:
http://forums.zmanda.com/showthread.php?3691-amrecover-segmentation-fault
This is definitely a bug in the latest amanda stable. To clarify, I am
running Amanda version 3.3.1, compiled from source on CentOS 6.2.
Is it presumptuous to assume this will make its way to the developers as
a bug report?
Thanks again.
Sincerely,
--
Greg Copeland
Copeland Computer Consulting
Re: Recovery Help Request
On Fri, 2012-04-13 at 11:19 -0700, Marcus Pless wrote: > I don't know if it's documented online but here's something like > what I've done in the past (config name was SGVA): > Thanks. I'm currently trying the proposed "patch", which is to simply comment out those debugging lines. So far, so good. It does appear to be trying to recover the desired file. Fingers crossed. If that fails, I'm sure I'll quickly be paying close attention to your wonderful reply. I made sure to include the the mailing list such that it can benefit others down the road. Again, thanks everyone so much for your rapid replies. If I get stuck, I'm sure I'll be back. Regards, > > To determine where on a tape a certain dumpfile is: > Look in ~amanda/logs/SGVA/log.[date].[N] where date is the > date that the > tape was written, and N is a serial number, for the > amdump/amflush > performed that day. N is usually 0. > > grep taper ~amanda/logs/SGVA/log.20060316.0 | less -N > > Once you find the filesystem you look for, the number will be > one > greater than the filenumber on the tape. If you fsf to the > index > minus two, you should be okay. I like using two for the extra > insurance. > > Be careful when restoring from a multiple tape set. The > numbers will > be far off. A second tape is used when you see something like > this: > > 307 START taper datestamp 20060316 label SGVA0024 tape 1 > > You will have to account for the index number (307), and the > INFO line > that follows it. Only SUCCESS lines indicate a file written to > tape. > > > To manually extract a file from an amanda tape: > 1) insert the tape > 2) fast forward to the position on the tape desired > $ mt -f /dev/nst0 fsf 13 > 3) extract the file > $ dd if=/dev/nst0 bs=32k skip=1 of=restored.file > > The format will either be a native dump format, or in a tar > format. > It will possibly be gzipped. > > additional notes > Following the above procedures I was able to manually extract > the > necessary files from tape. However, I was unable to read them > using > tar or restore. The recovered dump files also weren't > compressed or > gzip'd. I used 'file' for the name of the output file with > 'dd'. > > [mpless@sgva-serv1 58]# file file > file: AMANDA dump file, DATE 20060422 hostname.ucsd.edu /var/s > > So, it's an AMANDA dump file. What that means is that I still > needed > to use 'amrestore file' to convert (extract?) the file I > pulled from > the tape into something I could work with. This produced a > file named > 'hostname.ucsd.edu._var_spool_mail.20060422.2' which I was > able to > process using tar. > > [mpless@sgva-serv1 58]# file > hostname.ucsd.edu._var_spool_mail.20060422.2 > hostname.ucsd.edu._var_spool_mail.20060422.2: GNU tar archive > > > Things can get more complicated depending on the version of > amanda you're using, if you're splitting files, spanning tapes, > etc. More complicated in that the entries in the log file may > not line up quite as nicely, but they can still be used to get > close, if you have a lot of disk list entries. My daily backups > are usually 500+ disk list entries, so I need to get close on > the tape to do this manually. > > The 'bs' argument to 'dd' needs to match whatever blocksize > amanda used when it wrote the tape; I think the default for > amanda is 32k. If you're not sure where you are on the tape you > can do something like > > dd if=/dev/nst0 bs=32k count=1 > > to see the amanda header, which will include the name of the > host and filesystem. Compare this to the entries in the log > file to see if you're getting close. If that's not it you can > then do something like > > dd if=/dev/nst0 bs=32k fsf=1 > > to get to the start of the next file on tape, and then check the > amanda header using the above dd command. You can follow this in > the amanda log file so you'll know when you're getting close. > > If you're at the beginning of the file on tape (you haven't > read the amanda header you can use > > dd if=/dev/nst0 bs=32k skip=1 of=restored.file > > to extract that file, minus the amanda header. If you just read the > amanda header and that's the fi
Re: Recovery Help Request
On Fri, 2012-04-13 at 12:01 -0600, Steven Backus wrote: > A quick google came up with two solutions: > > http://forums.zmanda.com/showthread.php?3691-amrecover-segmentation-fault > http://www.mail-archive.com/amanda-users@amanda.org/msg46079.html > > I'll offer my own, upgrade to the latest version (3.3.1) and see if > that helps. > > Steve Thanks. I'll check those out. FYI, this is Amanda 3.3.1. -- Greg Copeland Copeland Computer Consulting
Recovery Help Request
I have a client who needs to recover a file. I'm using amrecover. I add the file needed for recovery. I then type, "extract". I then get the following. Extracting files using tape drive tape:/dev/nst0 on host backup.chapal.com. Load tape weekly-00 now Continue [?/Y/n/s/d]? Y amrecover - amidxtaped closed the connection amrecover - can't talk to tape server: (null) amrecover> Write failed: Broken pipe Syslogs show: Apr 13 12:06:42 backup amidxtaped[8523]: TypeError in method 'debug', argument 1 of type 'char *' I'm rather pressed for time on this so any solutions would be most appreciated. Even if I need to use a different recovery tool (amrestore). Help, -- Greg Copeland Copeland Computer Consulting
unsubscribe please
I have attempted to unsubscribe from all three lists and got an error hack in each case. Please unsubscribe me from all amanda mailing lists. Thank you. -- Greg Copeland, Owner [EMAIL PROTECTED] Copeland Computer Consulting 940.206.8004
Re: Using Amanda again...
On Mon, 2003-12-29 at 16:34, Jon LaBadie wrote: > On Mon, Dec 29, 2003 at 03:53:41PM -0600, Greg Copeland wrote: > > It's been several years since I last used Amanda and am having trouble > > remembering some of the details from the last time I used it. I'm > > attempting to backup 2 linux boxen and 1 win box, using amanda. On the > > Linux box, what is the preferred user and group names that amanda should > > run as? Is there such a thing? Is there a reason why I would not want > > amanda to simply run as root? > > The concept of minimal privledges for the task. > > Some programs require you to be root to run them (recoveries come to mind) > and others run automatically require root suid. > > > > I guess I may have to break down an actually read, in length, the > > provided documentation, if I continue to have problems. :( > > Oh my gosh, what a concept :) I understand that your response was followed with a smiley, however, it was less than helpful. As I previously stated, I have used amanda before, so, an in depth reading should not be required. I have also spent a fair amount of time reviewing (thus the, "in length", comment in my original posting), the available documentation and the faq-o-matic. To date, your message nor the sources that I've reviewed answered my very simple question. Care to follow up with a more helpful response? Thank you, -- Greg Copeland <[EMAIL PROTECTED]> Owner, Copeland Computer Consulting Phone: 940.206.8004 Fax: 940.497.3195
Using Amanda again...
It's been several years since I last used Amanda and am having trouble remembering some of the details from the last time I used it. I'm attempting to backup 2 linux boxen and 1 win box, using amanda. On the Linux box, what is the preferred user and group names that amanda should run as? Is there such a thing? Is there a reason why I would not want amanda to simply run as root? I guess I may have to break down an actually read, in length, the provided documentation, if I continue to have problems. :( Thanks, Greg -- Greg Copeland <[EMAIL PROTECTED]> Owner, Copeland Computer Consulting Phone: 940.206.8004 Fax: 940.497.3195
Re: Yet another Insecure Port ...
From a security perspective, you normally don't want to allow packet fragments. In most cases, turning off packet fragmentation is generally what you want. Why? Well, because some rules can not be properly applied to packet fragments which may create potential security concerns. Greg Jason Hollinden wrote: > The ports that worked best for me were: > > --with-portrange=2064,2320 > --with-udpportrange=830,870 > > Also, some other firewall wierdness I've had (with RedHat6.2's ipchains) > was once in a while a fragmented packet is sent, for whatever reason. > My amanda client's firewall log would show 3 denied packets from the > tape server, with source and destination ports of 65535. > > To get around this, you need a rule that allows fragmented packets, such > as this: > > -A input -s /32 -d /32 -f -j ACCEPT > > > On Wed, 04 Apr 2001, Doug Silver wrote: > >> Brand new build of amanda 2.4.2p2 >> >> server config build: >> /configure --with-gnutar=/usr/local/bin/tar --with-portrange=900,950 >> --with-udpportrange=900,950 (etc) >> >> client config build: >> ./configure --with-gtar=/usr/local/bin/gtar --without-server >> --with-portrange=900,950 --with-udpportrange=900,950 >> >> Server binaries: >> -rwsr-x--- 1 root wheel 68759 Apr 4 15:46 >> /usr/local/libexec/calcsize* >> -rwsr-x--- 1 root wheel 231765 Apr 4 15:47 /usr/local/libexec/dumper* >> -rwsr-x--- 1 root wheel 58227 Apr 4 15:46 >> /usr/local/libexec/killpgrp* >> -rwsr-x--- 1 root wheel 309711 Apr 4 15:47 /usr/local/libexec/planner* >> -rwsr-x--- 1 root wheel 56004 Apr 4 15:46 /usr/local/libexec/rundump* >> -rwsr-x--- 1 root wheel 56761 Apr 4 15:46 /usr/local/libexec/runtar* >> -rwsr-x--- 1 root wheel 322122 Apr 4 15:47 /usr/local/sbin/amcheck* >> >> Client: >> ls: /usr/local/libexec/dumper: No such file or directory >> ls: /usr/local/libexec/planner: No such file or directory >> -rwsr-x--- 1 root wheel 71756 Apr 4 17:22 /usr/local/libexec/calcsize* >> -rwsr-x--- 1 root wheel 62521 Apr 4 17:22 /usr/local/libexec/killpgrp* >> -rwsr-x--- 1 root wheel 60112 Apr 4 17:22 /usr/local/libexec/rundump* >> -rwsr-x--- 1 root wheel 60905 Apr 4 17:22 /usr/local/libexec/runtar* >> >> amcheck -c test >> >> Amanda Backup Client Hosts Check >> >> ERROR: frog.hoop-t.net: [host cat.hoop-t.net: port 62870 not >> secure] >> Client check: 1 host checked in 0.076 seconds, 1 problem found >> >> I'm not seeing any errors through the firewall, so I'm not sure how to >> further debug this. >> >> Any suggestions? Has anyone got Amanda to work using the >> udpportrange/portrange options through a firewall? >> >> Thanks! >> >> ~ >> Doug Silver >> 619 235-2665 >> Quantified Systems, Inc >> ~ >> Here's the client amandad.debug packet stuff: >> sending ack: >> >> Amanda 2.4 ACK HANDLE 000-00300D08 SEQ 986430352 >> >> >> amandad: sending REP packet: >> >> Amanda 2.4 REP HANDLE 000-00300D08 SEQ 986430352 >> ERROR [host cat.hoop-t.net: port 62870 not secure] >> >> >> amandad: got packet: >> >> Amanda 2.4 ACK HANDLE 000-00300D08 SEQ 986430352 >> >> >> amandad: pid 56308 finish time Wed Apr 4 17:25:53 2001 >> > > > -- >Jason Hollinden > >SMG Systems Admin > -- Greg Copeland, Principal Consultant Copeland Computer Consulting -- PGP/GPG Key at http://www.keyserver.net DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD --
unsubscribe gtcopeland@earthlink.net
unsubscribe [EMAIL PROTECTED]
unsubscribe
unsubscribe
Re: Using Removable Hard Drives for Backup
ORBs provide 2.2G per disk, are SCSI, and are pretty cheap if I recall. greg "Richard C" <[EMAIL PROTECTED]>, on the subject of 'Re: Using Removable Hard Drives for Backup', is quoted as: > >http://www.raidzone.com > > 1 TB ~~21,000 > >rcb > >On Mon, 11 Dec 2000, Bernhard R. Erdmann wrote: > >> Rod Roberts wrote: >> [...] >> > Hopefully some backup hardware manufacturer may in future sell sell a >> > system comprised of hot plugable disk mechanisms with little or no >> > electronics and a drive bay with the supporting electronics. The >> > economics of this look quite good at the moment. Any thoughts on this?? >> >> Syquest: 44, 88 & 270 MB per medium ;-) >> > >-- >- >Richard Bond ([EMAIL PROTECTED] (206) 605-3561 >System Administrator K-351, Health Sciences Center >Department of Molecular Biotechnology Box 357730 >University of Washington Seattle, WA 98195 > > > >
