RE: amrecover problems on compressed DLEs
I ran another backup with client compression, and tried
recovering from it. It hung in the same fashion as the previous time I tried
it. I then tried running amrecover on the actual client system itself (the
cleverly named "backuptest"), in the hopes that it would work better from
there. Sadly, it did not.
I then tried to read the files off the tape directly myself:
[root@archivist ssh]# tar -tf /dev/st0
tar: /dev/st0: Cannot read: Cannot allocate memory
tar: At beginning of tape, quitting now
tar: Error is not recoverable: exiting now
I'm not sure what that's about.
-Sandro
From: owner-amanda-us...@amanda.org [mailto:owner-amanda-us...@amanda.org] On
Behalf Of Ochressandro Rettinger
Sent: Tuesday, November 01, 2016 10:03 AM
To: 'Jean-Louis Martineau' <jmartin...@carbonite.com>;
'amanda-users@amanda.org' <amanda-users@amanda.org>
Subject: RE: amrecover problems on compressed DLEs
I tried to recover 4 or 5 times. It failed each time.
I only ran one backup of that type, but amcheckdump said it was
a good dump. I could try again.
-Sandro
From: Jean-Louis Martineau [mailto:jmartin...@carbonite.com]
Sent: Tuesday, November 01, 2016 9:50 AM
To: Ochressandro Rettinger
<orettin...@salud.unm.edu<mailto:orettin...@salud.unm.edu>>;
'amanda-users@amanda.org'
<amanda-users@amanda.org<mailto:amanda-users@amanda.org>>
Subject: Re: amrecover problems on compressed DLEs
client compressed dump are decompressed by amrecover
server compressed dump are decompressed by amidxtaped (on the server)
I tried many recovery with client compressed dump and it never hanged.
Do you tried it once or many times?
Knowing if it always fail or sometimes fail can help.
Jean-Louis
On 01/11/16 11:40 AM, Ochressandro Rettinger wrote:
Since you asked about server vs: client compression, I decided
to try server side compression instead. And, because my life just isn't weird
enough, it worked.
When I look at the amidxtaped.debug file for the process that
worked on recovery from server compressed tape, I see that it appears as
though amidxtaped itself is spawning a gzip process, and when I look at the
amidxtaped.debug file for the process that hung forever, I see no similar
message. Also, it appears that amidxtaped is simply aware of more needed
steps, for the server compressed backups.
Tue Nov 01 09:17:14.081375699 2016: pid 153615: thd-0x19b6400: amidxtaped:
Starting <Xfer@0x28f64e0 (<XferSourceRecovery@0x24fc000> ->
<XferFilterProcess@0x28fb010> -> <XferFilterCrc@0x293d030> ->
<XferDestFd@0x293d0e0>)>
Tue Nov 01 09:17:14.081424025 2016: pid 153615: thd-0x19b6400: amidxtaped:
Final linkage: <XferSourceRecovery@0x24fc000> -(PULL_BUFFER)->
<XferElementGlue@0x2976040> -(READFD)-> <XferFilterProcess@0x28fb010>
-(WRITEFD)-> <XferElementGlue@0x2976170> -(PUSH_BUFFER_STATIC)->
<XferFilterCrc@0x293d030> -(PUSH_BUFFER_STATIC)-> <XferElementGlue@0x29762a0>
-(WRITEFD)-> <XferDestFd@0x293d0e0>
Vs:
Sat Oct 29 14:18:46.905301215 2016: pid 98917: thd-0x2653600: amidxtaped:
Starting <Xfer@0x35a5e20 (<XferSourceRecovery@0x3199000> ->
<XferDestFd@0x3583820>)>
Sat Oct 29 14:18:46.905335006 2016: pid 98917: thd-0x2653600: amidxtaped: Final
linkage: <XferSourceRecovery@0x3199000> -(PULL_BUFFER)->
<XferElementGlue@0x3613030> -(WRITEFD)-> <XferDestFd@0x3583820>
-Sandro
From: Jean-Louis Martineau [mailto:jmartin...@carbonite.com]
Sent: Monday, October 31, 2016 2:53 PM
To: Ochressandro Rettinger
<orettin...@salud.unm.edu><mailto:orettin...@salud.unm.edu>;
'amanda-users@amanda.org<mailto:amanda-users@amanda.org>'
<amanda-users@amanda.org><mailto:amanda-users@amanda.org>
Subject: Re: amrecover problems on compressed DLEs
You are doing client or server compression?
The backup was done with 3.4 or 3.3.?
Can you post the complete amrecover and amidxtaped debug files.
Jean-Louis
On 31/10/16 03:51 PM, Ochressandro Rettinger wrote:
I'm running Amanda 3.4 (3.4.1?) from the zmanda RPM, on an RHEL
7.2 machine. My client is an RHEL 6.8 machine, running the same generation of
client, also from the zmanda RPM.
My disklist file was as follows:
backuptest /slash/ {
comp-gnutar-ssh
exclude append "./boot"
exclude append "./var"
}
backuptest /bootgnutar-ssh
backuptest /varcomp-gnutar-ssh-full
with the thought that everything in /boot is compressed already
anyway, and wanting to test the idea of splitting DLEs up and use different
backup methods and the like.
Well, the backup went OK, and running amcheckdump on the backup
sho
Re: amrecover problems on compressed DLEs
A few versions ago, I had this issue too. The newer clients were expecting to do their own decompression, since the client had compressed the dump to start with. But the older server had already DONE a decompress before sending the data. Thus, any backups done with CLIENT compression failed to restore, because the server sent data which was already uncompressed.** When I switched to always doing SERVER compression, those newer clients were happy, because then they didn’t try to do their own decompression. I had heard that newer versions fixed this, but I still always have the server do the compression (& thus the uncompression ). ** We had a temporary fix, so we could actually restore from dumps previously done with client side compression. Here it is: $ more gzip.null.kludge #!/bin/bash # # null gzip command to fake out amanda when restoring an old dump # from an old amanda server where the server gunzips before sending # and then the client also tries to gunzip the data... which fails # # to use: # cp this-file /usr/bin/gzip.null (if not already in place) # mv /usr/bin/gzip /usr/bin/gzip.real # mv /usr/bin/gzip.null /usr/bin/gzip # amrecover ... # mv /usr/bin/gzip /usr/bin/gzip.null # mv /usr/bin/gzip.real /usr/bin/gzip # /bin/cat > On Nov 1, 2016, at 11:03 AM, Ochressandro Rettinger > <orettin...@salud.unm.edu> wrote: > > I tried to recover 4 or 5 times. It failed each time. > > I only ran one backup of that type, but amcheckdump said it > was a good dump. I could try again. > > -Sandro > > From: Jean-Louis Martineau [mailto:jmartin...@carbonite.com] > Sent: Tuesday, November 01, 2016 9:50 AM > To: Ochressandro Rettinger <orettin...@salud.unm.edu>; > 'amanda-users@amanda.org' <amanda-users@amanda.org> > Subject: Re: amrecover problems on compressed DLEs > > client compressed dump are decompressed by amrecover > server compressed dump are decompressed by amidxtaped (on the server) > > I tried many recovery with client compressed dump and it never hanged. > > Do you tried it once or many times? > Knowing if it always fail or sometimes fail can help. > > Jean-Louis > > On 01/11/16 11:40 AM, Ochressandro Rettinger wrote: > Since you asked about server vs: client compression, I > decided to try server side compression instead. And, because my life just > isn’t weird enough, it worked. > > When I look at the amidxtaped.debug file for the process that > worked on recovery from server compressed tape, I see that it appears as > though amidxtaped itself is spawning a gzip process, and when I look at the > amidxtaped.debug file for the process that hung forever, I see no similar > message. Also, it appears that amidxtaped is simply aware of more needed > steps, for the server compressed backups. > > Tue Nov 01 09:17:14.081375699 2016: pid 153615: thd-0x19b6400: amidxtaped: > Starting <Xfer@0x28f64e0 (<XferSourceRecovery@0x24fc000> -> > <XferFilterProcess@0x28fb010> -> <XferFilterCrc@0x293d030> -> > <XferDestFd@0x293d0e0>)> > Tue Nov 01 09:17:14.081424025 2016: pid 153615: thd-0x19b6400: amidxtaped: > Final linkage: <XferSourceRecovery@0x24fc000> -(PULL_BUFFER)-> > <XferElementGlue@0x2976040> -(READFD)-> <XferFilterProcess@0x28fb010> > -(WRITEFD)-> <XferElementGlue@0x2976170> -(PUSH_BUFFER_STATIC)-> > <XferFilterCrc@0x293d030> -(PUSH_BUFFER_STATIC)-> <XferElementGlue@0x29762a0> > -(WRITEFD)-> <XferDestFd@0x293d0e0> > > > Vs: > > > Sat Oct 29 14:18:46.905301215 2016: pid 98917: thd-0x2653600: amidxtaped: > Starting <Xfer@0x35a5e20 (<XferSourceRecovery@0x3199000> -> > <XferDestFd@0x3583820>)> > Sat Oct 29 14:18:46.905335006 2016: pid 98917: thd-0x2653600: amidxtaped: > Final linkage: <XferSourceRecovery@0x3199000> -(PULL_BUFFER)-> > <XferElementGlue@0x3613030> -(WRITEFD)-> <XferDestFd@0x3583820> > > -Sandro > > From: Jean-Louis Martineau [mailto:jmartin...@carbonite.com] > Sent: Monday, October 31, 2016 2:53 PM > To: Ochressandro Rettinger <orettin...@salud.unm.edu>; > 'amanda-users@amanda.org' <amanda-users@amanda.org> > Subject: Re: amrecover problems on compressed DLEs > > You are doing client or server compression? > The backup was done with 3.4 or 3.3.? > Can you post the complete amrecover and amidxtaped debug files. > > Jean-Louis > > On 31/10/16 03:51 PM, Ochressandro Rettinger wrote: > > I’m running Amanda 3.4 (3.4.1?) from the zmanda RPM, on an > RHEL 7.2 machine. My client is an RHEL 6.8 machine, running the same
RE: amrecover problems on compressed DLEs
Since you asked about server vs: client compression, I decided
to try server side compression instead. And, because my life just isn't weird
enough, it worked.
When I look at the amidxtaped.debug file for the process that
worked on recovery from server compressed tape, I see that it appears as
though amidxtaped itself is spawning a gzip process, and when I look at the
amidxtaped.debug file for the process that hung forever, I see no similar
message. Also, it appears that amidxtaped is simply aware of more needed
steps, for the server compressed backups.
Tue Nov 01 09:17:14.081375699 2016: pid 153615: thd-0x19b6400: amidxtaped:
Starting <Xfer@0x28f64e0 (<XferSourceRecovery@0x24fc000> ->
<XferFilterProcess@0x28fb010> -> <XferFilterCrc@0x293d030> ->
<XferDestFd@0x293d0e0>)>
Tue Nov 01 09:17:14.081424025 2016: pid 153615: thd-0x19b6400: amidxtaped:
Final linkage: <XferSourceRecovery@0x24fc000> -(PULL_BUFFER)->
<XferElementGlue@0x2976040> -(READFD)-> <XferFilterProcess@0x28fb010>
-(WRITEFD)-> <XferElementGlue@0x2976170> -(PUSH_BUFFER_STATIC)->
<XferFilterCrc@0x293d030> -(PUSH_BUFFER_STATIC)-> <XferElementGlue@0x29762a0>
-(WRITEFD)-> <XferDestFd@0x293d0e0>
Vs:
Sat Oct 29 14:18:46.905301215 2016: pid 98917: thd-0x2653600: amidxtaped:
Starting <Xfer@0x35a5e20 (<XferSourceRecovery@0x3199000> ->
<XferDestFd@0x3583820>)>
Sat Oct 29 14:18:46.905335006 2016: pid 98917: thd-0x2653600: amidxtaped: Final
linkage: <XferSourceRecovery@0x3199000> -(PULL_BUFFER)->
<XferElementGlue@0x3613030> -(WRITEFD)-> <XferDestFd@0x3583820>
-Sandro
From: Jean-Louis Martineau [mailto:jmartin...@carbonite.com]
Sent: Monday, October 31, 2016 2:53 PM
To: Ochressandro Rettinger <orettin...@salud.unm.edu>;
'amanda-users@amanda.org' <amanda-users@amanda.org>
Subject: Re: amrecover problems on compressed DLEs
You are doing client or server compression?
The backup was done with 3.4 or 3.3.?
Can you post the complete amrecover and amidxtaped debug files.
Jean-Louis
On 31/10/16 03:51 PM, Ochressandro Rettinger wrote:
I'm running Amanda 3.4 (3.4.1?) from the zmanda RPM, on an RHEL
7.2 machine. My client is an RHEL 6.8 machine, running the same generation of
client, also from the zmanda RPM.
My disklist file was as follows:
backuptest /slash/ {
comp-gnutar-ssh
exclude append "./boot"
exclude append "./var"
}
backuptest /bootgnutar-ssh
backuptest /varcomp-gnutar-ssh-full
with the thought that everything in /boot is compressed already
anyway, and wanting to test the idea of splitting DLEs up and use different
backup methods and the like.
Well, the backup went OK, and running amcheckdump on the backup
showed as OK, but when I went to recover, attempting to recover /slash for
example, it would start trying to extract the files, and then just hang
forever. (Forever in this case being defined as 24 hours.) However, when I
tried to recover the /boot DLE, that actually worked. So, I changed my DLEs to
all be just plain "gnutar-ssh" type, re-ran the backup, and then attempted to
recover again, and was successful recovering.
I ran "ps -ef" while the amrecover process was hung, and saw
that it had spawned a "gzip -dc" process. So, I presume it was trying to pipe
compressed data to that process, but somehow, either before or afterwards, it
was getting lost on its way to the tar process. Indeed, looking at the debug
file, I see "amrecover: Spawning "/usr/bin/gzip /usr/bin/gzip -dc" in pipeline".
The last thing in the debug file is "amrecover:
send_to_tape_server: DATA-READY" until I hit ctrl-C in the amrecover window, at
which point a "QUIT" was sent by amrecover, presumably to the amandad process
that it was connected to.
Any thoughts on why this wouldn't be working? Any thoughts on
other things I can look at?
-Sandro
amrecover problems on compressed DLEs
I'm running Amanda 3.4 (3.4.1?) from the zmanda RPM, on an RHEL
7.2 machine. My client is an RHEL 6.8 machine, running the same generation of
client, also from the zmanda RPM.
My disklist file was as follows:
backuptest /slash/ {
comp-gnutar-ssh
exclude append "./boot"
exclude append "./var"
}
backuptest /bootgnutar-ssh
backuptest /varcomp-gnutar-ssh-full
with the thought that everything in /boot is compressed already
anyway, and wanting to test the idea of splitting DLEs up and use different
backup methods and the like.
Well, the backup went OK, and running amcheckdump on the backup
showed as OK, but when I went to recover, attempting to recover /slash for
example, it would start trying to extract the files, and then just hang
forever. (Forever in this case being defined as 24 hours.) However, when I
tried to recover the /boot DLE, that actually worked. So, I changed my DLEs to
all be just plain "gnutar-ssh" type, re-ran the backup, and then attempted to
recover again, and was successful recovering.
I ran "ps -ef" while the amrecover process was hung, and saw
that it had spawned a "gzip -dc" process. So, I presume it was trying to pipe
compressed data to that process, but somehow, either before or afterwards, it
was getting lost on its way to the tar process. Indeed, looking at the debug
file, I see "amrecover: Spawning "/usr/bin/gzip /usr/bin/gzip -dc" in pipeline".
The last thing in the debug file is "amrecover:
send_to_tape_server: DATA-READY" until I hit ctrl-C in the amrecover window, at
which point a "QUIT" was sent by amrecover, presumably to the amandad process
that it was connected to.
Any thoughts on why this wouldn't be working? Any thoughts on
other things I can look at?
-Sandro
amrecover problems
Hello,
i tried to set up a mix of
http://wiki.zmanda.com/index.php/Test_environment_with_virtual_tapes and
http://wiki.zmanda.com/index.php/Quick_start
now i can run backups but amrecover tells me about an invalid service
(this is debian/etch if it matters in some way)
if i add the -auth=bsd stuff to my /etc/inetd.conf I just get a
timeout. so I really don't have any idea what to do...
any help is appreciated, you can find a session below
$ su -l -c amdump data backup
runs without any errors...
$ amrecover data
AMRECOVER Version 2.5.1p1. Contacting server on localhost ...
NAK: amindexd: invalid service
$ su -l -c amcheck data backup
Amanda Tape Server Host Check
-
Holding disk /imports/holdingdisk/data/: 5232384 kB disk space
available, using 4720384 kB
slot 12: read label `DataDump-12', date `X'
NOTE: skipping tape-writable test
Tape DataDump-12 label ok
Server check took 0.193 seconds
Amanda Backup Client Hosts Check
Client check: 1 host checked in 0.107 seconds, 0 problems found
(brought to you by Amanda 2.5.1p1)
$ egrep '(^am)' /etc/inetd.conf
amanda dgram udp waitbackup /usr/sbin/tcpd
/usr/lib/amanda/amandad
amindexdstream tcp nowait backup /usr/sbin/tcpd
/usr/lib/amanda/amindexd
amidxtape stream tcp nowait backup /usr/sbin/tcpd
/usr/lib/amanda/amidxtaped
$ egrep -v '(^#)|(^$)' /etc/amandahosts
localhost root amdump amindexd amidxtaped
localhost backup amdump amindexd amidxtaped
shares.openforce.com root amdump amindexd amidxtaped
shares.openforce.com backup amdump amindexd amidxtaped
$ egrep '(^am)' /etc/services
amanda 10080/tcp # amanda backup services
amanda 10080/udp
amindexd10082/tcp # amanda backup
services # amandaidx
amidxtaped 10083/tcp # amanda backup
services # amidxtape
$ egrep -v '(^#)|(^$)' /etc/amanda/data/amanda.conf
org My Company
mailto [EMAIL PROTECTED]
dumpcycle 4 weeks
runspercycle 28
tapecycle 30
dumpuser backup
tpchanger chg-disk
tapedev file:/imports/backup/data/slots
changerfile /var/lib/amanda/data/changerfile
labelstr DataDump-.*
tapetype DVD_SIZED_DISK
logdir /var/log/amanda/data
infofile /var/lib/amanda/data/curinfo
indexdir /var/lib/amanda/data/index
tapelist /var/lib/amanda/data/tapelist
holdingdisk HD-DATA {
directory /imports/holdingdisk/data/
use -500 Mb
chunksize 500 Mb
}
define dumptype comp-tar {
program GNUTAR
compress fast
index yes
record no
}
define tapetype DVD_SIZED_DISK {
filemark 4 KB
length 4482 MB
}
--
Martin Marcher
[EMAIL PROTECTED]
http://www.mycorners.com
https://www.xing.com/profile/Martin_Marcher
http://www.linkedin.com/in/martinmarcher
http://www.studivz.net/profile.php?ids=9f83ea8c5996b8ec
http://www.amazon.de/gp/registry/wishlist/3KDAGCL2NKOIM/ref=reg_hu-wl_goto-registry/302-4432803-5146435?ie=UTF8sort=date-added
Re: amrecover problems
Your inetd.conf must be:
amanda dgram udp waitbackup /usr/sbin/tcpd
/usr/lib/amanda/amandad -auth=bsd amdump amindexd amidxtaped
Martin Marcher wrote:
Hello,
i tried to set up a mix of
http://wiki.zmanda.com/index.php/Test_environment_with_virtual_tapes and
http://wiki.zmanda.com/index.php/Quick_start
now i can run backups but amrecover tells me about an invalid service
(this is debian/etch if it matters in some way)
if i add the -auth=bsd stuff to my /etc/inetd.conf I just get a
timeout. so I really don't have any idea what to do...
any help is appreciated, you can find a session below
$ su -l -c amdump data backup
runs without any errors...
$ amrecover data
AMRECOVER Version 2.5.1p1. Contacting server on localhost ...
NAK: amindexd: invalid service
$ su -l -c amcheck data backup
Amanda Tape Server Host Check
-
Holding disk /imports/holdingdisk/data/: 5232384 kB disk space
available, using 4720384 kB
slot 12: read label `DataDump-12', date `X'
NOTE: skipping tape-writable test
Tape DataDump-12 label ok
Server check took 0.193 seconds
Amanda Backup Client Hosts Check
Client check: 1 host checked in 0.107 seconds, 0 problems found
(brought to you by Amanda 2.5.1p1)
$ egrep '(^am)' /etc/inetd.conf
amanda dgram udp waitbackup /usr/sbin/tcpd
/usr/lib/amanda/amandad
amindexdstream tcp nowait backup /usr/sbin/tcpd
/usr/lib/amanda/amindexd
amidxtape stream tcp nowait backup /usr/sbin/tcpd
/usr/lib/amanda/amidxtaped
$ egrep -v '(^#)|(^$)' /etc/amandahosts
localhost root amdump amindexd amidxtaped
localhost backup amdump amindexd amidxtaped
shares.openforce.com root amdump amindexd amidxtaped
shares.openforce.com backup amdump amindexd amidxtaped
$ egrep '(^am)' /etc/services
amanda 10080/tcp # amanda backup services
amanda 10080/udp
amindexd10082/tcp # amanda backup
services # amandaidx
amidxtaped 10083/tcp # amanda backup
services # amidxtape
$ egrep -v '(^#)|(^$)' /etc/amanda/data/amanda.conf
org My Company
mailto [EMAIL PROTECTED]
dumpcycle 4 weeks
runspercycle 28
tapecycle 30
dumpuser backup
tpchanger chg-disk
tapedev file:/imports/backup/data/slots
changerfile /var/lib/amanda/data/changerfile
labelstr DataDump-.*
tapetype DVD_SIZED_DISK
logdir /var/log/amanda/data
infofile /var/lib/amanda/data/curinfo
indexdir /var/lib/amanda/data/index
tapelist /var/lib/amanda/data/tapelist
holdingdisk HD-DATA {
directory /imports/holdingdisk/data/
use -500 Mb
chunksize 500 Mb
}
define dumptype comp-tar {
program GNUTAR
compress fast
index yes
record no
}
define tapetype DVD_SIZED_DISK {
filemark 4 KB
length 4482 MB
}
Re: Amrecover problems
I followed this sites example of doing a restore http://homepages.cs.ncl.ac.uk/ncrr/procedures/amrecover.html Also I got the correct filename/extension as I stated and the path in which the file was restored was correct as well. So this is what I did to add the file I wanted for those that wish to see.. amrecover add vpasswd Added /**/vpasswd amrecover extract Extracting files using tape drive /dev/st0 on host **. The following tapes are needed: DailySet15 Restoring files into directory /var/spool/amanda Continue? [Y/n]: y Jason From: Paul Bijnens [EMAIL PROTECTED] Date: Fri, 04 Feb 2005 09:38:25 +0100 To: Jason Miller [EMAIL PROTECTED] Subject: Re: Amrecover problems Jason Miller wrote: Has anyone ran across a issue while running amrecover where the file that is requested and extracted from recover is not at all the file you ended up with. The filename/extension are correct but the actual content is not at all what the original was. So to illustrate what I am trying to say here is my example ... Any insight on what I could have done wrong? You could at least show the commands you did? e.g. the filenames you entered, and the filenames you got instead, also including the path up to that file etc. (are there any strange characters in the filename: wildcards, spaces, Was it the correct tape that you inserted? etc. etc. -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... Are you sure? ... YES ... Phew ... I'm out * ***
Amrecover problems
Has anyone ran across a issue while running amrecover where the file that is requested and extracted from recover is not at all the file you ended up with. The filename/extension are correct but the actual content is not at all what the original was. So to illustrate what I am trying to say here is my example I was expecting the following output in my recovered text file; 14grand:$1$FUP5cjOh$mEfi4gAXrCq5xOyY.Y4tH/:1:0:14grand:/usr/local/vpopmail/d omai ns/**/14grand:1600S 17706303:$1$Nc1pDv1T$h.zl9f.NyjJgCBgasdQZr1:1:0:17706303:/usr/local/vpopmail /dom ains/**/17706303:1600S 1974bliss:$1$BsFFyTES$EiyfprX/JMGNf756ZayDl.:1:0:1974bliss:/usr/local/vpopma il/d omains/**/1974bliss:1600S 1andonly:$1$L7luiB5y$n4XW5ATnp1.llKowR9bRZ1:1:0:1andonly:/usr/local/vpopmail /dom ains/**/1andonly:1600S But I got this instead; Return-Path: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: (qmail 42535 invoked by uid 0); 1 Feb 2005 18:00:59 - Received: from unknown (HELO** by zeata.interlinc.net with SMTP; 1 Feb 2005 18:00:59 - MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=_=_NextPart_001_01C43209.B50370E0 Subject: Interlinc.net Billing Reminder Date: Tue, 01 Feb 2005 18:14:25 GMT From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] This is a multi-part message in MIME format. --_=_NextPart_001_01C43209.B50370E0 Content-Type: text/plain; charset=us-ascii Etc etc etc etc So as you can see I was expecting a bunch of text garbage but got an email instead... LOL Any insight on what I could have done wrong? Thanks in advance, Jason
amrecover problems with indexes
I am having problems using amrecover. I can only see limited number of
indexes and then follow them down to a file level. Most indexes do not
seem to be there. When I do a 'ls' command I only see the 'opt/'
directory or entry from the index files.
amrecover setdisk /hostserver0/root
Scanning /var/holddisk/amanda1...
20030627: found Amanda directory.
Scanning /var/holddisk/amanda0...
20030627: found Amanda directory.
200 Disk set to /hostserver0/root.
amrecover ls
2003-07-01 opt/
From the index file 20030701_0: I see serveral entries for /opt...
/opt/SUNWexplo/output/explorer.hostserver0-2003.06.28.07.00/disks/vxvm/disk_groups/vxdg-g_free=r
ootdg.out
And I also see the following entries in the same index file:
...
07665067355/./etc/lu/optfs
07665067356/./etc/vx/vras/.rdg
07665067403/./opt/SUNWstade/System/NETCONNECT
...
07665067405/./opt/SUNWstade/lib/auto/XML/LibXML/LibXML.bs
07665067405/./opt/SUNWstade/lib/auto/XML/Parser/Expat/Expat.bs
07665067412/./.dt/.Printers/CSD-HP5_Print
07665067412/./.dt/.Printers/_default_Print
07665067412/./.dt/.Printers/hplj5si_Print
...
When I do a 'ls' command in amrecover, I only see the 'opt/' directories
and files and none of the other enteries that start with a number followed by
a '/./'.
My dumptype looks like:
define dumptype global {
comment Global definitions
holdingdisk no
compress none
}
define dumptype root-tar {
global
program GNUTAR
comment root partitions dumped with tar
index yes
priority high
dumpcycle 0
}
My disklist looks like:
hostserver0 / root-tar 1 local
Also, I am running Amanda 2.4.4 on a Sun Solaris 9 box. Has anyone seen
any problems like this? Any ideas? Thanks in advance.
Bob...
--
Robert Zahn UNIX Systems Administrator
Oklahoma City Community College
S. May Avenue
Oklahoma City, Ok 73159
[EMAIL PROTECTED][EMAIL PROTECTED]
--
Re: amrecover problems with indexes
On Tue, 1 Jul 2003 at 2:22pm, Bob Zahn wrote And I also see the following entries in the same index file: .. 07665067355/./etc/lu/optfs 07665067356/./etc/vx/vras/.rdg 07665067403/./opt/SUNWstade/System/NETCONNECT .. 07665067405/./opt/SUNWstade/lib/auto/XML/LibXML/LibXML.bs 07665067405/./opt/SUNWstade/lib/auto/XML/Parser/Expat/Expat.bs 07665067412/./.dt/.Printers/CSD-HP5_Print 07665067412/./.dt/.Printers/_default_Print 07665067412/./.dt/.Printers/hplj5si_Print Uh oh. Also, I am running Amanda 2.4.4 on a Sun Solaris 9 box. Has anyone seen any problems like this? Any ideas? Thanks in advance. This is a very common problem -- you're running a bad version of tar (probably 1.13). You need at least 1.13.19, and (last I checked) 1.13.25 is current. You can get them from alpha.gnu.org. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: amrecover problems ....
--On Thursday, February 13, 2003 22:02:46 -0700 Jim Richard [EMAIL PROTECTED] wrote: I can't seem to get amrecover to work. I have a single server running amanda, with an SDLT drive attached to it. All my clients are being backed up without problems. (I have done recent recoveries manually.) However, when I try to run amrecover from a client, when I issue the extract, amrecover fails and tells me to check the amidxtaped log file on the server. I do and at the end of it I see: Ready to execv amrestore with: path = /usr/local/sbin/amrestore argv[0] = amrestore argv[1] = -h argv[2] = -p argv[3] = /dev/nst0 argv[4] = lun argv[5] = ^/home$ argv[6] = 20030120 amrestore: could not open tape /dev/nst0: Permission denied amidxtaped: amrestore terminated normally with status: 2 Rewinding tape: no tape online amidxtaped: pid 27373 finish time Thu Feb 13 17:16:29 2003 the amrecover command I use on the client: /usr/local/sbin/amrecover -C set1 -s godzilla -t godzilla -d /dev/nst0 godzilla is my amanda/tape server, lun is the client I'm trying to run it on. all the clients are having no problem talking to /dev/nst0 on the tape server during backup, why would amrecover be having a problem. Something to do with having to run amrecover as root on the client Are you running amrecover as root on the client? You should be. Frank Clues ?? thanks
amrecover problems ....
I can't seem to get amrecover to work. I have a single server running amanda, with an SDLT drive attached to it. All my clients are being backed up without problems. (I have done recent recoveries "manually.") However, when I try to run amrecover from a client, when I issue the extract, amrecover fails and tells me to check the amidxtaped log file on the server. I do and at the end of it I see: Ready to execv amrestore with:path = /usr/local/sbin/amrestoreargv[0] = "amrestore"argv[1] = "-h"argv[2] = "-p"argv[3] = "/dev/nst0"argv[4] = "lun"argv[5] = "^/home$"argv[6] = "20030120"amrestore: could not open tape /dev/nst0: Permission deniedamidxtaped: amrestore terminated normally with status: 2Rewinding tape: no tape onlineamidxtaped: pid 27373 finish time Thu Feb 13 17:16:29 2003 the amrecover command I use on the client: /usr/local/sbin/amrecover -C set1 -sgodzilla -t godzilla -d /dev/nst0 godzilla is my amanda/tape server, lun is the client I'm trying to run it on. all the clients are having no problem talking to /dev/nst0 on the tape server during backup, why would amrecover be having a problem. Something to do with having to run amrecover as root on the client Clues ?? thanks
Re: tar, amrecover problems
Hello James, What's the output of 'amadmin config find'?, amrecover will not use a dump that is not listed. Could you also provide your amindexd.*.debug file. Jean-Louis On Fri, Oct 04, 2002 at 01:39:03PM -0400, James Shearer wrote: Hello. I am new to amanda, and recently attempted a test recovery using amrecover. Alas, I did not get very far. I recieved the No index records for disk for specified date error, despite having enabled indexing in my amanda.conf. Google turned up alot of hits for this error, one of which pointed to what I thought was my culprit: tar 1.13. The generated index files in my amanda index directory has the leading numerals described by previously troubled amrecover users. So, I wrote a quick perl script to fix up the files and upgraded tar (today). I removed the leading [0-9]+/ from the entries. Still, however, amrecover reports the *same error*. Is there some problem with repairing the index files after their initial generation? Is there some other aspect of indexing that could be affecting these files, or amrecover's ability to find/read them? Again, I did enable indexing in my amanda.conf and I have had no problems with setdisk or sethost. I will see if my situation improves after the next run (and thus, gnu tar is used), but I would really like to know what's going on, if for no other reason as to have a better understanding of indexing in amanda. TIA, Jim -- :egad, a base tone denotes a bad age!: tmbg -- Jean-Louis Martineau email: [EMAIL PROTECTED] Departement IRO, Universite de Montreal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montreal, Canada, H3C 3J7Fax: (514) 343-5834
tar, amrecover problems
Hello. I am new to amanda, and recently attempted a test recovery using amrecover. Alas, I did not get very far. I recieved the No index records for disk for specified date error, despite having enabled indexing in my amanda.conf. Google turned up alot of hits for this error, one of which pointed to what I thought was my culprit: tar 1.13. The generated index files in my amanda index directory has the leading numerals described by previously troubled amrecover users. So, I wrote a quick perl script to fix up the files and upgraded tar (today). I removed the leading [0-9]+/ from the entries. Still, however, amrecover reports the *same error*. Is there some problem with repairing the index files after their initial generation? Is there some other aspect of indexing that could be affecting these files, or amrecover's ability to find/read them? Again, I did enable indexing in my amanda.conf and I have had no problems with setdisk or sethost. I will see if my situation improves after the next run (and thus, gnu tar is used), but I would really like to know what's going on, if for no other reason as to have a better understanding of indexing in amanda. TIA, Jim -- :egad, a base tone denotes a bad age!: tmbg
Re: tar, amrecover problems
I get this error every time I run amrecover from a directory that isn't in my disklist, or from a host that isn't the backup server. Try using the sethost, setdisk, and setdate commands in amrecover. For example: sbs|amv: /tmp sudo amrecover Gemini AMRECOVER Version 2.4.2p2. Contacting server on sbs ... 220 sbs AMANDA index server (2.4.2p2) ready. 200 Access OK Setting restore date to today (2002-10-04) 200 Working date set to 2002-10-04. 200 Config set to Gemini. 200 Dump host set to sbs. $CWD '/tmp' is on disk '/tmp' mounted at '/tmp'. 200 Disk set to /tmp. No index records for disk for specified date If date correct, notify system administrator Invalid directory - /tmp amrecover sethost sbs 200 Dump host set to sbs. amrecover setdisk /home 200 Disk set to /home. amrecover setdate 2002-10-03 200 Working date set to 2002-10-03. amrecover ls 2002-10-03 . 2002-09-27 .sh_history 2002-10-03 amv/ 2002-10-03 bat/ 2002-10-03 btj/ . . . 2002-10-03 vsifax/ amrecover Good luck. Anthony Valentine On Fri, 2002-10-04 at 09:39, James Shearer wrote: Hello. I am new to amanda, and recently attempted a test recovery using amrecover. Alas, I did not get very far. I recieved the No index records for disk for specified date error, despite having enabled indexing in my amanda.conf. Google turned up alot of hits for this error, one of which pointed to what I thought was my culprit: tar 1.13. The generated index files in my amanda index directory has the leading numerals described by previously troubled amrecover users. So, I wrote a quick perl script to fix up the files and upgraded tar (today). I removed the leading [0-9]+/ from the entries. Still, however, amrecover reports the *same error*. Is there some problem with repairing the index files after their initial generation? Is there some other aspect of indexing that could be affecting these files, or amrecover's ability to find/read them? Again, I did enable indexing in my amanda.conf and I have had no problems with setdisk or sethost. I will see if my situation improves after the next run (and thus, gnu tar is used), but I would really like to know what's going on, if for no other reason as to have a better understanding of indexing in amanda. TIA, Jim -- :egad, a base tone denotes a bad age!: tmbg -- UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.
RE: tar, amrecover problems
I get this error every time I run amrecover from a directory that isn't in my disklist, or from a host that isn't the backup server. Try using the sethost, setdisk, and setdate commands in amrecover. Yep. I've tried that before. It's still no good, as you can see: # /usr/local/sbin/amrecover AMRECOVER Version 2.4.2p2. Contacting server on mullet1 ... 220 mullet1 AMANDA index server (2.4.2p2) ready. 200 Access OK Setting restore date to today (2002-10-04) 200 Working date set to 2002-10-04. 200 Config set to DailySet1. 200 Dump host set to mullet1. Can't determine disk and mount point from $CWD amrecover setdisk /usr/local Scanning /export/home/amanda/dumps... 200 Disk set to /usr/local. No index records for disk for specified date If date correct, notify system administrator amrecover setdate 2002-10-04 200 Working date set to 2002-10-04. No index records for cwd on new date Setting cwd to mount point DailySet1 is indeed the config, and mullet1 is the correct host. Here's a snippet of the index file for /usr/local on mullet1 for 10/4: [begin snippet] ./apache/htdocs/ttweb/ ./apache/htdocs/ttweb/docs/ ./apache/htdocs/ttweb/docs/images/ ./apache/htdocs/ttweb/docs/wwhdata/ ./apache/htdocs/ttweb/docs/wwhdata/common/ ./apache/htdocs/ttweb/docs/wwhdata/js/ ./apache/htdocs/ttweb/docs/wwhdata/js/search/ ./apache/htdocs/ttweb/docs/wwhelp/ [end] Again, this is after the perl-fix-up removing the leading numerals.
Re: tar, amrecover problems
--On Friday, October 04, 2002 13:39:03 -0400 James Shearer [EMAIL PROTECTED] wrote: Hello. I am new to amanda, and recently attempted a test recovery using amrecover. Alas, I did not get very far. I recieved the No index records for disk for specified date error, despite having enabled indexing in my amanda.conf. Google turned up alot of hits for this error, one of which pointed to what I thought was my culprit: tar 1.13. The generated index files in my amanda index directory has the leading numerals described by previously troubled amrecover users. So, I wrote a quick perl script to fix up the files and upgraded tar (today). I removed the leading [0-9]+/ from the entries. I'm not sure editing is a fix. Someone on this list reported that restoring from one of the bad tar archives resulted in the files being OK but the directories were all renamed (I think to big numbers), and that if you knew what the paths were supposed to be you could (with a lot of work) restore everything as it was. Still, however, amrecover reports the *same error*. Is there some problem with repairing the index files after their initial generation? Is there some other aspect of indexing that could be affecting these files, or amrecover's ability to find/read them? Again, I did enable indexing in my amanda.conf and I have had no problems with setdisk or sethost. Did you check to be sure that you have an amandaidx entry in your (x)inetd config and that there are no packet filters in place that would block connections to it? I will see if my situation improves after the next run (and thus, gnu tar is used), but I would really like to know what's going on, if for no other reason as to have a better understanding of indexing in amanda. TIA, Jim Good luck, Frank -- Frank Smith[EMAIL PROTECTED] Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
RE: tar, amrecover problems
I'm not sure editing is a fix. Someone on this list reported that restoring from one of the bad tar archives resulted in the files being OK but the directories were all renamed (I think to big numbers), and that if you knew what the paths were supposed to be you could (with a lot of work) restore everything as it was. Noted. I'll watch out for that -- at this point, I'm just concerned that the bad index file was not the problem, and that even after tonight's run with the new gnu (ha) tar, I will still be without amrecover's fine services. Did you check to be sure that you have an amandaidx entry in your (x)inetd config and that there are no packet filters in place that would block connections to it? That's a good thought, but here's the apropos entry from my inetd.conf: amandaidx stream tcp nowait amanda /usr/local/libexec/amindexd amindexd and here's what netstat says: *.amidxtape *.*0 0 24576 0 LISTEN And there's no firewall or tcpwrappers in use
RE: tar, amrecover problems
Well, so much for that. . . What do the directories and data look like in your curinfo directory? I don't remember if that tar problem corrupts it also. Anthony On Fri, 2002-10-04 at 10:26, James Shearer wrote: I get this error every time I run amrecover from a directory that isn't in my disklist, or from a host that isn't the backup server. Try using the sethost, setdisk, and setdate commands in amrecover. Yep. I've tried that before. It's still no good, as you can see: # /usr/local/sbin/amrecover AMRECOVER Version 2.4.2p2. Contacting server on mullet1 ... 220 mullet1 AMANDA index server (2.4.2p2) ready. 200 Access OK Setting restore date to today (2002-10-04) 200 Working date set to 2002-10-04. 200 Config set to DailySet1. 200 Dump host set to mullet1. Can't determine disk and mount point from $CWD amrecover setdisk /usr/local Scanning /export/home/amanda/dumps... 200 Disk set to /usr/local. No index records for disk for specified date If date correct, notify system administrator amrecover setdate 2002-10-04 200 Working date set to 2002-10-04. No index records for cwd on new date Setting cwd to mount point DailySet1 is indeed the config, and mullet1 is the correct host. Here's a snippet of the index file for /usr/local on mullet1 for 10/4: [begin snippet] ./apache/htdocs/ttweb/ ./apache/htdocs/ttweb/docs/ ./apache/htdocs/ttweb/docs/images/ ./apache/htdocs/ttweb/docs/wwhdata/ ./apache/htdocs/ttweb/docs/wwhdata/common/ ./apache/htdocs/ttweb/docs/wwhdata/js/ ./apache/htdocs/ttweb/docs/wwhdata/js/search/ ./apache/htdocs/ttweb/docs/wwhelp/ [end] Again, this is after the perl-fix-up removing the leading numerals. -- UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.
Re: tar, amrecover problems
On Fri, Oct 04, 2002 at 02:26:36PM -0400, James Shearer wrote: I get this error every time I run amrecover from a directory that isn't in my disklist, or from a host that isn't the backup server. Try using the sethost, setdisk, and setdate commands in amrecover. Yep. I've tried that before. It's still no good, as you can see: # /usr/local/sbin/amrecover AMRECOVER Version 2.4.2p2. Contacting server on mullet1 ... 220 mullet1 AMANDA index server (2.4.2p2) ready. 200 Access OK Setting restore date to today (2002-10-04) 200 Working date set to 2002-10-04. 200 Config set to DailySet1. 200 Dump host set to mullet1. Can't determine disk and mount point from $CWD amrecover setdisk /usr/local Scanning /export/home/amanda/dumps... 200 Disk set to /usr/local. No index records for disk for specified date If date correct, notify system administrator amrecover setdate 2002-10-04 200 Working date set to 2002-10-04. No index records for cwd on new date Setting cwd to mount point Had a backup been run on 2002-10-04 when you did this? What if you set it to an earlier date? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
amrecover problems
Can you explain the error on last line (Can't determine disk and mount point from $CWD ) The index shows 20 files had been backup on the tape. But I can not list any file from amrecover bash-2.05# ./amrecover daily AMRECOVER Version 2.4.2p2. Contacting server on bouncer ... 220 bouncer AMANDA index server (2.4.2p2) ready. 200 Access OK Setting restore date to today (2002-06-11) 200 Working date set to 2002-06-11. 200 Config set to daily. 200 Dump host set to bouncer. Can't determine disk and mount point from $CWD Thanks Minh
Re: amrecover problems
Use setdisk to tell amrecover what backup you want to restore from. On Tue, 11 Jun 2002, M. Cao wrote: - - - Can you explain the error on last line (Can't determine disk and mount - point from $CWD ) - - The index shows 20 files had been backup on the tape. But I can not list - any file from amrecover - - - bash-2.05# ./amrecover daily - AMRECOVER Version 2.4.2p2. Contacting server on bouncer ... - 220 bouncer AMANDA index server (2.4.2p2) ready. - 200 Access OK - Setting restore date to today (2002-06-11) - 200 Working date set to 2002-06-11. - 200 Config set to daily. - 200 Dump host set to bouncer. - Can't determine disk and mount point from $CWD - - - - - - Thanks - Minh - - - -- -- Stephen Carville UNIX and Network Administrator DPSI (formerly Ace USA Flood Services) 310-342-3602 [EMAIL PROTECTED]
Amrecover problems.
hi everyone. Well, i have three machines with amanda, my disklist is sc01us0105/ user-tar sc01us0103.cf.jcyl.es / user-tar sc01us0103.cf.jcyl.es /global/datos2/esri-web user-tar sc01us0104.cf.jcyl.es / user-tar where sc01us0105 is the server. When i connect to sc01us0105 from sc01us0103 with amrecover, and set the the disk and the date make a ls, and amrecover list opt/ usr/ but the other files and dirs where are they?, i don't know. Because of this, i can not recover /etc/hosts by example. anyone can help me??, please. --- Javier Fernández Pérez Servicio de Informática Corporativa D.G. de Telecomunicaciones y Transportes Consejería de Fomento - Junta de Castilla y León Rigoberto Cortejoso, 14. 47014 Valladolid (Spain) Telf. 983418958 e-mail: [EMAIL PROTECTED] ---
Re: amrecover problems
On Jun 26, 2001, Olivier Nicole [EMAIL PROTECTED] wrote:
Does it make the things run slower if a program is ALWAYS compiled with -g?
Not when using GCC. In fact, that's the reason why configure uses
CFLAGS=-O2 -g by default, when the compiler is GCC. GCC generates
exactly the same code, regardless of -g, and you can always strip off
debugging information if you wish. Debugging information will only
take up disk space, but since it's not in loadable sections, it won't
even use additional memory when you run the program.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: amrecover problems
Does it make the things run slower if a program is ALWAYS compiled with -g? In general, yes. How much is highly dependent on the program. For instance, if it's I/O bound or always doing system calls, then optimization doesn't buy you much. But it can be very noticeable in surprising places (even things that you think are I/O bound may do more CPU work than you expect). I don't know about specific portions of Amanda (just never tried it). But I'm also not entirely sure how you'd go about coercing autoconf, et al, to change from -O to -g. It's also not needed all that often any more. Most Amanda problems can be diagnosed from the logs and don't need a program debugger. Which is OK since most people don't know (and, because of the stability of modern systems, don't need to know) how to run them. Olivier John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amrecover problems
John R. Jackson wrote: You need to rebuild everything, not just amidxtaped, because of the Amanda libraries it brings in. But you only need to install/test the resulting amidxtaped binary. With --disable-shared involved, it should be self-contained. did a 'make distclean' export CFLAGS=-g ./configure --disabled-shared make copied amidxtaped to /usr/local/libexec, and gave inetd a SIGHUP. Ran amrecover and tried extracting a file... core dump started gdb... atsun04:/tmp/amanda# gdb /usr/local/libexec/amidxtaped core GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as sparc-sun-solaris2.7... Core was generated by `'. Program terminated with signal 11, Segmentation Fault. Reading symbols from /usr/lib/libgen.so.1...done. Loaded symbols for /usr/lib/libgen.so.1 Reading symbols from /usr/lib/libm.so.1...done. Loaded symbols for /usr/lib/libm.so.1 Reading symbols from /usr/lib/libcurses.so.1...done. Loaded symbols for /usr/lib/libcurses.so.1 Reading symbols from /usr/lib/libsocket.so.1...done. Loaded symbols for /usr/lib/libsocket.so.1 Reading symbols from /usr/lib/libnsl.so.1...done. Loaded symbols for /usr/lib/libnsl.so.1 Reading symbols from /usr/lib/libintl.so.1... warning: Lowest section in /usr/lib/libintl.so.1 is .hash at 0074 done. Loaded symbols for /usr/lib/libintl.so.1 Reading symbols from /usr/lib/libc.so.1...done. Loaded symbols for /usr/lib/libc.so.1 Reading symbols from /usr/lib/libdl.so.1...done. Loaded symbols for /usr/lib/libdl.so.1 Reading symbols from /usr/lib/libmp.so.2...done. Loaded symbols for /usr/lib/libmp.so.2 Reading symbols from /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1...done. Loaded symbols for /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1 #0 0xff136dec in strlen () from /usr/lib/libc.so.1 (gdb) bt #0 0xff136dec in strlen () from /usr/lib/libc.so.1 #1 0xff17fe18 in _doprnt () from /usr/lib/libc.so.1 #2 0xff181c40 in vfprintf () from /usr/lib/libc.so.1 #3 0x13b48 in debug_printf (format=0x1bb70 %s: version %s\n) at debug.c:64 #4 0x127a0 in main (argc=0, argv=0xffbefd14) at amidxtaped.c:149 (gdb) break main Breakpoint 1 at 0x12678: file amidxtaped.c, line 98. (gdb) run Starting program: /usr/local/libexec/amidxtaped warning: Lowest section in /usr/lib/libintl.so.1 is .hash at 0074 Breakpoint 1, main (argc=1, argv=0xffbefcd4) at amidxtaped.c:98 98 char *buf = NULL; I did some stepping... and line 104 char *tapename = NULL; ?? Just to make sure that I'm not seeing things... I made sure to run amrecover with -d still NULL. Any help is appreciated apologies for the newbieness here on debugging c code, as I don't do this all too often ;) thanks, \Ben John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amrecover problems
#3 0x13b48 in debug_printf (format=0x1bb70 %s: version %s\n) at debug.c:64 #4 0x127a0 in main (argc=0, argv=0xffbefd14) at amidxtaped.c:149 Oh, that problem. You're inetd.conf line is probably wrong. I'm betting you forgot to put amidxtaped twice, e.g.: amidxtape stream tcp nowait backup /opt/amanda/libexec/amidxtaped amidxtaped Without that trailing amidxtaped, argv[0] is NULL and that's why the dbprintf failed. \Ben John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amrecover problems
John R. Jackson wrote: You're inetd.conf line is probably wrong. I'm betting you forgot to put amidxtaped twice, e.g.: You are correct argh! always the small details ;) amidxtape stream tcp nowait backup /opt/amanda/libexec/amidxtaped amidxtaped Without that trailing amidxtaped, argv[0] is NULL and that's why the dbprintf failed. Understood. Thanks again for the help on this. \Ben John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amrecover problems
John R. Jackson wrote: That's not enough information to go on, but is the critical piece of the puzzle. Please recompile amidxtaped with -g and reinstall it, then see if you can get a traceback with actual routine names and line numbers. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] Finally I have some time to start working on this problem again ;) Okay I have modified CFLAGS in restore-src/Makefile -g and recompiled. The end result is a file size not much bigger than amidxtaped without debug. Shouldn't amidxtaped with debug be substantially bigger? Ran an amrecover session, and upon extract I get the core dump. Fire up gdb and load the core. Bt gives me the same info not very helpful :( #0 0xff136dec in ?? () (gdb) bt #0 0xff136dec in ?? () #1 0xff181c40 in ?? () #2 0x12e8c in main () #3 0x12460 in main () Solaris 8 gcc version 2.8.1 gmake 3.79.1 gdb 5.0 I'm sure this is pilot error on my part Thanks, \Ben
Re: amrecover problems
Okay I have modified CFLAGS in restore-src/Makefile -g and recompiled. The end result is a file size not much bigger than amidxtaped without debug. Shouldn't amidxtaped with debug be substantially bigger? Probably. It's not easy getting Amanda compiled with debugging in the GNU autoconf/libtool magic environment. Here's what I do: * Start from scratch, i.e. make distclean or remove config.cache and all the .o files. * Before you run ./configure, set the CFLAGS environment variable to -g, e.g.: env CFLAGS=-g ./configure ... * Use --disabled-shared. You need to rebuild everything, not just amidxtaped, because of the Amanda libraries it brings in. But you only need to install/test the resulting amidxtaped binary. With --disable-shared involved, it should be self-contained. \Ben John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Amrecover problems
Hi, Amrecover wants a reserved port (=1024) for itself. Seems like you have to rebuild it ;-). (Dunno *why*, but it does...) Regards, Arjan Nate Burton wrote: I was able to run amdump and it appears that everything ran and backed up correctly, based on the logs and the Amanda report. Now I am trying to test and see if I can recover some files. When I run amrecover it is not connecting: admin2 is the client, admin1 is the server [root@admin2 amanda]# /usr/local/amanda/sbin/amrecover -C TestSet -s admin1.airscorp.com -t admin1.airscorp.com -d /dev/nst0 AMRECOVER Version 2.5.0. Contacting server on admin1.airscorp.com ... amrecover: did not get a reserved port: 50012 [root@admin2 amanda]# cat /tmp/amanda/amrecover.20010612111330.debug amrecover: debug 1 pid 8340 ruid 0 euid 0 start time Tue Jun 12 11:13:30 2001 amrecover: stream_client: connected to 10.0.4.91.10082 amrecover: stream_client: our side is 0.0.0.0.50012 did not get a reserved port: 50012 amrecover: pid 8340 finish time Tue Jun 12 11:13:30 2001 I believe I have setup the .amandahosts file correctly, I added a line for admin2 with the user 'root' on the server admin1. Amanda was built with '--with-portrange=5,50020' and it appeared to use those ports correctly when the backup was being performed, but why can it not get the reserved port now? The systems are admin1(Redhat 6.2), admin2(Redhat 7.1), Amanda cvs code from 6/04/01. Thanks
Re: Amrecover problems
AMRECOVER Version 2.5.0. Contacting server on admin1.airscorp.com ... amrecover: did not get a reserved port: 50012 Yup, that appears to be broken. You do understand, don't you, that 2.5 is the development version and only folks prepared to do serious debugging on their should go down path, right? I'll take a look, but I suspect it'll get deep into the new security framework, and I get really lost in there. The old code would try for a reserved port first, which, since amrecover runs as root, should have worked. Only if that failed would it fall back to the port range or any unreserved port. I'm guessing it's now going for the port range first. The problem is, I'm not sure whether that's a good thing or a bad thing. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Amrecover problems
I don't mind working with the development version. I did get it working, on the suggestion of someone else, I recompiled with the portrange = 1024 and everything works fine. Thanks Nathanael Burton On Wednesday 13 June 2001 16:11, John R. Jackson wrote: AMRECOVER Version 2.5.0. Contacting server on admin1.airscorp.com ... amrecover: did not get a reserved port: 50012 Yup, that appears to be broken. You do understand, don't you, that 2.5 is the development version and only folks prepared to do serious debugging on their should go down path, right? I'll take a look, but I suspect it'll get deep into the new security framework, and I get really lost in there. The old code would try for a reserved port first, which, since amrecover runs as root, should have worked. Only if that failed would it fall back to the port range or any unreserved port. I'm guessing it's now going for the port range first. The problem is, I'm not sure whether that's a good thing or a bad thing. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Amrecover problems
I was able to run amdump and it appears that everything ran and backed up correctly, based on the logs and the Amanda report. Now I am trying to test and see if I can recover some files. When I run amrecover it is not connecting: admin2 is the client, admin1 is the server [root@admin2 amanda]# /usr/local/amanda/sbin/amrecover -C TestSet -s admin1.airscorp.com -t admin1.airscorp.com -d /dev/nst0 AMRECOVER Version 2.5.0. Contacting server on admin1.airscorp.com ... amrecover: did not get a reserved port: 50012 [root@admin2 amanda]# cat /tmp/amanda/amrecover.20010612111330.debug amrecover: debug 1 pid 8340 ruid 0 euid 0 start time Tue Jun 12 11:13:30 2001 amrecover: stream_client: connected to 10.0.4.91.10082 amrecover: stream_client: our side is 0.0.0.0.50012 did not get a reserved port: 50012 amrecover: pid 8340 finish time Tue Jun 12 11:13:30 2001 I believe I have setup the .amandahosts file correctly, I added a line for admin2 with the user 'root' on the server admin1. Amanda was built with '--with-portrange=5,50020' and it appeared to use those ports correctly when the backup was being performed, but why can it not get the reserved port now? The systems are admin1(Redhat 6.2), admin2(Redhat 7.1), Amanda cvs code from 6/04/01. Thanks
Re: amrecover problems
A nice core file exists as well :( GDB and backtrace of the core I get the following: Core was generated by `'. Program terminated with signal 11, Segmentation Fault. #0 0xff136dec in ?? () (gdb) where #0 0xff136dec in ?? () #1 0xff181c40 in ?? () #2 0x12e8c in main () #3 0x12460 in main () That's not enough information to go on, but is the critical piece of the puzzle. Please recompile amidxtaped with -g and reinstall it, then see if you can get a traceback with actual routine names and line numbers. Ben John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amrecover problems
What's in amidxtaped.debug on amanda??? Nothing that tells me anything, that's the problem. But it might mean something to someone else. :-) I currently have a restore going, so as soon as it finishes, I'll rerun it and let you know. OK. One question I have though is, should I have to manually load each tape into the drive (by manually, I mean using 'amtapee config slot X') or should I just be able to answer 'Y' when it asks me "Load next tape now" and expect amanda to find the correct tape in the changer library? Loading "by hand" is, unfortunately, the current technique. Amidxtaped (what amrecover uses to process the tapes) uses amrestore to process the tape. Amrestore doesn't know about changers or anything else in an Amanda configuration (it's meant to be a stand alone utility). And amidxtaped was never taught about them, either. There is a discussion going on right now in amanda-hackers about the changes needed to get this to behave better. Feel free to join in :-). Paul John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amrecover problems
EOF, check amidxtaped.debug file on amanda. Would it help if we made this message 72 point, bold and rang the bell? :-) :-) What's in amidxtaped.debug on amanda??? Paul John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amrecover problems
In a message dated: Sat, 25 Nov 2000 17:09:24 EST "John R. Jackson" said: EOF, check amidxtaped.debug file on amanda. Would it help if we made this message 72 point, bold and rang the bell? :-) :-) Probably not, but it might be a fun touch to add ;) What's in amidxtaped.debug on amanda??? Nothing that tells me anything, that's the problem. I currently have a restore going, so as soon as it finishes, I'll rerun it and let you know. Interestingly enough, I tried the following to get to the 2nd tape, and it seems to work (well, it's still running, anyway :) - Placed tape 1 in the drive - Answered 'Y' to Load 1st tape now question - Let the restore of tape 1 run. - At the end, when it asked if it should load 2nd tape I loaded 2nd tape (in a second window with amtape) - Answered 'Y' to the Load 2nd tape now question - It failed with: EOF, check amidxtaped.debug file on amanda. amrecover: short block 0 bytes UNKNOWN file amrecover: Can't read file header extract_list - child returned non-zero status: 1 - I answered 'N' to Continue - re-added the path I wanted to restore - typed extract - Answered 'Y' to Load 1st tape question - It failed (obviously, wrong tape in drive - Answered 'Y' to Load 2nd tape now question - It's still extracting from 2nd tape Don't know what's going to happen when it's ready for the 3rd tape. I'm assuming the same cycle will work. One question I have though is, should I have to manually load each tape into the drive (by manually, I mean using 'amtapee config slot X') or should I just be able to answer 'Y' when it asks me "Load next tape now" and expect amanda to find the correct tape in the changer library? Thanks, -- Seeya, Paul I'm in shape, my shape just happens to be pear! If you're not having fun, you're not doing it right!
