Re: Backup Server will not back itself up.
On Monday July 28 2003 12:27 am, you wrote: > Stephen Carville wrote: > > About a week ago, my backup server stopped backing itself up: > > ... > > > GNUTAR //snap01/development 0 1970:1:1:0:0:0 -1 > > exclude-file=Temporary\ \(Not\ Backed\ Up\!\) > > Exclude/Include list with spaces in the names do > not work (yet). I have a (very ugly!) patch if urgent. > But the good fix is much more difficult. > See: http://groups.yahoo.com/group/amanda-hackers/message/3761 That was/is the problem. I had the same problem with spaces in file names a while back and I thought escaping them with a backslash fixed it. Next I'm going to try: exclude = "Temorary??Not?Backed?Up??" > ... > > > FORMAT ERROR IN REQUEST PACKET > > ... > > > REQ packet is bogus: extra text at end -- Stephen Carville http://www.heronforge.net/~stephen/gnupgkey.txt -- Mom & Pop were just a couple of kids when they got married. He was eighteen, she was sixteen and I was three." -- Billie Holiday
Re: chg-manual bug?
On Monday 28 July 2003 20:27, Matthias Bethke wrote:
>Hi Gene,
>
>on Monday, 2003-07-28 at 16:25:00, you wrote:
>> >Hmm...I was a bit surprised about this value already, but
>> > according to both the DIP switch and mt, compression is off.
>>
>> First, mt doesn't know or report on its setting, it can only issue
>> the commands. Amtapetype has an option to check it, by doing some
>> sort of a destructive write, see man amtapetype for details.
>
>"man mt" tells me it could ("Inquire or set the compression status
>(on/off)"), and here it correctly reports the hardware setting on
> the drive.
Hmm, a simple 'mt -f /dev/nst0 compression' just returns a prompt
here. Ditto for defcompression. What version of mt-st do you have?
>> >Can amanda be told to use bzip2? This P3 is far from fully loaded
>> > with its job as a WLAN router and fileserver, and as it cannot
>> > be clocked down to save some energy, it might as well do
>> > something useful for the calories it burns :)
>>
>> Not that I know of Mathias. When bzip2 settles down to the no
>> mistakes in a year category, it might, but that hasn't happened
>> just yet, it still makes mistakes in decoding from time to time,
>> mistakes you can't get it to repeat willingly either.
>
>OK, that's a point. Seems I've just ben lucky so far.
>
>> Its also a heck of a lot (like maybe 5x?) slower than gzip when
>> both are running at maximum compression. And even gzip 'best' is
>> only of use on 1 gigahertz and up machines.
>
>Oh, I've been using it since the A4000/68040/40 days -- but then
> there were also much smaller amounts of data to crunch :) For
> incrementals I'd still consider using it.
So have I Matthias, and I thought that name looked a bit familiar!
But my 68040 lived on a PP&S card with 64 megs of ram in a 2000. And
you are right, on that 28 mhz 68040, gzip and bzip2 were similar
enough in speeds that you often had to replay the command line to see
which you used. And what do you mean, smaller data? My last drive
in that amiga was 30 gigger, pretty well filled up too.
Anyway, I base that statement pretty much on some of my experiences
unpacking kernels and patches here, I've literally had it silently
skip whole subdirs in unpacking a kernel src tarball on 20 or so
occasions over the last 5 years. There was a flurry of bz2
developement about 2 years ago, and it got better, but its not quite
'bulletproof' in that regard yet, it was only maybe 2 months ago when
I couldn't get a kernel to build, and the error was different each
time I ran the same script, which basicly blew away the srcs, and
unpacked a fresh copy of both the src and the patches. I finally
went and got the tar.gz versions of everything, it worked, and I've
not had any similar problems with the use of gzip.
>regards
> Matthias
--
Cheers, Gene
AMD [EMAIL PROTECTED] 320M
[EMAIL PROTECTED] 512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Re: Setting up chg-scsi
On Monday 28 July 2003 20:07, Joshua D. Bello wrote: >runtapes 1 # number of tapes to be used in a single run >tpchanger "chg-scsi"# the tape-changer glue script >tapedev "/dev/nsa0" # the no-rewind tape device to be used >rawtapedev "/dev/nrsa0" # the raw device to be used (ftape only) >changerfile "/usr/local/etc/amanda/daily/chg-scsi.conf" >changerdev "/dev/ch0" The *real* tapedev(ice) is specified in chg-scsi.conf, here in amanda.conf, the proper useage is a number from 0 to whatever, that represents the index number of the configurations present in chg-scsi.conf. It can contain more than one set of specs, and you must specify here, which it is to use from the (possible) choices in chg-scsi.conf. As I only have one config spelled out in chg-scsi.conf, it is tapedev "0" in my amanda.conf. Likewise, and as it clearly says, define only one, so the rawtapedev line, the whole thing should be commented out. Ditto for changerdev, that also is properly spec'd in chg-scsi.conf, in the configuration number referenced above. chg-scsi.conf should start out resembling this: - number_configs 1 eject 0 # Tapedrives need an eject command sleep 13 # Seconds to wait until the tape gets ready cleanmax100 # How many times could a cleaning tape be used -- Then each of these 'configurations' in chg-scsi.conf will look something like this, bearing in mind mine is a linux box so the devices shown are 'linux' devices -- # # Next comes the data for drive 0 # config 0 drivenum0 dev /dev/nst0 # the device that is used for the tapedrive 0 startuse0 # The slots associated with the drive 0 enduse 3 # statfile/usr/local/etc/amanda/tape-slot # The file where the actual slot is stored #cleancart 3 # the slot where the cleaningcartridge for drive 0 is located #cleanfile /usr/local/etc/amanda/tape-clean # The file where the cleanings are recorded usagecount /usr/local/etc/amanda/totaltime # This is the end --- The next one would start out as 'config 1' etc.. -- Cheers, Gene AMD [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 512M 99.27% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Re: selfcheck timeout after a week of troubleshooting, on just one client out of many
On Mon, Jul 28, 2003 at 04:58:29PM -0500, Martin, Jeremy wrote:
> My amanda server is having problems connecting to a client. It's working great with
> a number of other clients, but this one client keeps trying to frustrate me.
> [awesomely complete situation report deleted]
>
> Any ideas of other things to try? Thanks!
You've already tried all the usual things that bite me. Ok, here
are some unusual ones :-)
Can you increase xinetd's verbosity, so that it logs all
connection attempts?
Your mention of /etc/hosts.allow suggests that tcpwrappers is in
the mix. I've never used it, but one of its man pages (tcpd(8))
says it logs all requests. What do those logs say?
How about tcpdump?
Better yet, check out Ethereal (www.ethereal.com). GUI, GPL, can
follow and reassemble TCP streams ... and it reads tcpdump's
raw-capture files ("tcpdump -w file"), so you can use it even if
you don't want to install it on the boxes in question, and
network topology keeps you from sniffing the packets from the
machine where Ethereal does reside.
Try strace'ing xinetd (if you use "-p pid", you won't have to
kill and restart xinetd). See if it tries to fork off an amandad
process (you'll need to run it with -f to see the child process's
exec() system call). If not, see whether it was able to read the
UDP packet. Those two answers will tell you where to look more
deeply -- at the TCP/IP side of things, xinetd itself, or
amandad.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
When I came back around from the dark side, there in front of me would
be the landing area where the crew was, and the Earth, all in the view
of my window. I couldn't help but think that there in front of me was
all of humanity, except me.
- Michael Collins, Apollo 11 Command Module Pilot
Re: chg-manual bug?
Hi Gene,
on Monday, 2003-07-28 at 16:25:00, you wrote:
> >Hmm...I was a bit surprised about this value already, but according
> > to both the DIP switch and mt, compression is off.
>
> First, mt doesn't know or report on its setting, it can only issue the
> commands. Amtapetype has an option to check it, by doing some sort
> of a destructive write, see man amtapetype for details.
"man mt" tells me it could ("Inquire or set the compression status
(on/off)"), and here it correctly reports the hardware setting on the
drive.
> >Can amanda be told to use bzip2? This P3 is far from fully loaded
> > with its job as a WLAN router and fileserver, and as it cannot be
> > clocked down to save some energy, it might as well do something
> > useful for the calories it burns :)
>
> Not that I know of Mathias. When bzip2 settles down to the no
> mistakes in a year category, it might, but that hasn't happened just
> yet, it still makes mistakes in decoding from time to time, mistakes
> you can't get it to repeat willingly either.
OK, that's a point. Seems I've just ben lucky so far.
> Its also a heck of a lot (like maybe 5x?) slower than gzip when both
> are running at maximum compression. And even gzip 'best' is only of
> use on 1 gigahertz and up machines.
Oh, I've been using it since the A4000/68040/40 days -- but then there
were also much smaller amounts of data to crunch :) For incrementals I'd
still consider using it.
regards
Matthias
Setting up chg-scsi
I'm hoping that somebody out there with more experience with setting up
chg-scsi could help point out the cause of my misconfiguration. In
attempting to use chg-scsi on my 15-tape changer, I suffer from the
following errors:
[EMAIL PROTECTED]:/usr/local/etc/amanda/daily$ amcheck daily
Amanda Tape Server Host Check
-
Holding disk /ambackup/daily: 109239520 KB disk space available, that's
plenty
amcheck-server: could not get changer info: check your config and use an
config file for chg-scsi
Amanda Backup Client Hosts Check
Client check: 15 hosts checked in 0.988 seconds, 0 problems found
(brought to you by Amanda 2.4.3b2)
[EMAIL PROTECTED]:/usr/local/etc/amanda/daily$
Similar command calls direct to chg-scsi (such as -status robot) results
in the same errors. The only working command is "chg-scsi -genconf",
which I used to create a configuration file, chg-scsi.conf. This config
file is owned by the ambackup users with appropriate read/write perms:
-rw-r--r-- 1 ambackup ambackup 2564 Jul 28 15:06 chg-scsi.conf
When running the chg-scsi command, the entire debug output consists of:
chg-scsi: debug 1 pid 92238 ruid 10080 euid 10080 start time Mon Jul 28
16:55:52 2003
chg-scsi: $Id: chg-scsi.c,v 1.6.2.22.2.7.2.2 2001/12/30 17:26:22
martinea Exp $
ARG [0] : /usr/local/libexec/amanda/chg-scsi
ARG [1] : -info
My amanda.conf file is configured to point at this config file location.
Attached are the chg-scsi.conf and amanda.conf files.
I am using Amanda 2.4.4 on FreeBSD 4.8-STABLE.
Thanks in advance!
--
Joshua D. Bello <[EMAIL PROTECTED]>
Systems Administrator
Nextrials, Inc. +1-925-415-8957
#$Id: amanda.conf,v 1.10 2003/07/25 17:49:53 josh Exp $
org "nextrials" # your organization name for reports
mailto "[EMAIL PROTECTED]" # space separated list of operators at your site
dumpuser "ambackup" # the user to run dumps under
inparallel 4# maximum dumpers that will run in parallel (max 63)
# this maximum can be increased at compile-time,
# modifying MAX_DUMPERS in server-src/driverio.h
dumporder "sssS"# specify the priority order of each dumper
# s -> smallest size
# S -> biggest size
# t -> smallest time
# T -> biggest time
# b -> smallest bandwitdh
# B -> biggest bandwitdh
# try "BTBTBTBTBTBT" if you are not holding
# disk constrained
netusage 60 Kbps # maximum net bandwidth for Amanda, in KB per sec
dumpcycle 7 days# the number of days in the normal dump cycle
runspercycle 7 # the number of amdump runs in dumpcycle days
# (6 weeks * 7 amdump runs per week -- just weekdays)
tapecycle 45 tapes # the number of tapes in rotation
# 6 weeks (dumpcycle) times 7 tapes per week
# plus a few to handle errors that
# need amflush and so we do not overwrite the full
# backups performed at the beginning of the previous
# cycle
bumpsize 500 Mb # minimum savings (threshold) to bump level 1 -> 2
bumpdays 1 # minimum days at each level
bumpmult 4 # threshold = bumpsize * bumpmult^(level-1)
etimeout 300# number of seconds per filesystem for estimates.
#etimeout -600 # total number of seconds for estimates.
dtimeout 1800 # number of idle seconds before a dump is aborted.
ctimeout 30 # maximum number of seconds that amcheck waits
# for each client host
tapebufs 20
runtapes 1 # number of tapes to be used in a single run of amdump
tpchanger "chg-scsi"# the tape-changer glue script
tapedev "/dev/nsa0" # the no-rewind tape device to be used
rawtapedev "/dev/nrsa0" # the raw device to be used (ftape only)
changerfile "/usr/local/etc/amanda/daily/chg-scsi.conf"
changerdev "/dev/ch0"
tapetype SDLT320 # what kind of tape it is (see tapetypes below)
labelstr "^DAILY[0-9][0-9][0-9][0-9]*$" # label constraint regex: all tapes must match
holdingdisk hd1 {
comment "main holding disk"
directory "/ambackup/daily" # where the holding disk is
use 100Gb # how much space can we use on it
# a non-positive value means:
#use all space but that value
chunksize 5Gb # size of chunk if you want big dump to be
# dumped on multiple files on holding disks
# N Kb/Mb/Gb split images in chunks of size N
# The maximum value should be
# (MAX_FILE_SIZE - 1Mb)
# 0 same
DOGA YA SAYGI, EKONOMI YE KATKI
Title: kartus.org Maili göremiyorsanýz buraya týklayýnýz. DOÐA YA SAYGI, EKONOMÝ YE KATKI BOÞ KARTUÞLARINIZI ATMAYINIZ ÝSTERSENÝZ SATIN ALALIM ÝSTERSENÝZ 100 % GARANTÝLÝ OLARAK DOLDURUP YENÝLEYELÝM KALÝTE, PERFORMANS, GERÇEK GARANTÝFAKS KAÐITLARI, FOTOKOPÝ TONERLERÝ, FAKS FÝLMLERÝ, YAZICI ÞERÝTLERÝ VE MUADÝL KARTUÞLARIN SATIÞINA DEVAM EDÝYORUZ ÜCRETSÝZ ADRESÝNÝZE TESLÝM EDÝYORUZ HABERLER Çalýnan Cep Telefonlarý Bulunabilecek mi? Çalýnan cep telefonlarýna GSM firmalarý tarafýndan, Bu telefon çalýntýdýr mesajý gönderilecek. Ankara Cumhuriyet Baþsavcýlýðý tarafýndan bugünden itibaren baþlatýlan uygulama, þimdilik Turkcell ve Aycell abonelerini kapsýyor. Bundan böyle, Ankarada cep telefonu çalýnan kiþi cep telefonunun IMEI kodunu Ankara Savcýlýðýna bildirecek. Savcýlýk da bu bilgileri GSM firmalarýna iletecek. Böylece çalýntý telefonu kulanan kiþi kartýný takmaya baþladýðý anda telefonun ekranýnda Bu çalýntýdýr ibaresini görülecek. Kasýrga bu konuda Böylece ikinci el cep telefonu kullanan kiþilerin baþlarý derde girmeyecek. Ýkinci el telefonlarýnýn cazip olmayacaðýný hýrsýzlar artýk anlasýnlar. Her konuda önemli misyon yüklenen Ankara Adliyesinin bu konuda da diðer Adliyelere örnek olacaðýna inanýyorum dedi. Þimdi hemen, cep telefonunuzun IMEI numarasýný yýldýz, kare, 06, kare tuþlarýna basarak, bulun ve bir yerlere not ediniz. Ýnternet bitti: IPv6e geçiyoruz Pentagon yeni kuþak Internet Protokolüne geçilmesi için harekete geçti. 128-bit standardýna sahip olan yeni Internet Protokolü, milyarlarca internet adresini destekleyecek kapasiteye sahip. ABD Savunma Bakanlýðý Pentagon Global Information Grid (Global Bilgi Þebekesi) programý çerçevesindeki tüm katýlýmcýlarýn 1 Ekim 2003 itibariyle Internet Protocol version 6 (IPv6)ya geçmelerini talep ediyor. IPv6nin halen kullanýmda bulunan 32-bitlik IPv4ün yerini en geç 2008 itibariyle almasý bekleniyor. Yeni protokole geçiþ, þimdiki internet adreslerini tükenmekte olduðu düþünülürse vazgeçilmez olarak görülüyor. Bilgisayar kullanmanýn püf noktalarý Bilgisayarda yazý yazarken gözlerin monitörden ayrýlmamasýnýn gözün bozulmasýnda etkin olduðu iddia edildi. Selçuk Üniversitesi Teknik Bilimler Meslek Yüksek Okulu Müdürü Prof. Dr. Hüseyin Öðüt, bilgisayarda yazý yazarken gözlerin monitörden ayrýlmamasýnýn, gözün bozukluk derecesini artýrdýðýný söyledi.Bilgisayarda yazý yazarken gözlerin ekrandan ayrýlmamasý, göz bozukluk derecesini artýrýr dedi. Kitap ya da tez gibi belli kaynaklar aktarýlýrken bilgisayarda hýzlý, doðru ve saðlýklý yazý yazabilmek için bilgisayar klavyesine deðil, yazý materyaline bakýlmasýnýn doðru olacaðýný vurgulayan Prof. Dr. Öðüt, þunlarý kaydetti: Bilgileri bir baþka kaynaktan bakarak deðil, doðaçlama olarak yazýyorsanýz, klavyeye bakmak daha doðrudur. Alýþkanlýk nedeniyle sürekli deðil, aralýklý olarak ekrana bakýn. Bir cümle veya paragraf yazýldýktan sonra ekrana bakýlmasý en doðru olanýdýr. Sürekli bilgisayar kaynaklý göz bozukluklarýnda en yüksek risk grubunu ise bilgisayar operatörleri ve sekreterler oluþturuyor. size kartus.org aylýk haber bültenini göndermemizi istemiyorsanýz [EMAIL PROTECTED] adresine konu baþlýðýný deðiþtirmeden mail atmanýz yeterli. Bu mesajda, yalnýzca muhatabýný ilgilendiren, kiþiye veya kuruma özel bilgiler yer alýyor olabilir. Mesajýn muhatabý deðilseniz, içeriðini ve varsa ekindeki dosyalarý kimseye aktarmayýnýz ya da kopyalamayýnýz. Boyle bir durumda lutfen gondereni uyarýp, mesaji imha ediniz. Göstermiþ oldugunuz hassasiyetten ötürü teþekkür ederiz.This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Thank you for your co-operation.
Re: Dell Powervault 120T
On Monday 28 July 2003 18:02, Russell Adams wrote:
>> >Here's the output from tapetype.
>>
>> Here is the clue that counts, your install is old, its been named
>> amtapetype for about a year now and now has facilities to detect
>> the drives compression status. And I'd suspect, from the results
>> you are getting that the drives own hardware compressor is on, and
>> that the data from /dev/urandom is growing quite a bit in the
>> hardware compressor.
>
>You are correct. I'm running Amanda 2.4.3.
>
>However! ;]
>
>I compiled 2.4.4p1 specifically for the _newest_ tapetype (now
> called amtapetype) because I thought my results were wrong! Ha! ;]
> That new amtapetype stopped at 27G as well.
>
>Please note there was a dramatic change in the output for
>(am)tapetype, including the weird new estimate stuff and compression
>detection. The 2.4.3 tapetype doesn't do that.
>
>Lastly, here's the output from 'mt status'.
>
>SCSI 2 tape drive:
>File number=0, block number=0, partition=0.
>Tape block size 0 bytes. Density code 0x1b (DLT 35GB).
>Soft error count since last status=0
>General status bits on (4101):
> BOT ONLINE IM_REP_EN
>
>It's got the right density code, and I've repeatedly run 'mt
>compression off'. I still don't understand why I can't get more than
> 27G.
>
>> >Writing 128 Mbyte compresseable data: 28 sec
>> >Writing 128 Mbyte uncompresseable data: 28 sec
>> >Estimated time to write 2 * 1024 Mbyte: 448 sec = 0 h 7 min
>> >wrote 860664 32Kb blocks in 2632 files in 24789 seconds (short
>> > write) wrote 855261 32Kb blocks in 5247 files in 33707 seconds
>> > (short write) define tapetype unknown-tapetype {
>> >comment "just produced by tapetype prog (hardware compression
>> >off)
>> >length 27065 mbytes
>> >filemark 66 kbytes
>> >speed 961 kps
>> >}
>
>Russell
That is indeed odd, and I'm afraid I'll have to defer to those who
have that drive. It certainly doesn't look right, thats for sure.
--
Cheers, Gene
AMD [EMAIL PROTECTED] 320M
[EMAIL PROTECTED] 512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Re: Dell Powervault 120T
> >Here's the output from tapetype.
>
> Here is the clue that counts, your install is old, its been named
> amtapetype for about a year now and now has facilities to detect the
> drives compression status. And I'd suspect, from the results you are
> getting that the drives own hardware compressor is on, and that the
> data from /dev/urandom is growing quite a bit in the hardware
> compressor.
You are correct. I'm running Amanda 2.4.3.
However! ;]
I compiled 2.4.4p1 specifically for the _newest_ tapetype (now called
amtapetype) because I thought my results were wrong! Ha! ;] That new
amtapetype stopped at 27G as well.
Please note there was a dramatic change in the output for
(am)tapetype, including the weird new estimate stuff and compression
detection. The 2.4.3 tapetype doesn't do that.
Lastly, here's the output from 'mt status'.
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x1b (DLT 35GB).
Soft error count since last status=0
General status bits on (4101):
BOT ONLINE IM_REP_EN
It's got the right density code, and I've repeatedly run 'mt
compression off'. I still don't understand why I can't get more than 27G.
> >Writing 128 Mbyte compresseable data: 28 sec
> >Writing 128 Mbyte uncompresseable data: 28 sec
> >Estimated time to write 2 * 1024 Mbyte: 448 sec = 0 h 7 min
> >wrote 860664 32Kb blocks in 2632 files in 24789 seconds (short
> > write) wrote 855261 32Kb blocks in 5247 files in 33707 seconds
> > (short write) define tapetype unknown-tapetype {
> >comment "just produced by tapetype prog (hardware compression
> >off)"
> >length 27065 mbytes
> >filemark 66 kbytes
> >speed 961 kps
> >}
Russell
selfcheck timeout after a week of troubleshooting, on just one client out of many
Hi,
My amanda server is having problems connecting to a client. It's working great with a
number of other clients, but this one client keeps trying to frustrate me.
I have developed a little step by step procedure for installing amanda clients on my
servers so I can quickly copy/paste most things to avoid mistake. Let me preface this
by saying I used the same self-made guide for setting up a bunch of other clients, as
well as this problem client... and the other ones are working great (one RedHat 7.1
servers, multiple RedHat 9 servers, and a few RedHat 7.3 servers as well).
There are 2 firewalls inbetween the client and the server. The client (a RedHat 7.3
box) was running iptables, but since we have it behind a hardware firewall I've even
tried doing "iptables --flush" and the problem remains with iptables wide open (the
default is set to ACCEPT).
In the server's firewall, I've turned on full logging and doing see anything being
logged at all. If I try a client-side-restore (even though the client has never been
backed up before), it works ok and lets me connect to the server, and I see
appropriate entries in the server's firewall's logs.
However every time I try doing amcheck, the client's self check times out.
Here's what I see in the client's firewall's logs when I attempt to amcheck it. (the
public IP's have been changed)
Date/Time: 2003-07-28 15:26:16
Source Address/Port: 1.2.3.4:694
Translated Address/Port: 1.2.3.4:694
Destination Address/Port: 192.168.250.120:10080
Service: UDP PORT 10080
Duration: 3 sec.
Bytes Sent: 163
Bytes Received: 191
Every time it's the same.. 163 bytes sent, 191 bytes received, but still the amcheck
says "host down?"
Here is the ./configure I'm using on the clients: ./configure --with-user=amanda
--with-group=amanda --with-amandahosts --prefix=/usr/local --with-config=Daily
--without-server --with-tcpportrange=44200,44209 --with-udpportrange=790,799
On the client, /etc/hosts has an entry for the server, "theisland"... /etc/hosts.allow
is set up properly (amanda : theisland : ALLOW), /etc/services contains all of my
custom UDP and TCP ports as well as the defaults of 10080 (tcp/udp), 10082 and 10083
(tcp)...
This is my xinetd.conf entry for amanda:
service amanda
{
socket_type = dgram
protocol = udp
user = amanda
server = /usr/local/libexec/amandad
wait = yes
}
(I've heard some people suggest putting "disable = no" in there but when I do, the
system complains that it's not a valid entry, so I've removed it)
lsof shows that amanda is listening... though I don't recognize the numbers, it
shouldn't really matter since the firewalls are currently set up to allow all traffic
between the amanda server and this client.
xinetd 876 root5u IPv4 1393 UDP *:amanda
I can run amandad as the amanda user and it doesn't give me any errors. When I run it,
it does create a /tmp/amanda/amandad.*.debug file... However when I try to run amcheck
on the server, it doesn't ever create any /tmp/amanda/ debug files. amanda:amanda does
own /tmp/amanda and has permission to create files there..
I did "service xinetd reload" "service xinetd restart".. as well as rebooted the
entire machine..
No error messages in /var/log/messages or /var/log/secure that I can see.
/home/amanda/.amandahosts is set up... "theisland amanda"
/home/amanda's permissions are correct.. as are the permissions in
/usr/local/var/amanda
On the server I do see a lot of these entries in /var/log/messages:
Jul 28 05:47:51 theisland kernel: (see the NOTES section of 'man 2 wait'). Workaround
activated.
Jul 28 05:55:16 theisland kernel: application bug: dumper(20085) has SIGCHLD set to
SIG_IGN but calls wait().
Jul 28 05:55:16 theisland kernel: (see the NOTES section of 'man 2 wait'). Workaround
activated.
However I've done some Google searches and these appear to be harmless, plus the fact
that the other servers are being backed up just fine, so I'm not too worried about
that.
I've read through the Amanda FAQ many times, including the multiple entries about the
"selfcheck timeout, host down?" message, but still haven't had any luck.
Just to make sure it wasn't a hardware firewall issue I completely opened up traffic
between the server and this problematic client on both firewalls (with full logging
turned on) and haven't noticed anything more in the logs compared to when I had it
restricted to specific ports (tcp 44200-44300 10080 10082 10083, and udp 10080 /
790-799).
Any ideas of other things to try? Thanks!
Jeremy Martin
Re: Dell Powervault 120T
On Monday 28 July 2003 11:07, Russell Adams wrote:
>I can't seem to get tapetype to agree to the rated capacity of my
>Powervault 120T (DLT 7000 35G native).
>
>The maximum uncompresses that tapetype registers is about 27G.
>
>Running 'mt status' returns a density code for 35G.
>
>Any ideas why I can't detect the full tape?
>
>Here's the output from tapetype.
Here is the clue that counts, your install is old, its been named
amtapetype for about a year now and now has facilities to detect the
drives compression status. And I'd suspect, from the results you are
getting that the drives own hardware compressor is on, and that the
data from /dev/urandom is growing quite a bit in the hardware
compressor.
>Writing 128 Mbyte compresseable data: 28 sec
>Writing 128 Mbyte uncompresseable data: 28 sec
>Estimated time to write 2 * 1024 Mbyte: 448 sec = 0 h 7 min
>wrote 860664 32Kb blocks in 2632 files in 24789 seconds (short
> write) wrote 855261 32Kb blocks in 5247 files in 33707 seconds
> (short write) define tapetype unknown-tapetype {
>comment "just produced by tapetype prog (hardware compression
>off)"
>length 27065 mbytes
>filemark 66 kbytes
>speed 961 kps
>}
>
>Russell
--
Cheers, Gene
AMD [EMAIL PROTECTED] 320M
[EMAIL PROTECTED] 512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Re: strange "disk offline" error
So it looks like this has something to do with me compiling this on SCO. I've asked my local "knowledgeable SCO guy" and he gave me an explanation that I don't understand but perhaps one of the coders would. Should I direct this thread to amanda-hackers instead? Kurt Yoder said: > More information about this problem: > > Looking more closely in /tmp/amanda/sendsize...debug, I see > something strange: > > sendsize[7578]: time 0.020: calculating for amname '/', dirname '/', > spindle -1 > sendsize[7578]: time 0.020: getting size via dump for / level 0 > sendsize[7578]: time 0.020: calculating for device '/' with '' > sendsize[7578]: time 0.022: running "/bin/dump 0Esf 1048576 - /" > sendsize[7578]: time 0.023: running /usr/local/libexec/killpgrp > sendsize[7578]: time 0.137: Usage: dump [-?CDVcgl -L[v] -a[v] -f[v] > -h[dnv] -o[v] -r[dnv] -s[dnv] -t[nv] -T index1[, index2]] file(s) > ... > sendsize[7578]: time 0.138: . > sendsize[7578]: estimate time for / level 0: 0.116 > sendsize[7578]: no size line match in /bin/dump output for "/" > sendsize[7578]: . > sendsize[7578]: estimate size for / level 0: -1 KB > sendsize[7578]: time 0.138: asking killpgrp to terminate > sendsize[7578]: time 1.149: done with amname '/', dirname '/', > spindle -1 > > Notice line 6 "Usage: " message. Perhaps dump is not acting the way > amanda expects? Is this my problem? I had trouble getting gnu tar to > compile, but maybe I should try again so I can use it instead of > dump. -- Kurt Yoder Sport & Health network administrator
Re: New tape not found in rack, but they are there
On Mon, Jul 28, 2003 at 09:58:25AM -0700, Adam Ardis wrote: > I never want to overwrite, but we're supposed to > rotate them out daily. I assume you mean you *do* want to overwrite, but only overwrite "old" tapes, for some definition of "old". In that case, Amanda did exactly the right thing on your behalf, by preventing you from overwriting your *newest* tapes. > It's possible these weren't > moved out, but my real question here is that I don't > want amanda to be dependent on the tapelist. In the environment you're in (apparently not full-only, dumpcycle 1 week), you really cannot do that. > Do I > have to go by what the rotation is listed in > tape-list, If your total number of labeled tapes is > tapecycle, you can have a choice of multiple "old" tapes, but you still need tapelist. > or can I continue to put in any tape? If I > can't, then i'll try to rearrange the tapes and the > tape list to be accurate, but since we have operators > moving the tapes, I wanted them to just put an > available tape in, rather than a specific tape. Well, if you're doing incrementals, you have to have your tapes at least *semi* under control, right? You can't just feed random tapes lest you clobber the tape(s) you need to restore a file you removed two days ago. > And > by available I mean one that came back to us offsite > that can be overwritten. Ah, *that* we can probably work with. > > Because you have set dumpcycle and tapecycle to tell > > it not to. > > Can you be more specific as to how to do this? Sure, though it would be even better if *you* were more specific! :-) But here's a cooked up example along the lines you're talking about. Suppose your particulars are: Do fulls at least 1X/week. Run amdump 5X/week, 1 tape/run. All tapes are transported offsite the day after being written. Keep the last 4 weeks worth of tapes offsite at all times. Keep about 1 weeks worth of "writable" tapes onsite at all times. dumpcycle 1 week runspercycle 5 tapecycle 20 You would amlabel at least 25 tapes. All except the most-recently- used 20 would be "writable". Each day when the newest tape is dropped off at offsite storage, the oldest tape is returned. Any of the onsite tapes can be used (since #-of-tapes is > tapecycle). > Ok I understand. If we fail to remove the tape and > have it overwrite daily, I will lose the day before's > data. And if we don't remove the tape that's full, we > don't have space to do the next backup. Any > suggestions, other than make sure we remove teh tapes > when they are full? :) Suggestion above. BTW, s/full/used/g. -- Jay Lessert [EMAIL PROTECTED] Accelerant Networks Inc. (voice)1.503.439.3461 Beaverton OR, USA(fax)1.503.466.9472
Re: chg-manual bug?
On Tue, Jul 29, 2003 at 01:32:19AM +0800, Matthias Bethke wrote: > Hi Gene, > on Monday, 2003-07-28 at 07:25:08, you wrote: > > >| EGREP=grep -E > > > > > >certainly looked wrong to me. Quoting did it: > > >| EGREP='grep -E' > > > > I don't use this but that is how it is in my copy of > > amanda-2.4.4p1-20030716, at line 33, with the quotes. > > Must have been fixed meanwhile -- my install directory is from June > 26th, I guess I downloaded the source one or two days before. > > > > length 3848 mbytes > > > [...] > > > > This looks as if the drives compression is on. If it is, then the > > data from /dev/urandom gets somewhat expanded by it, and will report > > a bit less than the tapes raw capacity. > > Hmm...I was a bit surprised about this value already, but according to > both the DIP switch and mt, compression is off. > > > Since the gzip that amanda uses can beat the hardware in every dept > > but speed, we generally recommend that the drives hardware compressor > > be disabled. > > Can amanda be told to use bzip2? This P3 is far from fully loaded with > its job as a WLAN router and fileserver, and as it cannot be clocked > down to save some energy, it might as well do something useful for the > calories it burns :) I've been looking at patching amanda to do bzip2 (actually, any arbitrary external compression program), but I'm not done yet. :-( A patch to just replace gzip with bzip2 is easy, but loses the ability to read old dumps. I don't know if anyone else has done any work in that direction. Maybe these posts to the list will jog someone's memory. -- JF
Re: chg-manual bug?
Hi Gene, on Monday, 2003-07-28 at 07:25:08, you wrote: > >| EGREP=grep -E > > > >certainly looked wrong to me. Quoting did it: > >| EGREP='grep -E' > > I don't use this but that is how it is in my copy of > amanda-2.4.4p1-20030716, at line 33, with the quotes. Must have been fixed meanwhile -- my install directory is from June 26th, I guess I downloaded the source one or two days before. > > length 3848 mbytes > > [...] > > This looks as if the drives compression is on. If it is, then the > data from /dev/urandom gets somewhat expanded by it, and will report > a bit less than the tapes raw capacity. Hmm...I was a bit surprised about this value already, but according to both the DIP switch and mt, compression is off. > Since the gzip that amanda uses can beat the hardware in every dept > but speed, we generally recommend that the drives hardware compressor > be disabled. Can amanda be told to use bzip2? This P3 is far from fully loaded with its job as a WLAN router and fileserver, and as it cannot be clocked down to save some energy, it might as well do something useful for the calories it burns :) regards Matthias
Re: amrecover problem: need help/advice
Title: Re: amrecover problem: need help/advice The problem was my scsi card driver. Reviewing my kernel configuration files, between 2.4.14 and 2.4.15 (now running 2.4.21), I switched to the new sym53c8xx_2 driver. I recompiled my kernel with the older NCR53c7,8xx driver (there is also an ncr53c8xx and sym53c8xx ). It won't utilize all the speed of the card/drives, but it will read my tapes ! The strange thing is that it writes the tapes fine, but has problems reading. If I have time, I will investigate further and post to the debian-alpha mailing list to see if any similar problems have occurred in other machines. On Sun, 2003-07-20 at 23:23, Gene Heskett wrote: On Sunday 20 July 2003 18:31, Freels, James D. wrote: >OK. I am learning from this. The number of 1k blocks on the first >stored file on this tape is actually 384 and not 352. I should have >looked at the taper output and not the dumper output. I issue the >following multiple times: > >mt rewind >mt -f=/dev/tape_norewind fsf 1 >dd if=/dev/tape_norewind of=./first_file bs=1k count=384 > >the number of records read returned is > >64 >288 >384 >384 >64 >64 >384 > >when it should be 384 every time ! Does this not smell of a > hardware problem ? Must be the scsi card ? Yes it does on the face of it. >If so, why don't I have other scsi errors on the hard drives ? > >Any ideas ? The only additional one I keep stumbling over is that maybe this card is so optimized for disk useage that its not quite kosher for a tape drive. If you are running the disks on this same card, a second ugly thought comes to mind, and this is something that historicly seems to be abused by tape drives more than disk drives, and that is the honoring of the 'scsi disconnect', which is the situation where a command is issued to a device on the scsi bus, and an immediate disconnect is done, opening up the bus for use by other programs and such, leaving it up to the device the command was issued to to notify the host that the command has been done, and any data read (or written for that matter) is now ready in the buffers to be read at the host and controllers convienience. Many tape drives ignore the disconnect message and lock the bus from other uses by other devices until the command is completed. I'm not saying that it couldn't happen to a disk, but if its a true scsi-2 or better, it should honor it. You might investigate that aspect of it, and see if there are any workarounds starting with the cards own bios configuration available during the 'post' of a reboot. If not, then that question might be answered by putting a different card in for the tape drive by itself so that it doesn't have to share a bus with disks that in all probability do honor a disconnect correctly. Other than those 2 possibilities, I'm fresh out of ideas. >On Sun, 2003-07-20 at 05:00, Gregor Ibic wrote: >> >> try to read the tape (or chunk - fsf) with dd >> dd if=/dev/nst0 of=/ bs=1024 count= >> where NNN is greater than your backup job/disk entry >> and see what happens >> >> i restored some valueable tape (MTF formated) reading this way and >> putting the pieces together. >> >> regards, >> gregor -- Cheers, Gene AMD [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 512M 99.26% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved. -- James D. Freels, Ph.D. Oak Ridge National Laboratory [EMAIL PROTECTED]
Re: New tape not found in rack, but they are there
I never want to overwrite, but we're supposed to rotate them out daily. It's possible these weren't moved out, but my real question here is that I don't want amanda to be dependent on the tapelist. Do I have to go by what the rotation is listed in tape-list, or can I continue to put in any tape? If I can't, then i'll try to rearrange the tapes and the tape list to be accurate, but since we have operators moving the tapes, I wanted them to just put an available tape in, rather than a specific tape. And by available I mean one that came back to us offsite that can be overwritten. > > Unless your dumpcycle is < 7 days, you do *NOT* want > to over-write > these! > > > My questions are why does the backup want to use > other > > tapes, and why won't it just use what's in the > drives? > > Because you have set dumpcycle and tapecycle to tell > it not to. Can you be more specific as to how to do this? > > Can I get Amanda to just use whatever is in teh > > drives and not care about a retention? > > Sure, but unless you know what you're doing (and you > don't yet), that > is a really bad idea. > This amanda setup was here before I was, and I'm just getting to try to figure out what it does and how it does it. > > You've not said, but I'm guessing that you're > running some sort of > full-only configuration. > We do incrementals and full once a week, but are supposed to off-site the tapes daily. > And I'm guessing you've set tapecycle to exactly the > number of tapes > you've labeled. Yes, this seems to be true. > > Amanda will decline to overwrite a tape newer than > tapecycle runs > old. You can set tapecycle to 0 if you want. > > Amanda will in any case also decline to overwrite > the newest run, > because if you do, and the current run fails, you've > lost not one > run, but two, right? > Ok I understand. If we fail to remove the tape and have it overwrite daily, I will lose the day before's data. And if we don't remove the tape that's full, we don't have space to do the next backup. Any suggestions, other than make sure we remove teh tapes when they are full? :) Thanks, Adam __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: New tape not found in rack, but they are there
On Mon, Jul 28, 2003 at 06:55:12AM -0700, Adam Ardis wrote: > I'm hoping someone can help me with this, i've looked > around and can't answer the question myself. I've got > two DLT7000 drives directly attached to my Solaris > server for backups, and they will run normally. On > occassion, I'll get a report back like: > > *** A TAPE ERROR OCCURRED: [label DS036 or new tape > not found in rack]. Some dumps may have been left in > the holding disk. Run amflush again to flush them to > tape. The next 2 tapes Amanda expects to used are: > DS036, DS035. > > Now, there are two tapes in the drives: > > twdev001:/home/amanda$ amtape staging show > amtape: scanning all 2 slots in tape-changer rack: > slot 2: date 20030722 label DS026 > slot 1: date 20030722 label DS010 Unless your dumpcycle is < 7 days, you do *NOT* want to over-write these! > My questions are why does the backup want to use other > tapes, and why won't it just use what's in the drives? Because you have set dumpcycle and tapecycle to tell it not to. > Can I get Amanda to just use whatever is in teh > drives and not care about a retention? Sure, but unless you know what you're doing (and you don't yet), that is a really bad idea. > We rotate the > tapes out daily, since we need to do it by hand > anyway. They go offsite for a month and then back > into rotation, so we don't really follow any rules as > to which tape to put in when. The first two tapes in > tapelist are what's in the drives, DS026 and DS010, DS026 and DS010 were written 6 days ago (20030722), NOT more than a month ago. > but we may not necessarily have the last two, which > I'm guessing are what Amanda expects, DS035 and DS036. > > twdev001:/home/amanda/staging$ more tapelist > 20030722 DS010 reuse > 20030722 DS026 reuse > 20030721 DS029 reuse > 20030718 DS025 reuse > 20030718 DS008 reuse > ...Continues down > 20030616 DS009 reuse > 20030610 DS027 reuse > 20030610 DS035 reuse > 20030526 DS036 reuse You've not said, but I'm guessing that you're running some sort of full-only configuration. And I'm guessing you've set tapecycle to exactly the number of tapes you've labeled. Amanda will decline to overwrite a tape newer than tapecycle runs old. You can set tapecycle to 0 if you want. Amanda will in any case also decline to overwrite the newest run, because if you do, and the current run fails, you've lost not one run, but two, right? -- Jay Lessert [EMAIL PROTECTED] Accelerant Networks Inc. (voice)1.503.439.3461 Beaverton OR, USA(fax)1.503.466.9472
Tapetyep question
I am using a backup to disk setup. I have my tapetype from amanda.conf
below. Backups aren't happening as quickly as I had hoped, and I am looking
at ways to improve matters. According to the amanda man page, the speed
parameter is not even used by amanda currently, but it also says the default
is 200 bps. So I am wondering if amanda is in fact using that value and I am
hurting myself by not specifying it, or if she tries to write at the fastest
speed possible, or if she is using the default 200 bps.
from amanda.conf:
tapetype HARD-DISK # what kind of tape it is (see tapetypes
below)
define tapetype HARD-DISK {
comment "40GB Hard disk"
length 4 mbytes
}
Thanks,
Josh
(광고)투자자 모심니다.
Title: 다임클럽 소식 --- 투자자 모심니다. --- 당사는 대부사업을 하는 업체입니다. 대부사업자 허가를 이미 마쳤으며. 현재 공격적인 마케팅으로 성업중입니다. 금번 당사는 부동산후순위 대출 영업을 기획하고 있습니다. 투자 이윤은 연이율 24%이상 보장합니다. 금액은 500만원 이상이면 관계없습니다. 또한, 이번 기회에 사채쪽으로 관심있으신 분에 한해 저희와 같이 일할 파트너도 구합니다. 대부업 정식 등록업체 02-566-7132 정보 통신부 관련법 준수 함.. (광고)문구 표기 ... '수신거부'문구표기 관련 법규 준수로 차후 문제의 소지 전혀 없음 02-566-7132 TEL :02-566-7133 --- 대부업 정식 등록 업체 --- KOREA. CO. 정통부 권고사항에 의거 제목에 [광고]라고 표기한 메일입니다. [수집URL] http://daily.daemonnews.org/view_story.php3?story_id8[수신거부(REJECT)]If you do not receive this mail. Please click above reject button.
Re: Dell Powervault 120T
Russell Adams wrote:
I can't seem to get tapetype to agree to the rated capacity of my
Powervault 120T (DLT 7000 35G native).
The maximum uncompresses that tapetype registers is about 27G.
Running 'mt status' returns a density code for 35G.
Any ideas why I can't detect the full tape?
Here's the output from tapetype.
Writing 128 Mbyte compresseable data: 28 sec
Writing 128 Mbyte uncompresseable data: 28 sec
Estimated time to write 2 * 1024 Mbyte: 448 sec = 0 h 7 min
wrote 860664 32Kb blocks in 2632 files in 24789 seconds (short write)
wrote 855261 32Kb blocks in 5247 files in 33707 seconds (short write)
define tapetype unknown-tapetype {
comment "just produced by tapetype prog (hardware compression
off)"
length 27065 mbytes
filemark 66 kbytes
speed 961 kps
}
Not the faintest idea. I would believe amtapetype to be correct
for your current setup. Maybe you have to fiddle with some setting?
Or do you have the correct media inserted that has 35 Gb (some
manufacturers supply different tapes that just differ in length,
hence the capacity difference). But 27 Gbyte is really a weird number.
While tuning/testing know that it runs *much* *much* faster if you
give amtapetype a realistic estimate, like stated in the manpage.
amtapetype -e 35g ...
--
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 *
***
Dell Powervault 120T
I can't seem to get tapetype to agree to the rated capacity of my
Powervault 120T (DLT 7000 35G native).
The maximum uncompresses that tapetype registers is about 27G.
Running 'mt status' returns a density code for 35G.
Any ideas why I can't detect the full tape?
Here's the output from tapetype.
Writing 128 Mbyte compresseable data: 28 sec
Writing 128 Mbyte uncompresseable data: 28 sec
Estimated time to write 2 * 1024 Mbyte: 448 sec = 0 h 7 min
wrote 860664 32Kb blocks in 2632 files in 24789 seconds (short write)
wrote 855261 32Kb blocks in 5247 files in 33707 seconds (short write)
define tapetype unknown-tapetype {
comment "just produced by tapetype prog (hardware compression
off)"
length 27065 mbytes
filemark 66 kbytes
speed 961 kps
}
Russell
Göçmen Vizesi GreenCard Amerikada Yaþam Fýrsatý
Title: Untitled Document Green Card, Amerikan vatandaюэ olmayan yabancэlara, Amerika Birleюik Devletleri 'nde sьresiz (цmьr boyu) oturma ve зalэюma izni saрlayan gцзmen vizesidir. Fэrsatlar ьlkesi Amerika 'da, 2003 yэlэ DV-2005 зekiliюine katэlэp ABD 'de зalэюma, yaюama ve okuma fэrsatэnэ yakalamak mьmkьn. ABD heryэl 55.000 kiюiye зekiliю sonucu gцзmen vizesi yani Green Card vermektedir. Greencardline.com Consulting Baюvuru ьcreti: Kredi kartlэ : 22 Milyon + KDV =25.960.000 TL Posta Цdemeli : 26 Milyon + KDV =30.680.000 TL Ayrэntэlэ bilgi iзin www.greencardline.com tэklayэnэz...
Question on Index Record
I am using a shell wrapper in my /sbin/dump so that I can run oracle backup before dumping the disk, and the gz file exists in my amanda index directory. However, it said no index records found when I do amrecover but when I run "amadmin config_file find /my_disk" , it stated that the disk had been stored into the tape and the status is OK. Does anyone know the problem and find the way to get all index record back? Also, just a quick question, how can I move the index record into the tape? (I know some website has this info, but I forgot the URL). -- Kin-Ho Kwan Software Engineer Hx Technologies [EMAIL PROTECTED]
New tape not found in rack, but they are there
Hello, I'm hoping someone can help me with this, i've looked around and can't answer the question myself. I've got two DLT7000 drives directly attached to my Solaris server for backups, and they will run normally. On occassion, I'll get a report back like: *** A TAPE ERROR OCCURRED: [label DS036 or new tape not found in rack]. Some dumps may have been left in the holding disk. Run amflush again to flush them to tape. The next 2 tapes Amanda expects to used are: DS036, DS035. Now, there are two tapes in the drives: twdev001:/home/amanda$ amtape staging show amtape: scanning all 2 slots in tape-changer rack: slot 2: date 20030722 label DS026 slot 1: date 20030722 label DS010 My questions are why does the backup want to use other tapes, and why won't it just use what's in the drives? Can I get Amanda to just use whatever is in teh drives and not care about a retention? We rotate the tapes out daily, since we need to do it by hand anyway. They go offsite for a month and then back into rotation, so we don't really follow any rules as to which tape to put in when. The first two tapes in tapelist are what's in the drives, DS026 and DS010, but we may not necessarily have the last two, which I'm guessing are what Amanda expects, DS035 and DS036. twdev001:/home/amanda/staging$ more tapelist 20030722 DS010 reuse 20030722 DS026 reuse 20030721 DS029 reuse 20030718 DS025 reuse 20030718 DS008 reuse ...Continues down 20030616 DS009 reuse 20030610 DS027 reuse 20030610 DS035 reuse 20030526 DS036 reuse Please help, any advice would be greatly appreciated. Thanks in advance, Adam __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: chg-manual bug?
On Monday 28 July 2003 04:50, Matthias Bethke wrote:
>Hi all,
>
>I just set up my first amanda config for my private network, to try
> it out before I put it on a larger installation at university. I
> have a P3-450 fileserver with a single big SCSI disk and a DSS-2
> drive[0]. That means I have to use the "manual changer" method --
> but amcheck failed to run chg-manual, complaining about a "command
> not found" in line 33. Now I'm not a shell programming expert, but
>
>| EGREP=grep -E
>
>certainly looked wrong to me. Quoting did it:
>| EGREP='grep -E'
I don't use this but that is how it is in my copy of
amanda-2.4.4p1-20030716, at line 33, with the quotes.
>
>Mine is a Linux system where /bin/sh is a link to bash, but I don't
>think the Bourne shell would like the above either, would it?
>
Same as here.
>Other than that, amanda seems to be running fine, I'm just doing my
>first full dump (tar, that is) in the background. Can't wait to try
> it on the 6x40GB jukebox @work :-)
>
>regards
> Matthias
>
>
>[0] Here's the tapetype as determined by amtapetype, with a 120m
> tape: define tapetype DEC-TLZ07 {
>comment "DEC DSS2 drive"
>length 3848 mbytes
>filemark 0 kbytes
>speed 392 kps
>}
>BTW, this is almost identical to the TLZ06, excpet that the 06 is
> DDS-1 and should thus have half the capacity. Just in case anyone
> still uses these...
This looks as if the drives compression is on. If it is, then the
data from /dev/urandom gets somewhat expanded by it, and will report
a bit less than the tapes raw capacity. Since the gzip that amanda
uses can beat the hardware in every dept but speed, we generally
recommend that the drives hardware compressor be disabled.
This then leads to the requirement that each tape which has been
previously written in the compressed mode, be re-written forceably
without compression in order to cancel the "I'm compressed" flag in
the tape header. Amanda's normal sequence of operations will not
allow the presetting of this by an external script because amanda
forces a re-read of the header in identifying the tape, and doesn't
let go of the drive until its done.
I have a script that can do this, or you can cobble up one of your own
with a bit of experimentation. The basic sequence is (assuming all
devices are non-rewinding):
load the tape
rewind
read the label out to a scratch file with dd
rewind
reset the compression status with mt commands, both ways for DDS
write that scratch file back to the tape with dd
write an additional amount from /dev/zero that will overflow the
drives buffer and force its flush to the media, 5 megs should be
enough.
rewind
read the label to make sure its ok
repeat for the rest of the tapes in the magazine that need it.
--
Cheers, Gene
AMD [EMAIL PROTECTED] 320M
[EMAIL PROTECTED] 512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Re: amdump hangs forever when dump should be starting
On Monday 28 July 2003 04:06, Paul Bijnens wrote:
>Scott Mcdermott wrote:
>> When I run the dump though, it calculates what it needs to
>> do, gets to the "driver: hdisk-state time xxx" line, and
>
>Do you mean that the line is truncated after the time?
>It should look like:
>
>driver: hdisk-state time 996.043 hdisk 0: free 22386164 dumpers 16
>
>i.e. it should continue with a state of each holdingdisk.
>Is there a newline or not? (a newline, means: no holdingdisks)
>(Yes, it seems you don't use a holdingdisk, then this is normal.)
>
>Just after it, there should be messages about the portusage
>of each client which connects to dumper.
>
>> $ ps -eo user,comm,pid,wchan | grep ^amanda
>> amanda amdump9302 wait4
>> amanda driver9315 do_select
>> amanda taper 9316 unix_stream_data_wait
>> amanda dumper9317 unix_stream_data_wait
>> amanda dumper9318 unix_stream_data_wait
>> amanda dumper9319 unix_stream_data_wait
>> amanda taper 9320 pipe_wait
>
>I would expect at least a "amandad" or one of its children
>be there to (if indeed the client is the same as the server).
>Is there a local firewall installed/activated?
>
>> amanda is just stuck, doesn't timeout, doesn't do anything,
>> just sits there.
>
>Or times out after a very long time?
>
>> $ cat normal/amanda.conf | grep -v ^\#
>
>...
>
>> runspercycle0
>
>Strange, but probably no error. Change into some
>real value to be very sure this is not the cause.
>
>> define dumptype tardump {
>> comment "uses GNU tar"
>> compressnone
>> holdingdisk no
>> ignore no
>> index yes
>> program "GNUTAR"
>> record no
>> starttime 0001
>> }
>
>I never tried the "starttime" option. Could this be the problem?
>
The last time I used it, it worked. If cron is not starting it until
some time after midnight, then it will wait till either 1 minute
after midnight or 1 am to continue. The ambiguity would be because
I'm not sure what it will do when the colon is missing.
>> driver: hdisk-state time 100.388
>
>Just after it, there should be messages about the tcp connections
>(the estimate were done in udp datagrams). Maybe some problem here?
--
Cheers, Gene
AMD [EMAIL PROTECTED] 320M
[EMAIL PROTECTED] 512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Göçmen Vizesi GreenCard Amerikada Yaþam Fýrsatý
Title: Untitled Document Green Card, Amerikan vatandaюэ olmayan yabancэlara, Amerika Birleюik Devletleri 'nde sьresiz (цmьr boyu) oturma ve зalэюma izni saрlayan gцзmen vizesidir. Fэrsatlar ьlkesi Amerika 'da, 2003 yэlэ DV-2005 зekiliюine katэlэp ABD 'de зalэюma, yaюama ve okuma fэrsatэnэ yakalamak mьmkьn. ABD heryэl 55.000 kiюiye зekiliю sonucu gцзmen vizesi yani Green Card vermektedir. Greencardline.com Consulting Baюvuru ьcreti: Kredi kartlэ : 22 Milyon + KDV =25.960.000 TL Posta Цdemeli : 26 Milyon + KDV =30.680.000 TL Ayrэntэlэ bilgi iзin www.greencardline.com tэklayэnэz...
chg-manual bug?
Hi all,
I just set up my first amanda config for my private network, to try it
out before I put it on a larger installation at university. I have a
P3-450 fileserver with a single big SCSI disk and a DSS-2 drive[0]. That
means I have to use the "manual changer" method -- but amcheck failed to
run chg-manual, complaining about a "command not found" in line 33. Now
I'm not a shell programming expert, but
| EGREP=grep -E
certainly looked wrong to me. Quoting did it:
| EGREP='grep -E'
Mine is a Linux system where /bin/sh is a link to bash, but I don't
think the Bourne shell would like the above either, would it?
Other than that, amanda seems to be running fine, I'm just doing my
first full dump (tar, that is) in the background. Can't wait to try it
on the 6x40GB jukebox @work :-)
regards
Matthias
[0] Here's the tapetype as determined by amtapetype, with a 120m tape:
define tapetype DEC-TLZ07 {
comment "DEC DSS2 drive"
length 3848 mbytes
filemark 0 kbytes
speed 392 kps
}
BTW, this is almost identical to the TLZ06, excpet that the 06 is DDS-1
and should thus have half the capacity. Just in case anyone still uses
these...
Re: amdump hangs forever when dump should be starting
Scott Mcdermott wrote:
When I run the dump though, it calculates what it needs to
do, gets to the "driver: hdisk-state time xxx" line, and
Do you mean that the line is truncated after the time?
It should look like:
driver: hdisk-state time 996.043 hdisk 0: free 22386164 dumpers 16
i.e. it should continue with a state of each holdingdisk.
Is there a newline or not? (a newline, means: no holdingdisks)
(Yes, it seems you don't use a holdingdisk, then this is normal.)
Just after it, there should be messages about the portusage
of each client which connects to dumper.
$ ps -eo user,comm,pid,wchan | grep ^amanda
amanda amdump9302 wait4
amanda driver9315 do_select
amanda taper 9316 unix_stream_data_wait
amanda dumper9317 unix_stream_data_wait
amanda dumper9318 unix_stream_data_wait
amanda dumper9319 unix_stream_data_wait
amanda taper 9320 pipe_wait
I would expect at least a "amandad" or one of its children
be there to (if indeed the client is the same as the server).
Is there a local firewall installed/activated?
amanda is just stuck, doesn't timeout, doesn't do anything,
just sits there.
Or times out after a very long time?
$ cat normal/amanda.conf | grep -v ^\#
...
runspercycle0
Strange, but probably no error. Change into some
real value to be very sure this is not the cause.
define dumptype tardump {
comment "uses GNU tar"
compressnone
holdingdisk no
ignore no
index yes
program "GNUTAR"
record no
starttime 0001
}
I never tried the "starttime" option. Could this be the problem?
driver: hdisk-state time 100.388
Just after it, there should be messages about the tcp connections
(the estimate were done in udp datagrams). Maybe some problem here?
--
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 *
***
제목없음
제목없음[수집URL] http://daily.daemonnews.org/view_story.php3?story_id8[수신거부(REJECT)]If you do not receive this mail. Please click above reject button.
Re: Backup Server will not back itself up.
Stephen Carville wrote: About a week ago, my backup server stopped backing itself up: ... GNUTAR //snap01/development 0 1970:1:1:0:0:0 -1 exclude-file=Temporary\ \(Not\ Backed\ Up\!\) Exclude/Include list with spaces in the names do not work (yet). I have a (very ugly!) patch if urgent. But the good fix is much more difficult. See: http://groups.yahoo.com/group/amanda-hackers/message/3761 ... FORMAT ERROR IN REQUEST PACKET ... REQ packet is bogus: extra text at end -- 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 * ***
