Re: all estimate timed out
Hi Chris, Am 03.04.2013 17:26, schrieb Chris Hoogendyk: This seems like an obvious read the FAQ situation, but . . . I'm running Amanda 3.3.2 on a Sun T5220 with Solaris 10 and a J4500 jbod disk array with multipath SAS. It all should be fast and is on the local server, so there isn't any network path outside localhost for the DLE's that are giving me trouble. They are zfs on raidz1 with five 2TB drives. Gnutar is v1.23. This server is successfully backing up several other servers as well as many more DLE's on the localhost. Output to an AIT5 tape library. I've upped the etimeout to 1800 and the dtimeout to 3600, which both seem outrageously long (jumped from the default 5 minutes to 30 minutes, and from the default 30 minutes to an hour). The filesystem (DLE) that is giving me trouble (hasn't backed up in a couple of weeks) is /export/herbarium, which looks like: marlin:/export/herbarium# df -k . Filesystemkbytesused avail capacity Mounted on J4500-pool1/herbarium 2040109465 262907572 177720189313% /export/herbarium marlin:/export/herbarium# find . -type f | wc -l 2806 marlin:/export/herbarium# find . -type d | wc -l 140 marlin:/export/herbarium# So, it is only 262G and only has 2806 files. Shouldn't be that big a deal. They are typically tif scans. One thought that hits me is: possibly, because it is over 200G of tif scans, compression is causing trouble? But this is just getting estimates, output going to /dev/null. Here is a segment from the very end of the sendsize debug file from April 1 (the debug file ends after these lines): Mon Apr 1 08:05:49 2013: thd-32a58: sendsize: . Mon Apr 1 08:05:49 2013: thd-32a58: sendsize: estimate time for /export/herbarium level 0: 26302.500 Nice, it took 7 hours 18 Minutes and 22 Seconds to get the level-0 estimate. Mon Apr 1 08:05:49 2013: thd-32a58: sendsize: estimate size for /export/herbarium level 0: 262993150 KB Mon Apr 1 08:05:49 2013: thd-32a58: sendsize: waiting for runtar /export/herbarium child Mon Apr 1 08:05:49 2013: thd-32a58: sendsize: after runtar /export/herbarium wait Mon Apr 1 08:05:49 2013: thd-32a58: sendsize: getting size via gnutar for /export/herbarium level 1 Mon Apr 1 08:05:49 2013: thd-32a58: sendsize: Spawning /usr/local/libexec/amanda/runtar runtar daily /usr/local/etc/amanda/tools/gtar --create --file /dev/null --numeric-owner --directory /export/herbarium --one-file-system --listed-incremental /usr/local/var/amanda/gnutar-lists/localhost_export_herbarium_1.new --sparse --ignore-failed-read --totals . in pipeline Mon Apr 1 10:16:17 2013: thd-32a58: sendsize: Total bytes written: 77663795200 (73GiB, 9.5MiB/s) Mon Apr 1 10:16:17 2013: thd-32a58: sendsize: . Mon Apr 1 10:16:17 2013: thd-32a58: sendsize: estimate time for /export/herbarium level 1: 7827.571 Mon Apr 1 10:16:17 2013: thd-32a58: sendsize: estimate size for /export/herbarium level 1: 75843550 KB Mon Apr 1 10:16:17 2013: thd-32a58: sendsize: waiting for runtar /export/herbarium child Mon Apr 1 10:16:17 2013: thd-32a58: sendsize: after runtar /export/herbarium wait Mon Apr 1 10:16:17 2013: thd-32a58: sendsize: done with amname /export/herbarium dirname /export/herbarium spindle 45002 and aditional it took 2 hours 11 minutes getting the level-1 estimate. in sum it took about 9 and a half hour to get the estimates so your etimeout of 30 minutes is a little bit low for this machine, isn't it? you should consider using another method of getting estimates for that machine, or you should find out what makes the estimates on that machine so slow, as the backup itself will likely take longer then the estimates Christoph
Re: full dump in degraded mode - possible?
Am 29.03.2013 06:30, schrieb Kamil Jońca: As far I know amanda does not do full dump when no tape (vtape in my case) is not available. Is there any way to force it? If not what is the rationale for this? (I would prefer keep disk with vtapes as short as possible turned on) KJ Hm, what about RTFM ? ;-) especialy man amanda.conf, where in the section about global parameters, it tells you something about the parameter reserve int, which defaults to 100, as to reserve 100% of holdingdisk-space for incremental backups if no tape is online. If you set this parameter to eg 10, amanda will happily do full dumps to the holdingdisk until ist is filled up to 90% and use the rest for incermentals only. hope that helps and happy easter to everyone Christoph
Re: Amanda Performance
Hi Again, Am 18.03.2013 05:55, schrieb Amit Karpe: Brian, Yes, initially I was using holdingdisk for all config. But when I see backup is low and taking more time, I had doubt that my backup holdingdisk are on same disk (NAS) which is 19TB. So I change it force not to use it. That holdingdisk on the NAS won't buy you much speed improvement, with the holdingdisk on the nas, all your data will be sent 4 times over the network, 1. from client to amanda server, 2. from amanda server to nas holdingdisk, 3. from nas holdingdisk back to amanda server 4. from amanda-server back to your vtape storage. and voila, there is your network-bottleneck again limiting you to roughly max-Networkbandwith/4 MByte/sec for the dumps. you realy need physical disk(s) in your amanda-machine for holdingspace to speed things up. Christoph
Problems saving W2k3 Server with zmanda-comunity-client and pre-backup-scripts on client
Hi,
i'm implementing a new amanda installation for a customer,
server is a intel Quad-core with 2GB ram, running debian-lenny,
amanda is 2.6.1p1, self-compiled.
clients are 3 windows-2003 server, with latest zmanda-community-client,
and the server itself.
Storage goes to v-tapes on sata-disks.
amcheck is happy with the config, but when it comes to dump-time,
all the disklist-entrys for which pre- and post-dump-scripts are defined
fail, and the client-services crash when amanda starts to collect the dumps.
Is that a known problem of these clients?
Should i go and install cygwin on the clients and install the amanda client
that way?
Or has someone a clue where i should look for?
Thanks and have a nice day
Christoph
-Ursprüngliche Nachricht-
Von: amandabac...@linfbw002.do723b.intern.
[mailto:amandabac...@linfbw002.do723b.intern.]
Gesendet: Donnerstag, 11. Juni 2009 08:32
An: Administrator
Betreff: factoring AMANDA MAIL REPORT FOR June 11, 2009
Hostname: LINFBW002
Org : factoring
Config : factoring
Date: June 11, 2009
These dumps were to tape factoring-04.
The next tape Amanda expects to use is: 1 new tape.
The next new tape already labelled is: factoring-00.
FAILURE DUMP SUMMARY:
172.16.8.42 D:/DFSlev 0 FAILED [Not enough
holding disk space]
172.16.8.42 E:/Datendateien/MSSQL/Datalev 0 FAILED [too many dumper retry: [request
failed: Connection refused]]
172.16.8.46 D:/Virtual Machines/Sicherung lev 0 FAILED Failed reading dump
header.
172.16.8.40 D:/Programme/Exchsrvr lev 0 FAILED Failed reading dump
header.
172.16.8.42 D:/DFSlev 0 FAILED Failed reading dump
header.
172.16.8.42 D:/DFSlev 0 FAILED [too many dumper retry: [request
failed: Connection refused]]
172.16.8.46 D:/Virtual Machines/Sicherung lev 0 FAILED Failed reading dump
header.
172.16.8.46 D:/Virtual Machines/Sicherung lev 0 FAILED [too many dumper retry: [request
failed: Connection refused]]
172.16.8.40 D:/Programme/Exchsrvr lev 0 FAILED Failed reading dump
header.
172.16.8.40 D:/Programme/Exchsrvr lev 0 FAILED [too many dumper retry: [request
failed: Connection refused]]
STRANGE DUMP SUMMARY:
LINFBW002 / lev 0 STRANGE (see below)
STATISTICS:
Total Full Incr.
Estimate Time (hrs:min)0:29
Run Time (hrs:min) 8:27
Dump Time (hrs:min)0:01 0:01 0:00
Output Size (meg) 309.7 309.70.0
Original Size (meg) 663.1 663.10.0
Avg Compressed Size (%)46.7 46.7--
Filesystems Dumped1 1 0
Avg Dump Rate (k/s) 4653.9 4653.9--
Tape Time (hrs:min)0:00 0:00 0:00
Tape Size (meg) 309.7 309.70.0
Tape Used (%) 0.00.00.0
Filesystems Taped 1 1 0
Chunks Taped 1 1 0
Avg Tp Write Rate (k/s) 119758 119758--
USAGE BY TAPE:
Label Time Size %NbNc
factoring-04 0:00 310M0.0 1 1
FAILED DUMP DETAILS:
/-- 172.16.8.42 D:/DFS lev 0 FAILED [Not enough holding disk space]
sendbackup: start [172.16.8.42:D:/DFS level 0]
sendbackup: info BACKUP=pkzip
sendbackup: info RECOVER_CMD=Extract with zmanda windows client or unzip program
sendbackup: info end
\
STRANGE DUMP DETAILS:
/-- LINFBW002 / lev 0 STRANGE
sendbackup: start [LINFBW002:/ level 0]
sendbackup: info BACKUP=/bin/tar
sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -xpGf - ...
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
? /bin/tar: ./home/amanda/20090611000502/LINFBW002._.0.tmp: file changed as we
read it
| /bin/tar: ./var/run/acpid.socket: socket ignored Total bytes written:
| 695326720 (664MiB, 11MiB/s)
sendbackup: size 679030
sendbackup: end
\
NOTES:
planner: Adding new disk LINFBW002:/.
planner: Adding new disk 172.16.8.42:D:/DFS.
planner: Adding new disk 172.16.8.42:E:/Datendateien/MSSQL/Data.
taper: tape factoring-04 kb 317151 fm 1 [OK]
DUMP SUMMARY:
DUMPER STATS TAPER STATS
HOSTNAME DISK L ORIG-MB OUT-MB COMP% MMM:SS KB/s MMM:SS
KB/s
--- -
172.16.8.4 -gramme/Exchsrvr 0 FAILED ---
172.16.8.4 D:/DFS 0 FAILED ---
172.16.8.4 -eien/MSSQL/Data 0 FAILED ---
172.16.8.4 -hines/Sicherung 0 FAILED ---
LINFBW002 / 0 663 310 46.74653.9 0:03 119758.1
(brought to you by Amanda version 2.6.1p1)
Re: [Amanda-users] How to read and interpret completed job emails from Amanda
Hi, looks all prety fine as Mark already told you, and now my 2 cents for the last Question: you see, the first disk got dumped to holdingdisk very fast, then it took relative long to get it written to tape, while the second disk was slowly writing to holdingdisk, but fast getting from there to the tape. Diagnosis: your holdingdisk is not fast enough to handle dumping the second disk and simultaneously streaming the first dump to the tape. Christoph g00f schrieb: [...] HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- - - archive2.win -TS/033x010 0 722933590 722933590-- 198:16 60769.8 241:30 49893.5 archive2.win -S/148Ax050 0 758000870 758000870-- 346:00 36512.1 185:53 67962.4 And finally this final output which tells me that bandwidth was different for the 2 FS's , why would one throughput be higher then the other one. Thanks for the decryption services :) . +-- |This was sent by [EMAIL PROTECTED] via Backup Central. |Forward SPAM to [EMAIL PROTECTED] +--
Re: Out of space problem
Hi,
Nigel Allen schrieb:
Hi All
I'm experiencing an odd problem with a USB DAT drive that keeps running
out of space. Apologies for the length of the post.
The drive is supposed to be 36 / 72 GB.
Ok this means amanda can put 36 GB of data after softwarecompression on it,
forget the 72GB value, its marketing.
Here's the kind of thing I see when I run a level 0 dump.
These dumps were to tape DailySet1-18.
*** A TAPE ERROR OCCURRED: [No more writable valid tape found].
Some dumps may have been left in the holding disk.
Run amflush to flush them to tape.
The next tape Amanda expects to use is: DailySet1-19.
FAILURE AND STRANGE DUMP SUMMARY:
mail..com.au mapper/VolGroup00-LogVol00 lev 0 FAILED [out
of tape]
STATISTICS:
Total Full Incr.
Estimate Time (hrs:min)0:04
Run Time (hrs:min)14:44
Dump Time (hrs:min) 11:22 11:22 0:00
Output Size (meg) 33927.133927.10.0
Original Size (meg) 50710.150710.00.0
Avg Compressed Size (%)66.9 66.9 10.0 (level:#disks
...)
Filesystems Dumped2 1 1 (1:1)
Avg Dump Rate (k/s) 849.1 849.18.5
Tape Time (hrs:min)0:00 0:00 0:00
Tape Size (meg) 0.00.00.0
Tape Used (%) 0.00.00.0 (level:#disks
...)
Filesystems Taped 1 0 1 (1:1)
Chunks Taped 0 0 0
Avg Tp Write Rate (k/s) 7.4-- 7.4
USAGE BY TAPE:
Label Time Size %NbNc
DailySet1-18 0:00 32K0.0 1 0
NOTES:
planner: Forcing full dump of
mail..com.au:mapper/VolGroup00-LogVol00 as directed.
taper: tape DailySet1-18 kb 31022240 fm 2 writing file: No space
ok, according to this, it wrote about 30 GB to the tape,
then it ran into EOT
this smells to me as if you have hardwarecompression enabled and are doing
softwarecompression.
That is s BAD idea, as it will lead to what you see, a loss of roughly
6 GB of tape-space, as the already compressed dump-image will EXPAND
by the hardwarecompression.
So first disable hardwarecompression of your Tapedrive, then try again.
And it tells you, you'll have to splitt your dumps in chunks using tar
and exclude-/includelists, as the level 0's are to big for your tapes.
another solution could be using a Tapechanger and tape-spanning.
left on device
driver: Taper error: [writing file: No space left on device]
driver: going into degraded mode because of taper component error.
big estimate: mail..com.au sda1 1
est: 64Kout 32K
Here is the amanda.conf file with everything not used snipped out:
org DailySet1 # your organization name for reports
mailto amandabackup # space separated list of operators at your site
dumpuser amandabackup # the user to run dumps under
inparallel 4# maximum dumpers that will run in parallel
(max 63)
dumporder sssS# specify the priority order of each dumper
taperalgo first # The algorithm used to choose which dump
image to send
displayunit k # Possible values: k|m|g|t
netusage 600 Kbps # maximum net bandwidth for Amanda, in KB per sec
dumpcycle 4 weeks # the number of days in the normal dump cycle
runspercycle 20 # the number of amdump runs in dumpcycle days
i would lower this, as it tells amanda:
do a level 0 of all disklist-entrys at least all 20 days.
have a nice day
Christoph
Re: Common 'Please add amdump to the line in /home/amanda/.amandahosts on the client' error
Craig Tierney schrieb:
I am having a problem with getting amcheck to run cleanly with a new
client I have just added. It seems that the problem is quite common,
but I still cannot figure it out.
I am trying to install Amanda-2.5.2 from source on Redhat Enterprise 5.
I have it configured and working properly on the server named 'amanda'.
By properly, amcheck finishes clean, I can get amdump to backup a
directory on the server, and I can use amrecover to look at the files
and use amrestore to restore a file.
Now I am trying to install the client on a server named 'datas'. I
copied over the amanda install directory, added the services to
/etc/services, and copied the amanda service file to /etc/xinetd.d.
I also modified the /home/amanda/.amandahosts file to look like:
amanda amanda amdump
amanda root amrecover
amanda root amandad amindexd amidxtaped
datas amanda amdump
datas root amrecover
datas root amandad amindexd amidxtaped
The /home filesystem is an NFS mount on both systems. I have tried
having the /home filesystem be local and it made no difference.
The user amanda and the group amanda have consistent uid and gid on
both systems.
My disklist is:
amanda /var/log root-tar
datas /home user-tar
So I try to run amcheck -cl daily, and I get the following response:
[EMAIL PROTECTED] daily]$ amcheck -cl daily
Amanda Tape Server Host Check
-
Holding disk /var/amandatapes/dumps: 50813372 KB disk space available,
using 49152000 KB as requested
NOTE: skipping tape checks
WARNING: tapecycle (10) = runspercycle (28).
NOTE: host info dir /opt/amanda-2.5.2/etc/amanda/daily/curinfo/datas
does not exist
NOTE: it will be created on the next run.
NOTE: index dir /opt/amanda-2.5.2/etc/amanda/daily/index/datas does not
exist
NOTE: it will be created on the next run.
Server check took 0.003 seconds
Amanda Backup Client Hosts Check
ERROR: NAK datas: user amanda from 192.168.64.44 is not allowed to
execute the service noop: Please add amdump to the line in
/home/amanda/.amandahosts on the client
Client check: 2 hosts checked in 0.044 seconds, 1 problem found
(brought to you by Amanda 2.5.2)
I have tried setting the permissions on the ~/.amandahosts file
to 400 and 600 (as I saw in other posts), but this did not help.
The /tmp/amanda*amandad file doesn't help much (to me at least):
amandad: debug 1 pid 10481 ruid 1003 euid 1003: start at Wed Jul 11
19:16:18 2007
Reading conf file /opt/amanda-2.5.2/etc/amanda/amanda-client.conf.
amandad: time 0.055: security_getdriver(name=bsd) returns 0x8e6540
amandad: version 2.5.2
amandad: time 0.055: build: VERSION=Amanda-2.5.2
amandad: time 0.055:BUILT_DATE=Thu Jul 5 14:22:23 PDT 2007
amandad: time 0.055:BUILT_MACH=Linux amanda 2.6.18-8.1.3.el5 #1
SMP Mon Apr 16 15:54:12 EDT 200
7 i686 i686 i386 GNU/Linux
amandad: time 0.055:CC=gcc
amandad: time 0.055:CONFIGURE_COMMAND='./configure'
'--prefix=/opt/amanda-2.5.2' '--with-user=a
manda' '--with-group=amanda' '--with-config=daily' '--with-ssh-security'
amandad: time 0.055: paths: bindir=/opt/amanda-2.5.2/bin
amandad: time 0.055:sbindir=/opt/amanda-2.5.2/sbin
amandad: time 0.055:libexecdir=/opt/amanda-2.5.2/libexec
amandad: time 0.055:mandir=/opt/amanda-2.5.2/man
AMANDA_TMPDIR=/tmp/amanda
amandad: time 0.055:AMANDA_DBGDIR=/tmp/amanda
amandad: time 0.055:CONFIG_DIR=/opt/amanda-2.5.2/etc/amanda
amandad: time 0.055:DEV_PREFIX=/dev/ RDEV_PREFIX=/dev/
DUMP=/sbin/dump
amandad: time 0.055:RESTORE=/sbin/restore VDUMP=UNDEF
VRESTORE=UNDEF
amandad: time 0.055:XFSDUMP=UNDEF XFSRESTORE=UNDEF VXDUMP=UNDEF
VXRESTORE=UNDEF
amandad: time 0.055:SAMBA_CLIENT=UNDEF GNUTAR=/bin/gtar
amandad: time 0.055:COMPRESS_PATH=/bin/gzip
UNCOMPRESS_PATH=/bin/gzip
amandad: time 0.055: LPRCMD=UNDEF MAILER=/usr/bin/Mail
amandad: time 0.055:
listed_incr_dir=/opt/amanda-2.5.2/var/amanda/gnutar-lists
amandad: time 0.055: defs: DEFAULT_SERVER=amanda DEFAULT_CONFIG=daily
amandad: time 0.055:DEFAULT_TAPE_SERVER=amanda HAVE_MMAP
NEED_STRSTR
amandad: time 0.055:HAVE_SYSVSHM LOCKING=POSIX_FCNTL
SETPGRP_VOID DEBUG_CODE
amandad: time 0.055:AMANDA_DEBUG_DAYS=4 BSD_SECURITY
RSH_SECURITY USE_AMANDAHOSTS
amandad: time 0.055:CLIENT_LOGIN=amanda FORCE_USERID HAVE_GZIP
amandad: time 0.055:COMPRESS_SUFFIX=.gz
COMPRESS_FAST_OPT=--fast
amandad: time 0.055:COMPRESS_BEST_OPT=--best UNCOMPRESS_OPT=-dc
amandad: time 0.056: dgram_recv(dgram=0x8e84a4, timeout=0,
fromaddr=0x8f8490)
amandad: time 0.056: (sockaddr_in *)0x8f8490 = { 2, 591, 192.168.64.44 }
amandad: time 0.056: security_handleinit(handle=0x92b5b58,
driver=0x8e6540 (BSD))
amandad: time 0.060: security_seterror(handle=0x92b5b58, driver=0x8e6540
(BSD) error=user amanda from 20
4.235.64.44 is not allowed to execute the service noop: Please add
amdump to the
Re: Bad tape or worse news?
H, i'm no free-bsd guru, but Jack Twilley schrieb: Here's the uname output: FreeBSD duchess.twilley.org 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sat Nov 8 00:40:54 PST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DUCHESS i386 I'm running amanda out of ports: amanda-client-2.4.4_2,1 The Advanced Maryland Automatic Network Disk Archiver (clie amanda-server-2.4.4_4,1 The Advanced Maryland Automatic Network Disk Archiver (serv I've started to get the following message in my nightly emails: *** A TAPE ERROR OCCURRED: [writing label: short write]. Some dumps may have been left in the holding disk. Run amflush to flush them to tape. The next tape Amanda expects to use is: twilley009. This is showing up in my messages file: Dec 3 01:08:19 duchess kernel: (sa0:ahc0:0:6:0): WRITE FILEMARKS. CDB: 10 0 0 0 2 0 Dec 3 01:08:19 duchess kernel: (sa0:ahc0:0:6:0): CAM Status: SCSI Status Error Dec 3 01:08:19 duchess kernel: (sa0:ahc0:0:6:0): SCSI Status: Check Condition Dec 3 01:08:19 duchess kernel: (sa0:ahc0:0:6:0): DATA PROTECT asc:27,0 Dec 3 01:08:19 duchess kernel: (sa0:ahc0:0:6:0): Write protected is it possible your tape is physical write-protected? Christoph Dec 3 01:08:19 duchess kernel: (sa0:ahc0:0:6:0): Unretryable error Dec 3 01:08:19 duchess kernel: (sa0:ahc0:0:6:0): failed to write terminating filemark(s) Dec 3 01:08:19 duchess kernel: (sa0:ahc0:0:6:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state. Does this mean I have a defective tape, or is the problem worse than that? Jack.
Re: tape problem
Hi, it is easy for you to verify if your tapelabels are valid, do the following commands: mt rewind dd if=/dev/nst0 bs=32k count=1 this will give you the first block of the tape. if the first characters there in are something like AMANDA: TAPESTART DATE then your labels are ok. if not you'll have to relabel them. How? very easy: amlabel -f normal normal05 the -f option forces amanda to ignore its tape-database and the contents on tape an write the label anyway. Christoph Your Name schrieb: Hi Paul You were right in pointing out that I have used a different amanda.conf file. However the changes in this file and that file are minimal (like nst0 instead of st0). You might be right when you say by using a rewinding device, I might have overwirtten the name , I am not sure how to answer this. I tried to rename the tape by amlabel normal normal05 which should be the tape it should be expecting. When I do this it says the label is already present in the drive. How can do a manual dump for time being immediately?. IS there any way I can force amanda to do backup on the tape irrespective of its label?. I appreciate your help. Regards Yogish Yogish wrote: Hi all I am facing problems with the tapes. Everytime I try to run amcheck,amverify or amdump it says its expecting a new tape. Here are the results it puts out when I run amcheck Amanda Tape Server Host Check - Holding disk /home/amanda: 29635568 KB disk space available, that's plenty ERROR: /dev/nst0: reading label: Input/output error (expecting a new tape) NOTE: skipping tape-writable test Server check took 0.016 seconds I strongly believe that the amanda.conf you send is not the one that is used! Or you changed it very recently. From your amanda.conf: tapedev /dev/st0 This is wrong: it is the rewinding device, and if I remember correctly I pointed out this and other errors in your amanda.conf a few weeks ago: http://groups.yahoo.com/group/amanda-users/message/46994 But the amcheck above says it uses /dev/nst0, so assume that the current amanda.conf is a different one... It could be that by using the rewinding device, you accidently overwrote the label. Was this what happened? -- Paul @ Home
Re: Help, Strange Error !!
Hi, have you tried it with a brand new tape? or only with tapes the old drive failed on? I had a sdt-9000 die similar, producing write-errors with medium-errors. the Tapes wreer unusable even in a new drive until i took a big magnet and wiped every bit on these tapes. after that they started working again. The defective drive must have written such a mess at the header peace of the tape(s), so no other drive's would write to them until they where bulk erased. Christoph Roberto Samarone Araújo (RSA) schrieb: Hi, I have an Amanda Backup that was working fine now, when I try to use: su -c /usr/sbin/amlabel Daily1 DAILY1-01 backup, the system return me: st0: Error with sense data: Current st09:00: sense key Medium Error Additional sense indicates Write error If I try: mt erase /dev/st0, it return me: st0: Error with sense data: Current st09:00: sense key Medium Error Additional sense indicates Write error mt: /dev/tape: Input/Output error I change my SDT-9000 tape to a new one and the problem persist. I saw on the logs the messages: st0: Block limits 1 - 16777215 bytes st0: Error with sense data: Current st09:00 sense key Medium Error Additional sense indicates Write error Does anyone could help me please ? When a try to recover a backup it worked fine. Roberto Samarone Araujo
Re: backups stopped after upgrade to redhat 9?
Hi, check your local firewall-settings. Even if you didn't change them or set them up there may be some. RH has decided around V8 to implement restrictive firewallrules as default, without asking for confirmation for doing it. That problem bit many other amanda-users before you. Christoph dwtrusty schrieb: Thanks for the tips. All the low-level commands seem to be in order. I can use ammt, mt, amtape, mtx successfully. I can use tar to write to the tape, and read the contents back. Amcheck shows no errors. I'm using version 2.4.3. What else should I check? Thanks, David --- In [EMAIL PROTECTED], Jon LaBadie [EMAIL PROTECTED] wrote: On Sat, Oct 18, 2003 at 10:21:21PM -0500, David Trusty wrote: Hi, After I upgraded my system to redhat 9, the backups have quit working. The file /var/lib/DailySet1/amdump ends with this line: taper: stream_accept: timeout after 120 seconds Step back. After the upgrade: Can you write to your tape with things like dd? Do mt commands work with your tape drive? How about ammt? If it is a changer, can you manipulate it with mtx? Do amtape commands work? What does amcheck say? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Set up drive as ide-scsi
Hi, verry easy to solve. you'll have to pass a command-line to your kernel to tell the ide-driver not to initialise your scsi-tape. with lilo use a line like append=hdd=ide-scsi in your lilo.conf. Christoph M3 Freak schrieb: Hello all, This message probably shouldn't be here, but it's for my tape drive, and I want to use Amanda, so it KINDA fits. :) Anyway, I can use my Seagate STT3401A with the ide-scsi and st modules when I insert them using modprobe. How do I get this modules loading automatically when the system boots? Currently, I have this in my /etc/modules.conf file (I did this according to a posting I found in a newsgroup): alias ide-tape off alias scsi-hostadaptor ide-scsi alias char-major-9 st When I rebooted the system, the st module loaded, but ide-scsi did not. The drive works just fine after I load the ide-scsi module manually. The kernel is configuring the tape device under /dev/hdd, but I think it should be under /dev/nst0. How do I get the kernel to not use /dev/hdd? I am running a RH9 system. Any help would be appreciated (even if it's just a pointer to the mailing list that this message should really be in). Thanks, Kanwar Sandhu
Re: Problem with chg-scsi on linux
Hi, s your changer the only device showing up in /proc/scsi/scsi? or just the only device with a LUN of 1 ? if the later then: the lun-Number in proc/scsi/scsi only tells you this is a device with more then one logical unit in a single housing. Christoph Stephen Walton wrote: On Wed, 2003-09-24 at 10:30, Joshua Baker-LePain wrote: Actually, you do (it just isn't noted in the message log. Look at the output of 'cat /proc/scsi/scsi'. The first device in there corresponds to sg0, the next to sg1, etc. This brings up a question I've been meaning to ask, though it is somewhat off topic for amanda-users. On my Linux system, modprobe sg is required to load the SCSI generic module. My tape changer is coming up as /dev/sg3 even though it is the only SCSI device in the system with a non-zero LUN as verified with cat /proc/scsi/scsi. Why?
Re: Help with writing to tape
Hmm. what about running amdump DailySet1 to actually let amnda do her work, get the dump for your /etc dir and put it to tape before you try to find a dump which has never been done until now? Christoph chris weisiger wrote: I am able to use the following commands for amanda properly: amlabel amtape amcheck but...i am unable to write to a tape(never used tape backup before, so i dont know exactly how to read the log files properly)..i am wanting to backup the server that amanda is running on so do i need amanda-client rpm installed also...if so i have it installed... this is the only thing i have in my disklist file bs1.domain.name /etc comp-root-tar i added the following to .amandahosts file: bs1.domain.name amanda i can telnet to ports 10082 and 10083 but NOT 10080 and when i run amcheck DailySet1 this is the output: Amanda Tape Server Host Check - Holding disk /data: 66999148 KB disk space available, using 66998124 KB amcheck-server: slot 3: date 20030924 label DailySet14 (first labelstr match) NOTE: skipping tape-writable test Tape DailySet14 label ok NOTE: info dir /usr/adm/amanda/normal/database: does not exist NOTE: it will be created on the next run NOTE: index dir /usr/adm/amanda/normal/index: does not exist Server check took 28.989 seconds Amanda Backup Client Hosts Check Client check: 1 host checked in 0.039 seconds, 0 problems found (brought to you by Amanda 2.4.3) when i run the following: su amanda -c amadmin DailySet1 find bs1 bash: /root/.bashrc: Permission denied the following is returned: by the way /data is the main holding disk Scanning /data... lost+found: skipping cruft directory, perhaps you should delete it. No dump to list So is there anything i overlooked or havent completed yet to write to a tape? btw also these services i have running for amanda amanda amandaidx amidxtape and i stopped iptables also Thanks
Re: Editing disklist
Hi, yes, amrecover uses disklist. To accomplish what you want, i would do the following: add an excludelist to the dle /mydisk/bigdir excluding /mydsik/bigdir/smalldir[1-n] and leave it in the disklist. this way you get 2 for the price of one: - amanda will happily restore the old backups, - if somehow a new dir gets created in /mydisk/bigdir and you miss to give it his own dle-entry it will get catched by the dle with the excludelist, and you'll see its size increase in your daily mailreports. Stefan G. Weichinger wrote: Hi, amanda-users, I want to change some DLEs from /mydisk/bigdir to /mydisk/bigdir/smalldir1 /mydisk/bigdir/smalldir2 /mydisk/bigdir/smalldir3 ... Will I be able to access the backups of /mydisk/bigdir on the older tapes I took out of the rotation already? Is it possible to find them with amrecover? Or does amrecover use disklist? Thank you, Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: Crashing machine
Hi, As many others, i guess you have a hardware-problem. Something simmilar happen to me a few years ago, a system was running fine for yaers, but suddenly it started to fail. It ran fine untill amanda kicked in to do her job, and after a short time it went south After some month of search i found out it was a new scsi disk i placed in the chain. Before i installed it, the chain was passivley terminated by a cd-rom. But that disk was the first ultra-scsi-device, and it had built in active termination. So i thought it would be a good idea to put it at the end of the chain and let do it his job. and terminate the bus. Bad idea. The internal terminators didn't do their job under load. There where no error-messages in the logfiles, as the system hadn't the chance to put them on disk. How did i find the error at least? The new disk grew out of space a few month later, and got replaced by a bigger one with working terminators and all problems went away. Since this time i only use dedicated active terminators for scsi-busses, no internal terminators of drives anymore. Doublecheck your hardware. it could be even the cpu-fan. you don't have switched on bios-throtle-control for a fan with its own termal regulation, do you? this can lead to verry strange results. Christoph Brashers, Bart -- MFG, Inc. wrote: I've been using amanda-2.4.2p2 for a long time now, without problems. In the last week or so, my Linux (2.4.20) machine has been crashing, apparently when amanda runs. I see in the various logs in /var/log when amanda (e.g. xinetd in /var/log/secure with user amanda, from 127.0.0.1) and then nothing until the restart the next morning when I restart the computer. The real kicker was just now when I ran amflush (after amcleanup) to flush the last failed dump to the disk. The system panicked after just a few minutes, with the Machine check exception (kernel panic: cpu context corrupt) error. That usually happens when the system is too hot, or you have a bad motherboard, or something. This machine has been in operation for about 6 months, so it's probably not the MB. It's not that hot in the room, and I checked that the fins on the CPU fan weren't clogged with dust. Any ideas here? Anyone heard of such a thing? Am I barking up the wrong tree thinking that amanda might be responsible for my crashes? It's a real pain, not being able to run stuff at night (and not having backups makes me nervous). Bart -- Bart Brashers, Ph.D. Air Quality Meteorologist MFG Inc. 19203 36th Ave W Suite 101 Lynnwood WA 98036-5707 [EMAIL PROTECTED] Phone: 425.921.4000 Fax: 425.921.4040
Re: Amanda and Onstream DI-30 fast
Hi, AFAIK this is a problem of the onstream firmware. amnda will not be able to work around this bug, so amanda probably will never work with these drives. Christoph [EMAIL PROTECTED] wrote: Hello Amanda-users :-) In former times I tried to make my Onstream DI-30 FAST work with amanda on SuSE 7.3 - without success. Now my question: Has things changed in amada for Onstream ? - is it possible to make it work now ?? Greetings from Wiesbaden, Henrik AktiNet IT-Services Henrik Bro Larsen [EMAIL PROTECTED]
Re: Install not clear
Hm, you hab a short look at docs/INSTALL as i read from your point 3. but you didn't do what docs/INSTALL is telling you under section 0, point A: Read this document all the way through if you had done this, you would have read section 1.1 subsection E and following, telling you how to create the makefile using configure with its various options. the document docs/INSTALL tells you all you need to get amanda running. At least it was all i needed to get it going a few years ago. but you should realy read it completley and folow it step by step. Christoph paolo wrote: Dear All I downloaded amanda-2.4.4.tar[1].gz 1- [EMAIL PROTECTED] /]# tar zxvf /mnt/cdrom/amanda-2.4.4.tar[1].gz 2- ok 3- I read yours: 1.2. BUILDING AND INSTALLING THE BINARIES A. Back at the top-level source directory (which is?) , build the sources: 1. make (don't exist) 2. su root (there isn't amnda 2.4.4) ; make install. I'm not clever but it doesn't seem very clear Thanks in advance for your help. BEFORE OF THIS EXPERIENCE 4- I have redhat9a - I tried to install amanda from install applications the system asks me CD2 and stop I type whereis amanda and the system shows me amanda: /etc/amanda /usr/lib/amanda ok [EMAIL PROTECTED] tape-src]# cd /etc/amanda [EMAIL PROTECTED] amanda]# amanda bash: amanda: command not found ... Could you help me please Thanks in advance Paolo
Re: About Linus's condemnation of Dump
Hi,
you have recognized this message was from 2001, yes?
shortly after linus message this has bee discussed here very deeply.
if you are interested in it, please go to the mailinglist-archives
and read the corresponding thread.
The result was more or less the folowing:
if you use dump the way it is designed to, you won't get in trouble
with its backups.
but dump on linux is designed only to do backups of ext2-fs, so you
won't be able at all to use it with your reiser-fs disks.
Christoph
Scott Phelps wrote:
I just stumbled over an email from Linus stating the following:
snip snip
Note that dump simply won't work reliably at all even in 2.4.x: the buffer
cache and the page cache (where all the actual data is) are not
coherent. This is only going to get even worse in 2.5.x, when the
directories are moved into the page cache as well.
So anybody who depends on dump getting backups right is already playing
russian rulette with their backups. It's not at all guaranteed to get the
right results - you may end up having stale data in the buffer cache that
ends up being backed up.
Dump was a stupid program in the first place. Leave it behind.
end snip
Read whole thing here:
http://www.cs.helsinki.fi/linux/linux-kernel/2001-16/1175.html
Anyhoo, I find myself currently using the Reiser filesystem, and I am now
considering backing up critical config files and directories on my servers
with tar and rebuilding them from scratch using XFS since that filesystem has
a working version of dump ('xfsdump').
Any comments, advice? (Does Amanda even work with xfsdump/xfsrestore?
Thanks,
Scott Phelps
Re: amrecover performance and exclude list
Hi,
youl have to put relative paths in exclude list.
example:
mount-point/dir-to-backup is: /var
file to exclude:/var/tmp/example-file
entry in file: ./tmp/example-file
Christoph
Pascal Robert wrote:
I have two questions for you:
1) any owners of HP SureStore DLT vs80 unit here ? If yes, what kind
of performance do you have with amrecover. I did a recover this
morning, it took 67 minutes to recover a single 2 bytes file. The
backup take 7 minutes so are this unit is really that slow for reading ?
I don't have a such a drive, but I should be much faster.
The 7 minutes, is that the dump time (to disk) or the time to write
to image to tape?
How large was the image? How fast is the tape for writing (see amanda
reports)? What filenumber was it on tape?
Total Full Daily
Estimate Time (hrs:min)0:02
Run Time (hrs:min) 0:47
Dump Time (hrs:min)1:00 1:00 0:00
Output Size (meg)5097.6 5097.60.0
Original Size (meg) 7855.1 7855.10.0
Avg Compressed Size (%)64.9 64.9-- Filesystems
Dumped3 3 0
Avg Dump Rate (k/s) 1439.7 1439.7--
Tape Time (hrs:min)0:33 0:33 0:00
Tape Size (meg) 5097.6 5097.60.0
Tape Used (%) 13.4 13.40.0
Filesystems Taped 3 3 0
Avg Tp Write Rate (k/s) 2597.2 2597.2--
Is the client a different machine (look for network problems)?
Did you specify amrecover_do_fsf true (should be much faster if the
image is near the end of tape).
Tried that, it's not faster.
2) our backups are done with 'dump' so I backup whole filesystems,
but I want to exclude some directories (example: /var/log and /usr).
I read
Excludes are for gnutar IRC. (Amanda is only a backup scheduler;
it uses external programs to do the actual backups. You're limited by
the functionality of those programs. Or does dump on your system allow
excludes?)
Ok, I switched to 'tar' dumps, added this directive to amanda.conf:
exclude list /var/lib/amanda/.amanda_excludes
And on each client, I created this file. But even if I put stuff in the
exclude list (for example: /var/spool), it's still being backed up.
This is my dump type:
define dumptype hard-disk-compress {
global
index yes
program GNUTAR
compress client fast
holdingdisk yes
priority high
exclude list /var/lib/amanda/.amanda_excludes
}
And a sample from my disklist:
x.cesart.local / hard-disk-compress
a little patch which made my changer working
Hi folks, i have a ADIC 12-Tape DAT autoloader which worked out of the box to 99% with chg-scsi. Only if i opend the door it gave me an error the first time i accessed it afterwards. Now the tapeunit died, and i replaced it with a HP dat24I drive, and chg-scsi stoped working. i dug into the source of amanda 2.4.4 and the messages chg-scsi gave and found two problems, one tape-related and one changer-related. the tape does enter unit-attention mode direct after loading a tape, and that caused chg-scsi to think there was something wrong with the drive. Fixed it by defining the correct answers for this tape-unit in sense.c verry similar problem for the changer, after opening the frontdoor it enters unit-attention-mode too, telling me someone opened the door... so i defined the correct codes for the changer too, and now realy all is fine with this changer and drive combination. i atach the changes i made as a patch, so everyone interested in it can have a look at it. it applys to 2.4.4p1 too. to whom should i send it to get it into the release next time? Christoph adic+C1537A.diff.gz Description: GNU Zip compressed data
Re: How can I fix this as it is failing the backup!!
Hi, you tell us your holding-area is located on /home/amanda/tmp, right? then you should hurry to your excludelist for this partition and exclude ./amanda/tmp completly from your backup. it is very bad to backup a filesystem containing the holdingdisk itself with a dumptype not excluding this area or not having the nohold option set. it will produce tons of data-waste in theimage for the partition, if it doesn't fail at all. Christoph Dalton, John L MONMOUTH ITS Multimax wrote: I fixed this by putting it in the exclude list and amdump was happy - no more errors. I do not think I need this file anyway since it is part of the holding disk??? -Original Message- From: Gene Heskett [mailto:[EMAIL PROTECTED] Sent: Friday, August 15, 2003 3:34 PM To: Dalton, John L MONMOUTH ITS Multimax; '[EMAIL PROTECTED]' Subject: Re: How can I fix this as it is failing the backup!! On Friday 15 August 2003 10:59, Dalton, John L MONMOUTH ITS Multimax wrote: FAILED AND STRANGE DUMP DETAILS: /-- XX/home lev 2 STRANGE sendbackup: start [XX:/home level 2] sendbackup: info BACKUP=/bin/tar sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/bin/tar -f... - sendbackup: info COMPRESS_SUFFIX=.gz sendbackup: info end ? gtar: ./amanda/tmp/20030815/XX._home.2.tmp: file changed as we read it | Total bytes written: 234874880 (224MB, 5.9MB/s) sendbackup: size 229370 sendbackup: end I don't imagine you can unless you can stop the activity in the /home filesystem while amanda is running.
