Re: Error while installing amanda-backup-client on RHEL 5 64-bit
On 11/17/2010 08:23 AM, Yogesh Hasabnis wrote: Hi All, I am trying to install amanda-backup_client-2.6.1p2-1.rhel5.x86_64.rpm on an RHEL 5 64-bit system. But I get an error as follows: # rpm -ivh --test amanda-backup_client-2.6.1p2-1.rhel5.x86_64.rpm error: Failed dependencies: libtermcap.so.2 is needed by amanda-backup_client-2.6.1p2-1.rhel5.x86_64 The libtermcap-devel-2.0.8-46.1.x86_64.rpm package which contains the libtermcap.so.2 has already been installed. Still the problem is observed. Can you kindly suggest any solution or workaround to this problem ? I checked the archives for a similar question. But the suggestions given there didn't work for me. Did you try yum localinstall amanda-backup_client-2.6.1p2-1.rhel5.x86_64.rpm instead? This will automatically resolve any dependencies. Could be an architecture issue -- maybe you have i386 versions of the termcap libraries installed by accident. - Julian
Re: RPM files for openSUSE 11.1
I have an amanda-2.6.0 package on OpenSUSE Build Service that I've been messing around with. https://build.opensuse.org/project/show?project=home:dunnj I cribbed the spec file from lmich on OBS and fixed some of the % Buildrequires. But OBS should be building packages for both 11.0 and 11.1. Feel free to hack on it yourself. - Julian
Re: client stopped getting backed up after June 18
On Sat, 2007-06-30 at 11:08 -0600, Charles Curley wrote: On Sat, Jun 30, 2007 at 12:20:43PM -0400, Julian C. Dunn wrote: I have the following strange problem with a FreeBSD amanda server running 2.5.1p3 and a Fedora 7 Linux client running the same. The last See bug 244916 in Redhat's Bugzilla. I tried the workaround, which is adding flags = IPv4 to /etc/xinetd.d/amanda on the client, but last night's backup failed again. I'm wondering if the problem is really applicable to me, because both the client and server already talk IPv6... unless Amanda has problems with IPv6? - Julian -- [ Julian C. Dunn [EMAIL PROTECTED] * You can throw confetti, ] [ WWW: www.aquezada.com/staff/julian * but you're still going ] [ PGP: 91B3 7A9D 683C 7C16 715F* through the motions, baby ] [ 442C 6065 D533 FDC2 05B9*- Aimee Mann ]
Re: client stopped getting backed up after June 18
On Mon, 2007-07-02 at 17:07 +0200, Radek Brich wrote: On Monday 02 of July 2007 16:09:55 Julian C. Dunn wrote: On Sat, 2007-06-30 at 11:08 -0600, Charles Curley wrote: On Sat, Jun 30, 2007 at 12:20:43PM -0400, Julian C. Dunn wrote: I have the following strange problem with a FreeBSD amanda server running 2.5.1p3 and a Fedora 7 Linux client running the same. The last See bug 244916 in Redhat's Bugzilla. I tried the workaround, which is adding flags = IPv4 to /etc/xinetd.d/amanda on the client, but last night's backup failed again. I'm wondering if the problem is really applicable to me, because both the client and server already talk IPv6... unless Amanda has problems with IPv6? Can amanda 2.5.1p3 really talk IPv6? I think it doesn't support it at all. Looks like you're right - I see your bug #198351 in RedHat bugzilla. Any idea when we might see Amanda 2.5.2 in FC7 updates? And until then, ought I just to downgrade xinetd to the last known working version? - Julian
Re: client stopped getting backed up after June 18
On Mon, 2007-07-02 at 13:43 -0600, Charles Curley wrote: On Mon, Jul 02, 2007 at 12:40:06PM -0400, Julian C. Dunn wrote: On Mon, 2007-07-02 at 17:07 +0200, Radek Brich wrote: Can amanda 2.5.1p3 really talk IPv6? I think it doesn't support it at all. Looks like you're right - I see your bug #198351 in RedHat bugzilla. Any idea when we might see Amanda 2.5.2 in FC7 updates? And until then, ought I just to downgrade xinetd to the last known working version? I am currently running F7 with xinetd-2.3.14-12.fc7 and no problems, but this is an IPv4 network. I believe the previous version of xinetd is that in the Fedora repo. The one in the Fedora repo also works, without the workround line. After you changed the xinetd file for amanda, did you restart xinetd? Whoops! I guess I'd better try that before complaining... - Julian
client stopped getting backed up after June 18
I have the following strange problem with a FreeBSD amanda server
running 2.5.1p3 and a Fedora 7 Linux client running the same. The last
successful backup of the client was on June 18. Ever since then, the
backup report has shown:
FAILURE AND STRANGE DUMP SUMMARY:
jupiter mapper/VolGroup00-LogVol00 RESULTS MISSING
jupiter sda1RESULTS MISSING
jupiter mapper/VolGroup00-LogVol02 RESULTS MISSING
jupiter mapper/VolGroup00-LogVol05 RESULTS MISSING
jupiter mapper/VolGroup00-LogVol06 RESULTS MISSING
jupiter mapper/VolGroup00-LogVol07 RESULTS MISSING
jupiter mapper/VolGroup00-LogVol08 RESULTS MISSING
jupiter mapper/VolGroup00-LogVol09 RESULTS MISSING
planner: ERROR Request to jupiter failed: timeout waiting for ACK
I can't find any useful information on the client except for .debug
files in /var/log/amanda/amandad that end with:
amandad: time 0.000: dgram_recv(dgram=0x39e6e2e928, timeout=0,
fromaddr=0x39e6e3
e920)
amandad: time 0.000: (sockaddr_in *)0x39e6e3e920 = { 10, 566, 0.0.0.0 }
amandad: time 9.122: dgram_recv(dgram=0x39e6e2e928, timeout=0,
fromaddr=0x39e6e3
e920)
amandad: time 9.122: (sockaddr_in *)0x39e6e3e920 = { 10, 566, 0.0.0.0 }
amandad: time 19.816: dgram_recv(dgram=0x39e6e2e928, timeout=0,
fromaddr=0x39e6e
3e920)
amandad: time 19.816: (sockaddr_in *)0x39e6e3e920 = { 10, 566, 0.0.0.0 }
amandad: time 29.814: pid 9520 finish time Fri Jun 29 00:44:59 2007
Doesn't tell me much. Any idea where I could start looking?
- Julian
client system crash using XFS root partition
I have an amanda setup as follows: server: amanda 2.5.1p2 running FreeBSD 6.2 client: amanda 2.5.0p2 running Fedora Core 6. The vendor SRPM has been rebuilt (rpmbuild -ba) in order to support xfsdump. The relevant packages: amanda-2.5.0p2-4 amanda-client-2.5.0p2-4 xfsdump-2.2.42-2.fc6 The client system has two disks, one is the root disk on a metadevice mirror, /dev/md0, and another is just a standalone drive, /dev/hde1. Both are formatted with XFS. If I try to back up the root partition, /dev/md0, using amanda, the client system crashes. On the rare occasion that I can actually access the client system before it locks up entirely, it seems that whatever amanda is doing causes the system to lose its root partition entirely (i.e. any ls command says I/O error). I can back up the /dev/hde1 standalone drive fine using Amanda, and I can manually xfsdump both drives. So something about the way Amanda is interacting with the client is causing the failure. Any ideas where I should start looking to fix this? - Julian -- [ Julian C. Dunn [EMAIL PROTECTED] * You can throw confetti, ] [ WWW: www.aquezada.com/staff/julian * but you're still going ] [ PGP: 91B3 7A9D 683C 7C16 715F* through the motions, baby ] [ 442C 6065 D533 FDC2 05B9*- Aimee Mann ]
making xfs dump work
I've got a Linux workstation which uses xfs as one of its volumes (/dev/md2), but which I can't back up using Amanda because Amanda appears to call /sbin/dump on it, which under Linux blows up (/sbin/dump is ext2/3 only). How do I make Amanda call the right dump program (xfsdump rather than /sbin/dump)? - Julian [ Julian C. Dunn [EMAIL PROTECTED] * You can throw confetti, ] [ WWW: www.aquezada.com/staff/julian * but you're still going ] [ PGP: 91B3 7A9D 683C 7C16 715F* through the motions, baby ] [ 442C 6065 D533 FDC2 05B9*- Aimee Mann ]
Re: making xfs dump work
On Thu, 13 Jul 2006, Joshua Baker-LePain wrote: On Thu, 13 Jul 2006 at 3:57pm, Julian C. Dunn wrote I have /usr/sbin/xfsdump already but Amanda doesn't seem to know how to call it, even though sendsize is aware that it's an XFS filesystem: Was xfsdump there when you *compiled* amanda? That's when the locations of such things get noted. Ah... I'm using the binary vendor RPM which I assume doesn't contain XFS support. Time to go compile my own. - Julian [ Julian C. Dunn [EMAIL PROTECTED] * You can throw confetti, ] [ WWW: www.aquezada.com/staff/julian * but you're still going ] [ PGP: 91B3 7A9D 683C 7C16 715F* through the motions, baby ] [ 442C 6065 D533 FDC2 05B9*- Aimee Mann ]
Re: amrecover Tape is not a dump tape but amrestore works?
Just following up on my own message. I'll try and be more succinct; maybe all my debugging info turned people off: What does 8 Extracting files using tape drive /dev/nrsa0 on host aphrodite.acf.aquezada.com.Load tape dltbw14 now Continue [?/Y/n/s/t]? Y Tape is not a dump tape extract_list - child returned non-zero status: 1 8 mean? - Julian -- [ Julian C. Dunn [EMAIL PROTECTED] * You can throw confetti, ] [ WWW: www.aquezada.com/staff/julian * but you're still going ] [ PGP: 91B3 7A9D 683C 7C16 715F* through the motions, baby ] [ 442C 6065 D533 FDC2 05B9*- Aimee Mann ]
Re: amrecover Tape is not a dump tape but amrestore works?
On Wed, 12 Jul 2006, Jon LaBadie wrote: On Wed, Jul 12, 2006 at 08:38:16AM -0400, Julian C. Dunn wrote: Just following up on my own message. I'll try and be more succinct; maybe all my debugging info turned people off: What does 8 Extracting files using tape drive /dev/nrsa0 on host aphrodite.acf.aquezada.com.Load tape dltbw14 now Continue [?/Y/n/s/t]? Y Tape is not a dump tape extract_list - child returned non-zero status: 1 8 mean? Sometimes people just don't have an answer, so they don't post :) I know, and sometimes people are discouraged by reams of debugging info (mea culpa) :-) I grep'ed the source, that message Tape is not a dump tape does not come directly from amanda. It must be coming from an auxilliary program. As it is refering to dump, I suspect it is coming from the restore program (restore, ufsrestore, ???restore, not amrestore). So whatever was fed by amrecover to the restore program did not appear to be created by the corresponding dump program. Do you use dump/restore in your amanda dumptypes or gnutar? I use dump/restore. I was trying to restore files from babelfish (a FreeBSD 6.1 box) on the tape server aphrodite (a FreeBSD 4.9 box). One would think the dump/restore utilities would be the same between versions though? When directed to do so, did you manually load the correct tape and rewind it before typeing y? Yep... I'm not that silly :-) What did work was this: 1) use amrestore to pull the dumps off the tape and save them manually 2) run restore on the target machine to do interactive restore But I'd rather not have to do that in the future, so I'd like to fix this. - Julian [ Julian C. Dunn [EMAIL PROTECTED] * You can throw confetti, ] [ WWW: www.aquezada.com/staff/julian * but you're still going ] [ PGP: 91B3 7A9D 683C 7C16 715F* through the motions, baby ] [ 442C 6065 D533 FDC2 05B9*- Aimee Mann ]
amrecover Tape is not a dump tape but amrestore works?
Hi,
I'm trying to restore some dumps off a set of tapes, and I'm getting the
following error with amrecover:
8
Extracting files using tape drive /dev/nrsa0 on host
aphrodite.acf.aquezada.com.Load tape dltbw14 now
Continue [?/Y/n/s/t]? Y
Tape is not a dump tape
extract_list - child returned non-zero status: 1
8
However, running amrestore on one of the candidate tapes seems to get me
some dump files that are meaningful:
8
aphrodite:/vol/vol2/babelfish-restore$ sudo amrestore /dev/nrsa0 babelfish
Password:
amrestore: 1: skipping aphrodite.ar0s2e.20060609.1
amrestore: 2: restoring babelfish.ad0s1f.20060609.0
gzip: stdin: decompression OK, trailing garbage ignored
amrestore: 3: restoring babelfish.ad0s1a.20060609.2
gzip: stdin: decompression OK, trailing garbage ignored
amrestore: 4: restoring babelfish.ad0s1d.20060609.1
gzip: stdin: decompression OK, trailing garbage ignored
amrestore: 5: skipping aphrodite.ar0s1h.20060609.1
amrestore: 6: skipping aphrodite.ar0s1a.20060609.0
amrestore: 7: skipping aphrodite.ar0s1e.20060609.2
amrestore: 8: skipping aphrodite.ar0s1g.20060609.2
amrestore: 9: skipping aphrodite.ar0s2h.20060609.0
amrestore: 10: reached end of tape: date 20060612
8
Does anyone have an idea how I might recover these files using something a
little less blunt than amrestore?
The tape server is Amanda 2.4.5 and the relevant disklist entries are:
8
babelfish ad0s1a comp-root -1 fxp0
babelfish ad0s1f comp-user -1 fxp0
babelfish ad0s1d comp-user -1 fxp0
8
where comp-user is:
8
define dumptype comp-user {
global
comment Non-root partitions on reasonably fast machines
compress client fast
priority medium
}
8
- Julian
[ Julian C. Dunn [EMAIL PROTECTED] * You can throw confetti, ]
[ WWW: www.aquezada.com/staff/julian * but you're still going ]
[ PGP: 91B3 7A9D 683C 7C16 715F* through the motions, baby ]
[ 442C 6065 D533 FDC2 05B9*- Aimee Mann ]
