Re: could not access device
On Tue, 1 Oct 2002 at 6:01pm, Nigel Stepp wrote I've been thinking about, and researching this problem for a while now, but it seems no one else is having it. *snip* Has anyone seen anything like this before? By the way, this is running on linux 2.2.13. Wow. Any reason for such an old kernel? selfcheck: checking disk sda1 selfcheck: device sda1 selfcheck: could not access sda1 (sda1): No such file or directory Try applying the advfs.patch from http://www.amanda.org/patches.html and reinstalling on the server and affected clients. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Fwd: DailySet4 AMANDA MAIL REPORT FOR October 1, 2002 (fwd)
I know dogs is offline, but what is this telling me, do I need to allocate
more tapes for a run, or tell it that the tapes are smaller , or what?
- -- Forwarded Message --
Subject: DailySet4 AMANDA MAIL REPORT FOR October 1, 2002
Date: Wed, 02 Oct 2002 00:10:08 -0500 (EST)
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
These dumps were to tapes DailySet130, DailySet131, DailySet132, DailySet102.
*** A TAPE ERROR OCCURRED: [[writing file: I/O error]].
Some dumps may have been left in the holding disk.
Run amflush to flush them to tape.
The next 4 tapes Amanda expects to used are: DailySet133, DailySet134,
DailySet139, DailySet140.
FAILURE AND STRANGE DUMP SUMMARY:
dogs /export/home lev 0 FAILED [Request to dogs timed out.]
dogs / lev 0 FAILED [Request to dogs timed out.]
flash /export/home lev 0 FAILED [data write: Broken pipe]
flash /export/home lev 0 FAILED [dump to tape failed]
trees /opt/cp30 lev 0 FAILED [data write: Broken pipe]
trees /opt/cp30 lev 0 FAILED [dump to tape failed]
trees /opt/cp30 lev 0 FAILED [out of tape]
trees /opt/cp30 lev 0 FAILED [data write: Broken pipe]
trees /opt/cp30 lev 0 FAILED [dump to tape failed]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:53
Run Time (hrs:min)23:37
Dump Time (hrs:min) 25:30 25:05 0:25
Output Size (meg) 132561.0130177.7 2383.2
Original Size (meg) 205222.0202833.7 2388.2
Avg Compressed Size (%)50.4 50.4 90.9 (level:#disks ...)
Filesystems Dumped 77 72 5 (1:5)
Avg Dump Rate (k/s) 1478.9 1476.5 1623.2
Tape Time (hrs:min) 10:41 10:37 0:04
Tape Size (meg) 132563.4130180.0 2383.4
Tape Used (%) 243.3 238.94.4 (level:#disks ...)
Filesystems Taped77 72 5 (1:5)
Avg Tp Write Rate (k/s) 3530.2 3488.010364.4
FAILED AND STRANGE DUMP DETAILS:
/-- flash /export/home lev 0 FAILED [data write: Broken pipe]
sendbackup: start [flash:/export/home level 0]
sendbackup: info BACKUP=/usr/sbin/ufsdump
sendbackup: info RECOVER_CMD=/usr/sbin/ufsrestore -f... -
sendbackup: info end
| DUMP: Writing 32 Kilobyte records
| DUMP: Date of this level 0 dump: Tue Oct 01 10:09:05 2002
| DUMP: Date of last level 0 dump: the epoch
| DUMP: Dumping /dev/rdsk/c0t3d0s0 (flash:/export/home) to standard output.
| DUMP: Mapping (Pass I) [regular files]
| DUMP: Mapping (Pass II) [directories]
| DUMP: Estimated 23794754 blocks (11618.53MB) on 0.17 tapes.
| DUMP: Dumping (Pass III) [directories]
| DUMP: Dumping (Pass IV) [regular files]
| DUMP: 10.17% done, finished in 1:28
| DUMP: 22.67% done, finished in 1:08
| DUMP: 32.82% done, finished in 1:01
| DUMP: 43.93% done, finished in 0:51
| DUMP: 53.31% done, finished in 0:43
\
/-- trees /opt/cp30 lev 0 FAILED [data write: Broken pipe]
sendbackup: start [trees:/opt/cp30 level 0]
sendbackup: info BACKUP=/usr/sbin/ufsdump
sendbackup: info RECOVER_CMD=/usr/sbin/ufsrestore -f... -
sendbackup: info end
| DUMP: Writing 32 Kilobyte records
| DUMP: Date of this level 0 dump: Tue Oct 01 16:57:15 2002
| DUMP: Date of last level 0 dump: the epoch
| DUMP: Dumping /dev/rdsk/c2t0d0s0 (trees:/opt/cp30) to standard output.
| DUMP: Mapping (Pass I) [regular files]
| DUMP: Mapping (Pass II) [directories]
| DUMP: Estimated 132476274 blocks (64685.68MB) on 0.96 tapes.
| DUMP: Dumping (Pass III) [directories]
| DUMP: Dumping (Pass IV) [regular files]
| DUMP: 1.56% done, finished in 10:30
| DUMP: 4.88% done, finished in 6:29
| DUMP: 9.08% done, finished in 5:00
| DUMP: 13.76% done, finished in 4:10
| DUMP: 18.92% done, finished in 3:34
| DUMP: 23.90% done, finished in 3:11
| DUMP: 28.15% done, finished in 2:58
| DUMP: 32.37% done, finished in 2:47
| DUMP: 35.69% done, finished in 2:42
| DUMP: 38.78% done, finished in 2:37
| DUMP: 43.77% done, finished in 2:21
| DUMP: 48.29% done, finished in 2:08
| DUMP: 52.11% done, finished in 1:59
| DUMP: 53.59% done, finished in 2:01
| DUMP: 55.06% done, finished in 2:02
| DUMP: 56.12% done, finished in 2:05
| DUMP: 57.22% done, finished in 2:07
| DUMP: 58.58% done, finished in 2:07
| DUMP: 59.85% done, finished in 2:07
| DUMP: 60.97% done, finished in 2:08
| DUMP: 62.24% done, finished in 2:07
| DUMP: 63.38% done, finished in 2:07
| DUMP: 64.42% done, finished in 2:07
| DUMP: 65.77% done, finished in 2:04
| DUMP: 66.94% done, finished in 2:03
| DUMP: 68.10% done, finished in 2:01
| DUMP: 68.89% done, finished in 2:02
| DUMP: 69.75% done, finished in 2:01
| DUMP: 70.70% done, finished in 2:00
| DUMP: 71.96% done, finished in 1:57
| DUMP: 73.27% done, finished in 1:53
| DUMP: 74.51% done, finished in 1:49
|
tape changer
Hi there I'm trying to use a Dell Powervault T130 with AMANDA and I'm having some difficulties. Specifically... backup@amanda:~$ amtape Changer reset amtape: could not reset changer: /dev/sg0: failed backup@amanda:~$ amtape Changer taper amtape: scanning for a new tape. amtape: could not get changer info: /dev/sg0: failed I'm using the chg-scsi changer option - could anyone indicate what I've missed? Regards Mart.
RE: tape changer
Here's a few things to try: 1. make the tape changer work separately from any AMANDA components. You might need zd-mtx or similar. (I use the ch driver and utilities from http://www.strusel007.de/linux/changer.html.) I'm guessing you're using some flavor of linux based on the device name /dev/sg0. 2. Make AMANDA work with the tape drive in the changer using the chg-manual changer. This means that before every backup, you will have to use the control commands from step 1 to load the right tape, but your backups will be working. 3. try the AMANDA changer script that matches the changer-driver you've selected. If you're using the one I linked to above, search the list archives for my chg-userland perl script that glues it to AMANDA, or let me know if you can't find it, and I'll re-post it. -Original Message- From: Martin A. Brooks [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 02, 2002 11:13 AM To: [EMAIL PROTECTED] Subject: tape changer Hi there I'm trying to use a Dell Powervault T130 with AMANDA and I'm having some difficulties. Specifically... backup@amanda:~$ amtape Changer reset amtape: could not reset changer: /dev/sg0: failed backup@amanda:~$ amtape Changer taper amtape: scanning for a new tape. amtape: could not get changer info: /dev/sg0: failed I'm using the chg-scsi changer option - could anyone indicate what I've missed? Regards Mart.
Re: could not access device
On Wed, 2 Oct 2002, Joshua Baker-LePain wrote: On Tue, 1 Oct 2002 at 6:01pm, Nigel Stepp wrote [snip kernel 2.2.13] Wow. Any reason for such an old kernel? I have had no need to upgrade. This machine used to serve out home directories over nfs, but now it just does amanda (in a private network). selfcheck: checking disk sda1 selfcheck: device sda1 selfcheck: could not access sda1 (sda1): No such file or directory Try applying the advfs.patch from http://www.amanda.org/patches.html and reinstalling on the server and affected clients. Hmm, isn't this only if I am using the advfs filesystem? All of the filesystems in question are ext2. -- Nigel D. Stepp Atistar Internet Services [EMAIL PROTECTED] http://www.atistar.net/
Re: could not access device
On Tue, 1 Oct 2002, Frank Smith wrote: --On Tuesday, October 01, 2002 18:01:22 -0700 Nigel Stepp [EMAIL PROTECTED] wrote: selfcheck: checking disk sda6 selfcheck: device /usr selfcheck: OK selfcheck: checking disk sda1 selfcheck: device sda1 selfcheck: could not access sda1 (sda1): No such file or directory selfcheck: checking disk sda5 selfcheck: device /home selfcheck: OK selfcheck: checking disk sda7 selfcheck: device /var selfcheck: OK Any chance your disklist dumptypes are out of whack and you are perhaps trying to back up a raw filesystem with tar? All of the dumptypes being used (I can post them if you like) are using GNUTAR as the dump program. Something that was puzzling me is that for each device, the selfcheck prints out the mount point, except for sda1. I imagine that this may be related to the problem, but I see no reason for the difference. I have replaced sda1 in my disklist file with /. That took the error out of amcheck. I will wait and see if there is an error in amdump. In the past when I have done something like this the error merely changed to the 'disk offline' error. -- Nigel D. Stepp Atistar Internet Services [EMAIL PROTECTED] http://www.atistar.net/
Re: Fwd: DailySet4 AMANDA MAIL REPORT FOR October 1, 2002 (fwd)
On Wednesday 02 October 2002 10:55, F.M. Taylor wrote: I know dogs is offline, but what is this telling me, do I need to allocate more tapes for a run, or tell it that the tapes are smaller , or what? Whew! Lemme snip to the heart of the matter. planner: Full dump of trees:/ promoted from 3 days ahead. taper: tape DailySet130 kb 47288448 fm 71 writing file: short write This normally means EOT has been encountered. taper: retrying online:/lang.0 on new tape: [writing file: short write] taper: tape DailySet131 kb 61882304 fm 5 writing file: short write taper: retrying flash:/export/home.0 on new tape: [writing file: short write] taper: tape DailySet132 kb 43417664 fm 4 writing file: short write taper: retrying trees:/opt/cp30.0 on new tape: [writing file: short write] taper: tape DailySet102 kb 1092032 fm 1 writing file: I/O error I started to say: that you have an entry in your disklist thats bigger than one tape. Amanda cannot span one disklist entry across 2 or more tapes, so you will need to break that entry down into its individual subdirs. This also means you have to use tar. Get the absolute latest as there has been a security problem found and fixed just this past week. What happened above was that its used the available tapes, each in turn, trying to make it fit 100% on one tape. When it couldn't, it just kept advancing the tape till it had used them all. My one Q there is how did DailySet102 get to be the last one it tried? Did it recycle back to slot one maybe? But now that I've reformatted that error list so its readable, its obvious that each time it advanced to the next tape, it did fit the dump in question on that next tape until the last tape, which was probably the head of the rack, it haveing wrapped around to tape 1 again, and that tape wasn't due to be overwritten yet, so it exits with error. The second, and more likely impression I'm getting is that you probably need to turn off any hardware compression the drive uses, then rerun the tapetype program to find the true size of a tape. I don't think amanda will let that happen if it knows the true capacity of the tape as amanda counts bytes actually going to the media and the use of hardware compression in the drive hides this from amanda, hence she allowed the overrun, possible because the tapetype spec in the amanda.conf file you used has the factories occasionally optimistic size claims of doubleing the capacity by useing their compression. Thats not a Good Thing(tm) Then use a dumptype containing 'compress client best', which can beat the socks off the hardware compressor any day of the month, but it will keep the clients busy for a while doing it. Its use will also reduce the network bandwidth useage, as far fewer bytes need to be moved to the server. I have some entries in my disklist that regularly compress to less than 15% of their original size, useing a 'compress server best' dumptype since the server is 5x faster than the 1 client here. You may still need to break up those entries in your disklist whose sizes are approaching the size of a full tape though. This can be advantagious because even if it does hit EOT by accident, the carried over dumpfile will be smaller, thereby wasting less of a tapes capacity when this occurs. I shoot for half a tape or less. Oh, and you still need to go get the latest tar from your vendor as soon as they make it available. Several already have fixed versions available. The lastest snapshot of amanda-2.4.3b4-20020930 wouldn't hurt either, it runs great here. [snip] -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.17% setiathome rank, not too shabby for a WV hillbilly
Re: could not access device
Joshua Baker-LePain wrote: *snip* Has anyone seen anything like this before? By the way, this is running on linux 2.2.13. Wow. Any reason for such an old kernel? Completely off topic, but... I do run such an old kernel on a machine. Reason: why shut it down when it works fine? I've never shut it down since the last boot more than two years ago now. uptime shows 321 days, but that's because around 497 days uptime the counter wrapped (*); the real uptime is 818 days. I had to reboot the machine beginning July 2000 because I moved it to another room. The machine served / is serving a lot of duties: it was our main mail system for some months, then our secondary MX server for over a year; it's also our primary DHCP server; it's one of our secondary DNS servers; and it runs a few internal websites with apache, like our bugzilla database with mysql backend. I did install/upgrade software, but never upgraded the kernel, so I never had to reboot it. The problem with machines with such an uptime is that the longer you have it, the harder you try to avoid reboots :-) Amanda client software works fine on that machine too. (*) that bug is solved in recent kernels: they used a 64 bit value instead of a 32 bit value for the clock ticks. They are measured in 1/100th of a second and 2^32 / (86400*100) = 497 days. -- Paul Bijnens, Xplanation Tel +32 16 40.51.40 Interleuvenlaan 15 H, B-3001 Leuven, BELGIUM Fax +32 16 40.49.61 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 * ***
Re: Fwd: DailySet4 AMANDA MAIL REPORT FOR October 1, 2002 (fwd)
F.M. Taylor wrote: I know dogs is offline, but what is this telling me, do I need to allocate more tapes for a run, or tell it that the tapes are smaller , or what? *snip* taper: tape DailySet130 kb 47288448 fm 71 writing file: short write taper: retrying online:/lang.0 on new tape: [writing file: short write] taper: tape DailySet131 kb 61882304 fm 5 writing file: short write taper: retrying flash:/export/home.0 on new tape: [writing file: short taper: tape DailySet132 kb 43417664 fm 4 writing file: short write taper: retrying trees:/opt/cp30.0 on new tape: [writing file: short write] taper: tape DailySet102 kb 1092032 fm 1 writing file: I/O error I would expect that you hit end of tape around the same value on all of your tapes, at least, if they have the same capacity. But the first one wrote 47 GB, the second wrote 61 GB, and the third wrote 43 GB. The last one is complete bad: it wrote only 1 GB and gave up. The numbers that you see there are the exact number of kbytes when it ran into end of tape (at least, they are consistent in my installation). End-of-tape and write error are almost the same for most drives, that's why I suspect your tapes or drive or cable etc. has serious problems. Or is there another explanation for the differences in numbers? -- Paul Bijnens, Xplanation Tel +32 16 40.51.40 Interleuvenlaan 15 H, B-3001 Leuven, BELGIUM Fax +32 16 40.49.61 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 * ***
Re: could not access device
On Wed, 2 Oct 2002 at 9:41am, Nigel Stepp wrote selfcheck: checking disk sda1 selfcheck: device sda1 selfcheck: could not access sda1 (sda1): No such file or directory Try applying the advfs.patch from http://www.amanda.org/patches.html and reinstalling on the server and affected clients. Hmm, isn't this only if I am using the advfs filesystem? All of the filesystems in question are ext2. From the page above: It also cleans up some problems with Linux device name determinations. Specifically, it seems to help when amanda can't figure out the root partition. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Win2K weirdness...
Hi, This is driving me nuts. I have a windows 2K server setup for Amanda to back it up, in theory everything should work fine but it keeps failing. I can use smbclient to connect from the Amanda server just fine, and amcheck reports that the host is configured correctly (ie amcheck returns no errors). However when the nightly backups run I get the following errors, console is the amanda server, frontoffice is the 2K server: console//frontoffice/backup lev 0 FAILED [disk //frontoffice/backup offline on console?] In the daily host check mail I get this: NOTE: info dir /var/log/amanda/Core/curinfo/console/__frontoffice_backup: does not exist NOTE: index dir /var/log/amanda/Core/index/console/__frontoffice_backup: does not exist The missing info and index files aren't surprising since this host has never been backed up. I'm running Amanda version 2.4.2p2, samba 2.2.5-1. Console is a RedHat 7.2 box, vanilla install except for amanda and samba. Frontoffice is a win2k box with SP2 installed, or so our windows guy says. Any suggestions as to why this might be happening? Thanks in advance, Josh
due vs dumpcycle, runspercycle, runtapes, etc
Question: amadmin config due
doesn't give the due dates that I expect. What am I doing wrong?
Am I mis-interpreting some of the basic params regarding
dumpcycles, etc.?
Config values are at bottom, since lengthy.
SCENARIO:
I started a new config and all new tapes on Monday. Did an amdump on
Monday and Tuesday (2, two!). Each took only 1 tape, not 2 as allowed
(but not required).
Today is Wednesday, so I expect due to
tell me they are due in 5 days (by next Monday), since dumpcycle=1 week=7
days.
Filesystem luthor.../export/home2 (*) behaves as expected.
One dump was promoted and done early, to start things becoming balanced.
So luthor.../export/home1 (**) is not due for 6 days ... also as expected.
All good, so far.
The other file systems are not doing what *I* expect.After 1 day, they
said due in 9 days. After 2 days, they say due in 8 days. It almost
seems that they are starting from (runspercycle * runtapes) rather
than the dumpcycle value.
Or am I just losing my mind??
Deb
==
$ amadmin daily due
Due in 8 days: bdback.FQDN:/var
Due in 6 days: luthor.FQDN:/export/home1**
Due in 5 days: luthor.FQDN:/export/home2*
Due in 8 days: luthor.FQDN:/export/home1/neuffer
Due in 8 days: luthor.FQDN:/export/home1/syphers
===
dumpcycle 1 week# the number of days in the normal dump cycle
runspercycle 5 # the number of amdump runs in dumpcycle days
runtapes 2 # some jobs take 2 tapes so allow up to 2 every day
tapecycle 50 tapes # the number of tapes in rotation
do comments on the line cause problems???
# these 5 dumptypes are in a global file (configMAIN.include)
# which is included in each config's amanda.conf
# via includefile /usr/local/etc/amanda/configMAIN.include
define dumptype BDglobal {
comment Global definitions
index yes
record yes
priority medium
compress client fast
}
define dumptype with-tar {
program GNUTAR
}
define dumptype BDtar {
BDglobal
with-tar
maxdumps 2
}
define dumptype BDnormal {
BDglobal
record yes
}
define dumptype amanda_server {
BDglobal
priority high
# so the amanda server backup is FIRST/EARLY on the tape
}
# in this config's amanda.conf
define dumptype luthor-home1 {
BDtar
exclude list /usr/local/ap/var/amanda/home1.exclude
}
define dumptype luthor-home2 {
BDtar
exclude list /usr/local/ap/var/amanda/home2.exclude
}
define interface localdisk {
comment a local disk
use 1000 kbps
}
# disklist
bdback.FQDN /var amanda_server -1 localdisk
luthor.FQDN /export/home1 luthor-home1 1
luthor.FQDN /export/home2 luthor-home2 2
luthor.FQDN /export/home1/neuffer BDtar 1 #100059
luthor.FQDN /export/home1/syphers BDtar 1 #95773
--- Are my comments re: size causing problems? But the first one
--- bdback... /varalso doesn't work right, and it doesn't have
--- a comment on the line.
installing into /opt
I decided to change prefix to /opt/amanda. Several things still seem to look in /usr/local instead of /opt/amanda... i.e. I had to make a sym link to amanda.conf in /usr/local/etc/amanda/confname because it didn't automatically look in $prefix. Is it just me, or do people not generally change that option and just live with it going into /usr/local??? Jerry __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com
Re: installing into /opt
Is it just me, or do people not generally change that option and just live with it going into /usr/local??? I've always considered /opt a Sun abberation and never deliberately put anything there. I want my systems to have as little as possible on filesystems that an OS reinstall will wipe.
Re: installing into /opt
Jerry wrote: Is it just me, or do people not generally change that option and just live with it going into /usr/local??? I use the followin gconfigure options (and more): ./configure --prefix=/opt/amanda\ --sysconfdir=/etc/opt/amanda\ --localstatedir=/var/opt/amanda \ --with-PACKAGE=no \ --with-configdir=/etc/opt/amanda\ --with-gnutar=/opt/gtar-amanda/bin/amtar\ --with-gnutar-listdir=/var/opt/amanda/gnutar-lists \ --with-tmpdir=/var/opt/amanda/tmp \ --with-debugging=/var/opt/amanda/debug \ --with-datadir=/opt/amanda/share $ ls -la /usr/local drwxr-xr-x 2 root other512 Aug 15 21:42 . drwxr-xr-x 36 root sys 1024 Aug 15 14:30 .. $ And Amanda is perfectly happy. Sven
Problem with amrestore
Hey, I just started playing with amanda with a very simple setup (one system plus one 1-slot DLT drive). After performing my first amdump, and properly writing 3.8gb of stuff, I can't seem to restore it... Here's what I get: bash-2.05a$ amrestore /dev/nst0 backup amrestore: 0: skipping start of tape: date 20021002 label DailySet-01 amrestore: 1: skipping localhost._data1.20021002.0 amrestore: 2: reached end of tape: date 20021002 So it flat out doesn't want to restore that portion of the tape. (I know you can go through more complex things such as piping the restoration to recover, I'm just trying to get the basics down first). After running an incremental dump (and adding 2.4mb of stuff onto my tape) and rerunning amrestore, it still skips the 3.8gb archive, but restores the 2.4mb archive into the current directory... What am I doing wrong? Thanks, Rob
