Re: win32
On Thu 19 Sep 02 16:32, Christophe Kalt wrote: Also, it seems that it would be much less work to actually port the existing (UNIX) amanda source (at least or at most?;) the client parts. Having a separate project really doesn't seem right. Erm... ever tried to port code from Unix to Windows? Ever wonder why there is so little Opensource Windows code? ..Brian -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
Colorado, again
Hi all,
Still gnashing my teeth over this HP Colorado drive. Found some pointers
which suggested disabling DMA -- have done so for both drives on that
controller. Got 3 successful dumps since Thursday (3GB written).
The problem today is as follows. The dumps failed with an Input/Output
error after 299kb written. When amcheck ran (without changing the tape) it
failed before reading the tape. My logs give me:
Sep 18 10:45:01 valhalla kernel: st: Version 20020205, bufsize 32768, wrt
30720, max init. bufs 4,
s/g segs 16
Sep 18 10:45:01 valhalla kernel: Attached scsi tape st0 at scsi0, channel 0,
id 0, lun 0
Sep 18 10:45:01 valhalla kernel: st0: Block limits 6684 - 1711130 bytes.
Sep 18 11:00:01 valhalla kernel: scsi : aborting command due to timeout : pid
329140, scsi0, channel 0, id 0, lun 0 Read (6) 01 00 00 40 00
Sep 18 11:00:01 valhalla kernel: hdd: irq timeout: status=0xc0 { Busy }
Sep 18 11:00:02 valhalla kernel: hdd: ATAPI reset complete
Sep 18 11:00:02 valhalla kernel: hdd: irq timeout: status=0x80 { Busy }
Sep 18 11:00:02 valhalla kernel: hdd: ATAPI reset complete
Sep 18 11:00:02 valhalla kernel: hdd: irq timeout: status=0x80 { Busy }
Sep 18 11:00:02 valhalla kernel: st0: Error 2707 (sugg. bt 0x20, driver
bt 0x7, host bt 0x7).
Sep 18 11:20:01 valhalla kernel: st: Unloaded.
Can I be sure that those IRQ timeouts are due to a faulty device? Can there
be another explanation?
Regards,
Brian Jonnes
--
Init Systems - Linux consulting
031 767-0139082 769-2320[EMAIL PROTECTED]
Re: Tape technology
First off, thanks to all for the info; I at least now have a base from which to start. the small business with say 5-10 major machines to backup, a dedicated software raid server with a rack of big drives, running rsync, also has a cost and speed advantage. I know of one such setup with a capacity of 320 gigs in 4 160 gig drives that does its Hell, you might as well start talking Coda to me. Which is another possibility. about 1600 USD at the time. Is it as dependable as tape? Time will tell. Can you take it offsite? In a sense, yes, by cycling enough drives thru each slot in the array and letting the raid rebuild I'm not really keen on this idea. Although relative to the price of a DDS drive it is affordable (for just one or two harddrives). My main problem is that the drives will be handled by average users. Hrm. ..Brian -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
Re: Tapetype
Not so sure about this. I had a Travan-4 tape whizzing away for 24 hours. Now, I've had full tapes before, and the dump time... lemme pull out the reports: Output Size (meg)3863.3 3829.7 33.6 ... Tape Time (hrs:min)2:15 2:05 0:10 Tape Size (meg) 3864.1 3830.0 34.1 Tape Used (%) 101.7 100.80.9 (level:#disks ...) So for a tapetype run it should take 4h30... Give it 5 hours. I gave up on it and went to the FAQO. ..Brian On Thu 12 Sep 02 17:15, Gene Heskett wrote: On Thursday 12 September 2002 10:48, Mozzi wrote: Hi Watch out for tapetype!!! I have a Tandberg VS80 DLT 40/80 Gig drive I gave it the command #./tapetype -e 40960 -f /dev/nst0 -t TandbergVS80 It has been going for 26 hours now,and no end in sight. Mozzi It will get done at some point. It has to write the tape completely full twice, and a slow writing big tape will take a while. -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
Re: Tape DDS-3 values
On Thu 12 Sep 02 16:38, Niall O Broin wrote: This is true but as a friend pointed out to me recently when I was having some tape reading problems - if you get some bit errors reading a tar file from a tape, most likely asll you will lose is the affected file. If OTOH you get bit errors reading a gzipped tar file, you most likely will not be able to read anything after the bit errors. Just something to be aware of. So... when, and how much work is it to get bzip2 used. Apparently it doesn't suffer from this problem? If I were to replace (by hook or by crook) the COMPRESS_PATH to bzip2 would that work? And what is the opinion of the Right Way to do this? Regards, Brian -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
Re: crontab
On Tue 10 Sep 02 18:53, Gene Heskett wrote: Don't feel like the lone stranger Brian. Somebody really *should* write a book on howto use cron. No denigration of Paul Vixie intended, but the docs (what there is) suck. But I guess thats man 5 crontab isn't _too_ bad. what we get when a usefull utility gets into the habit because nothing else does the job quite as elegantly, particularly one written back in jurrasic computer times and which is probably old We should replace it with... Unix Task Scheduler!!! Ha! And you have to have a web-browser to configure it. ..Brian -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
Re: HP Colorado, ide-scsi
I'm assuming it is from the head of the tape; this was an amdump. ..Brian On Mon 09 Sep 02 20:43, Gene Heskett wrote: On Monday 09 September 2002 12:14, Brian Jonnes wrote: On Mon 09 Sep 02 14:26, Gene Heskett wrote: On Monday 09 September 2002 02:39, Brian Jonnes wrote: Just a brief note: I did some tests on the w/end and I had 3 out of 4 successful dumps (on the same tape). Will see if HP's test-tools give me any more info. ..Brian And what happened to the try that didn't work? 400MB written. Then writing filemark: Input/output error. And was that from the head of the tape, or appending to it? -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
Re: crontab
On Mon 09 Sep 02 22:14, Chris Bourne wrote: 0 14 * * 1-6/usr/sbin/amcheck [EMAIL PROTECTED] DailySet1 0 1 * * 1-6/usr/sbin/amtape DailySet1 slot next 0 2 * * 0/usr/sbin/amtape DailySet1 clean 0 2 * * 1-6/usr/sbin/amdump DailySet1 Just one suggestion: You are running amcheck at 14h00 Monday to Friday, and amdump 02h00 Monday to Friday. Not sure if this is what you want; I'd imagine you want: 0 2 * * 2-7 /usr/sbin/amdump DailySet1 That is, 02h00 Tuesday to Sunday. Rgds, Brian -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
Re: HP Colorado, ide-scsi
On Mon 09 Sep 02 00:24, Gene Heskett wrote: Humm, fakeroot? Odd indeed. Not saying its wrong, but... Whats this fakeroot do? I haven't gone into details, but I think it mainly fakes file permissions. The main use is that you don't have to have _real_ root to do stuff which doesn't really necessitate it. Debian has such a thing as auto-builds, and for various reasons it makes sense not to have to have root to construct package files. For *most* systems, amanda should be built by the user thats going to run it from that users crontab. But amanda does its own su- when the time comes, and in order for all the perms to be set right, root must install, same as your's. The package scripts sort out the file permissions before package construction (make install isn't used directly). ..Brian -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
Re: HP Colorado, ide-scsi
Just a brief note: I did some tests on the w/end and I had 3 out of 4 successful dumps (on the same tape). Will see if HP's test-tools give me any more info. ..Brian -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
Re: HP Colorado, ide-scsi
On Mon 09 Sep 02 14:26, Gene Heskett wrote: On Monday 09 September 2002 02:39, Brian Jonnes wrote: Just a brief note: I did some tests on the w/end and I had 3 out of 4 successful dumps (on the same tape). Will see if HP's test-tools give me any more info. ..Brian And what happened to the try that didn't work? 400MB written. Then writing filemark: Input/output error. -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
Re: HP Colorado, ide-scsi
On Fri 06 Sep 02 16:59, Jon LaBadie wrote:
level 0 and degraded mode? Aren't these non-sequitors? I thought degraded
mode meant falling back to incrementals because there was no place to put
the level 0's. I.e. the tape was not working and the holding disk did not
have enough unreserved space to hold the level 0's. So where would you
like amanda to put your huge level 0's if it can't put it to tape or to
disk?
Sorry, I think what I should be doing is splitting the amdump and amflush. In
other words, all dumps go to disk, and then I can manually flush ('cause I'm
having this intermittence).
But the report does say
driver: going into degraded mode because of tape error.
Even though I do have plenty holding disk (Remember -- 4GB tapes):
Holding disk /export/backupstore: 26773908 KB disk space available, that's
plenty
Although before I complain about _this_ problem, I should probably upgrade.
Like I mentioned to someone else -- I'm being a distro weenie. I _like_
everything Debianized -- will see if the debian package scripts drop in over
the new version.
By the way, the latest beta is considered stable?
..Brian
--
Init Systems - Linux consulting
031 767-0139082 769-2320[EMAIL PROTECTED]
Re: HP Colorado, ide-scsi
On Sun 08 Sep 02 15:34, Gene Heskett wrote: Then, if you are sure the kernels ide-scsi support is working, I'm of the opinion that this drive should be taken to a winderz box, and the software on the cd that came with it be used to verify that it is indeed working. I've had quite a bit of trouble with a Will do that. Things like where does it keep its configs, what are its owner:group settings, and anything else that I set in a script I use to do the configuration: Yeah got all that. Almost there. Just gotta add a few patches (Debian stores dumpdates in /var/lib and amandates in /var/lib/amanda). The configure scripts were screwing me around; autoconf was getting re-called (because a Makefile.am file had been patched), and it was dumping bogus Makefiles in the source tree. Got around that by making sure the date of Makefile.am didn't get changed Remember, amanda is configured and built as the user amanda, but must be installed by root. This is where debian is a little different. Build it as whoever. Package it with fakeroot, install it as root. ..Brian -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
Re: HP Colorado, ide-scsi
On Fri 06 Sep 02 16:59, Jon LaBadie wrote: On Fri, Sep 06, 2002 at 11:01:45AM +0200, Brian Jonnes wrote: Pulled the tape out, plugged it back in, and now its dumping fine. Can anyone make sense of this? I don't use your systems but ISTR people mentioning using mt to set the block size to 32K. Tried that just now; failed. Now the strange thing is that I'm getting _partial_ success now. The taper line in NOTES gives me (as an example): taper: tape DAILY_02 kb 467776 fm 48 writing filemark: Input/output error Where previously it was giving me kb 0 (with ide-tape). Again I stress, some of the dumps finish fine. I got just under 2GB written on Thursday morning, but Friday and Saturday have now failed (Friday's got 64kb written; tried an amflush and it got 35MB written). I'm now guessing that ide-tape was merely _reporting_ that 0k was written; ide-scsi is now being more accurate with regards to how much data is written before failure. I think I'm gonna throw this drive against the wall! As I've mentioned, I already had the unit swapped out. Right now I can't imagine it being anything else, 'cause the errors are distributed throughout the tape cycle. ..Brian BTW is there a way of getting amanda to put level 0's in degraded mode? I'd still like full dumps when I have to manually run amdump. level 0 and degraded mode? Aren't these non-sequitors? I thought degraded mode meant falling back to incrementals because there was no place to put the level 0's. I.e. the tape was not working and the holding disk did not have enough unreserved space to hold the level 0's. So where would you like amanda to put your huge level 0's if it can't put it to tape or to disk? What's your holding disk space and reserve % situation? -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
Re: HP Colorado, ide-scsi
Okay here's another confusion: Why do the block-limits change each time
kernel module st gets loaded:
Sep 7 10:02:53 valhalla kernel: st0: Block limits 4931 - 13329843 bytes.
Sep 7 10:28:34 valhalla kernel: st0: Block limits 17664 - 11931656 bytes.
Sep 7 12:10:27 valhalla kernel: st0: Block limits 512 - 43129 bytes.
What do those numbers mean??
Regards,
Brian
On Fri 06 Sep 02 16:59, Jon LaBadie wrote:
On Fri, Sep 06, 2002 at 11:01:45AM +0200, Brian Jonnes wrote:
Hi all,
I'm getting this in my kern.log's:
---
Sep 6 00:45:01 valhalla kernel: st: Version 20020205, bufsize 32768, wrt
30720, max init. bufs 4, s/g segs 16 Sep 6 00:45:01 valhalla kernel:
Attached scsi tape st0 at scsi0, channel 0, id 0, lun 0 Sep 6 00:45:01
valhalla kernel: st0: Block limits 25976 - 6841632 bytes. Sep 6 01:18:39
valhalla kernel: st0: Error with sense data: Info fld=0x10200, Deferred
st09:00: sense key Medium Error Sep 6 01:18:39 valhalla kernel:
Additional sense indicates Sequential positioning error Sep 6 01:30:01
valhalla kernel: st: Unloaded.
---
This was from an amdump, which failed after 64kb written.
A little bit later, running an amcheck:
---
Sep 6 09:54:45 valhalla kernel: st: Version 20020205, bufsize 32768, wrt
30720, max init. bufs 4, s/g segs 16 Sep 6 09:54:45 valhalla kernel:
Attached scsi tape st0 at scsi0, channel 0, id 0, lun 0 Sep 6 09:54:45
valhalla kernel: st0: Block limits 11268 - 112641 bytes. Sep 6 10:09:45
valhalla kernel: scsi : aborting command due to timeout : pid 72600,
scsi0, channel 0, id 0, lun 0 Read (6) 01 00 00 40 00 Sep 6 10:09:45
valhalla kernel: hdd: irq timeout: status=0xc0 { Busy } Sep 6 10:09:45
valhalla kernel: hdd: ATAPI reset complete
Sep 6 10:09:45 valhalla kernel: hdd: irq timeout: status=0x80 { Busy }
Sep 6 10:09:46 valhalla kernel: hdd: ATAPI reset complete
Sep 6 10:09:46 valhalla kernel: hdd: irq timeout: status=0x80 { Busy }
Sep 6 10:09:46 valhalla kernel: st0: Error 2707 (sugg. bt 0x20,
driver bt 0x7, host bt 0x7). Sep 6 10:20:01 valhalla kernel: st:
Unloaded.
---
Pulled the tape out, plugged it back in, and now its dumping fine. Can
anyone make sense of this?
I don't use your systems but ISTR people mentioning using mt to set the
block size to 32K.
BTW is there a way of getting amanda to put level 0's in degraded mode?
I'd still like full dumps when I have to manually run amdump.
level 0 and degraded mode? Aren't these non-sequitors? I thought degraded
mode meant falling back to incrementals because there was no place to put
the level 0's. I.e. the tape was not working and the holding disk did not
have enough unreserved space to hold the level 0's. So where would you
like amanda to put your huge level 0's if it can't put it to tape or to
disk?
What's your holding disk space and reserve % situation?
--
Init Systems - Linux consulting
031 767-0139082 769-2320[EMAIL PROTECTED]
Tape technology
Hi all, Perhaps this is not quite the place for this question, but I hope it won't offend anyone ;) I will be looking to get a new tape drive, but am not very familiar with the current technology. I have heard of DDS, DAT and have used Travan. As far as I'm concerned, the Travan is out of the question, 'cause the tapes are so expensive (and apparently they are now obsolete?). So; what are the opinions of this list? (BEGIN FLAME...?) ..Brian -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
HP Colorado, ide-scsi
Hi all,
I'm getting this in my kern.log's:
---
Sep 6 00:45:01 valhalla kernel: st: Version 20020205, bufsize 32768, wrt 30720, max
init. bufs 4, s/g segs 16
Sep 6 00:45:01 valhalla kernel: Attached scsi tape st0 at scsi0, channel 0, id 0, lun 0
Sep 6 00:45:01 valhalla kernel: st0: Block limits 25976 - 6841632 bytes.
Sep 6 01:18:39 valhalla kernel: st0: Error with sense data: Info fld=0x10200,
Deferred st09:00: sense key Medium Error
Sep 6 01:18:39 valhalla kernel: Additional sense indicates Sequential positioning
error
Sep 6 01:30:01 valhalla kernel: st: Unloaded.
---
This was from an amdump, which failed after 64kb written.
A little bit later, running an amcheck:
---
Sep 6 09:54:45 valhalla kernel: st: Version 20020205, bufsize 32768, wrt 30720, max
init. bufs 4, s/g segs 16
Sep 6 09:54:45 valhalla kernel: Attached scsi tape st0 at scsi0, channel 0, id 0, lun 0
Sep 6 09:54:45 valhalla kernel: st0: Block limits 11268 - 112641 bytes.
Sep 6 10:09:45 valhalla kernel: scsi : aborting command due to timeout : pid 72600,
scsi0, channel 0, id 0, lun 0 Read (6) 01 00 00 40 00
Sep 6 10:09:45 valhalla kernel: hdd: irq timeout: status=0xc0 { Busy }
Sep 6 10:09:45 valhalla kernel: hdd: ATAPI reset complete
Sep 6 10:09:45 valhalla kernel: hdd: irq timeout: status=0x80 { Busy }
Sep 6 10:09:46 valhalla kernel: hdd: ATAPI reset complete
Sep 6 10:09:46 valhalla kernel: hdd: irq timeout: status=0x80 { Busy }
Sep 6 10:09:46 valhalla kernel: st0: Error 2707 (sugg. bt 0x20, driver bt 0x7,
host bt 0x7).
Sep 6 10:20:01 valhalla kernel: st: Unloaded.
---
Pulled the tape out, plugged it back in, and now its dumping fine. Can anyone make
sense of this?
BTW is there a way of getting amanda to put level 0's in degraded mode? I'd still
like full dumps when I have to manually run amdump.
Regards,
Brian Jonnes
--
Init Systems - Linux consulting
031 767-0139082 769-2320[EMAIL PROTECTED]
Re: Testing tapes
I think I'm getting closer to the problem. First off, it seems that ide-tape doesn't work properly with the Colorado drives. I haven't yet had time to test, but I'll install ide-scsi when I next get a chance. Does anyone know of a reference as to the differences between ide-tape/ide and st/ide-scsi/ide? Regards, Brian Jonnes -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
Re: Testing tapes
On Sun 01 Sep 02 20:51, Gene Heskett wrote: Thats just a wee bit more than my tapetype says it is here, I got 3780mb as the capacity. Odd. What version of amanda? There was a period of a couple of weeks where the internal rewind function was a bit foobar. The tape might not have been rewound, but then again, thats wrong cause it had to rewind it to verify it was the right tape, which it apparently did. Anyway, the current snapshot is 2.4.3b4-20020829 and all *known* bugs have been squished. Hrm. Running Debian Woody's version (2.4.2p2). Also, what scsi card? Adaptec 1542's are getting a bad rep in this group. They do not do tape happily. It be an IDE drive. I've been getting mine on ebay, and allthough the price has risen somewhat, you should be able to get a couple of 10 packs for $35-$40 a 10-pack. Plus the inevitable shipping of course. Dunno if the shipping is gonna kill it for me, being in SA ;) Regards, Brian Jonnes -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
Re: Testing tapes
On Sat 31 Aug 02 16:11, Gene Heskett wrote:
On Saturday 31 August 2002 07:45, Brian Jonnes wrote:
Hi,
I think I have a faulty tape or two. What is the best recommended
way of testing this? Generate a file from /dev/urandom, write it
to the tape and md5sum it?
Most drives do the equ of that themselves. its when they can't
recover the error that you become aware that its doing re-read
after re-read and reporting a failure.
Okay, here's the deal. I'll use my DAILY_04 tape as an example. Dump on 13/08:
---
These dumps were to tape DAILY_04.
The next tape Amanda expects to use is: DAILY_05.
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:01
Run Time (hrs:min) 2:46
Dump Time (hrs:min)1:46 1:20 0:25
Output Size (meg)3940.3 2940.1 1000.2
Original Size (meg) 6798.4 5010.1 1788.3
Avg Compressed Size (%)58.0 58.7 55.9 (level:#disks ...)
Filesystems Dumped 27 13 14 (1:8 2:4 3:2)
Avg Dump Rate (k/s) 637.2 626.3 671.6
---
As you can see, the tape was used to the full. Now, on 31/08 I had a
failure:
---
These dumps were to tape DAILY_04.
*** A TAPE ERROR OCCURRED: [[writing filemark: Input/output error]].
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: DAILY_05.
FAILURE AND STRANGE DUMP SUMMARY:
valhalla /export/mail/pmail.usr lev 0 FAILED [disk /export/mail/pmail.usr
offline on valhalla?]
valhalla /export/mail/subs lev 0 FAILED [out of tape]
---
Now from this I'd assume it was trying to write too much data. But looking at
the log files, it seems that it only wrote a couple of kb (unfortunately I
can't access the server right at the mo').
Where am I going wrong? Are the logs straightforward to interpret (i.e. I add
up the kb for the DUMPER lines up until the point of failure)? Can tapes be
intermittent?
failed, one of them ripping the tapes in two violently, in less
than a year. So generally speaking, TR4's aren't any more, or less
dependable than a DDS2, but the DDSx format is slowly pulling ahead
in my personal tally sheets. Plus the DDS2 tapes are beaucoup
cheaper...
I have to get a new (and bigger) drive in the near future, so I'll definitely
look into these.
Regards,
Brian Jonnes
--
Init Systems - Linux consulting
031 767-0139082 769-2320[EMAIL PROTECTED]
Testing tapes
Hi, I think I have a faulty tape or two. What is the best recommended way of testing this? Generate a file from /dev/urandom, write it to the tape and md5sum it? Also, what is the expected lifetime for Travan 4 tapes (each used once a week)? When should I retire them? ..Brian -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
Confused, irritated. Small dumpcycle+tapecycle.
Howdy, Have been running amanda for a while now, but I'm really battling to get it configured right. Almost every day now I have to manually run amflush because amanda is generating dumps that are too big. I have a very small (relatively speaking) tapecycle: 7 tapes. I understand that my dumpcycle should be such that I end up with two full dumps of each disk per tapecycle. But amanda plans according to days, not runs. Am I being unreasonable here. I have Travan 4/8 GB tapes and am backing up around 20GB of data, but each disk is less than 2GB compressed. Should I be splitting the config? Arrrgggh! Regards, Brian Jonnes -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
Re: Linux DUMP
dump reads on a lower level than tar, and is more sensitive when dumping an active file system. Dumps may be rendered useless due to a file changing underneath dump. If the system is placed in single user mode there should be no problem. If the file system is quiet, there should be close to no problems. The 'close' word makes most people switch to tar. This does not really make sense. Is dump not a standard utility? How do other Unices work? Dump can't be as simple as cat /dev/hdX... what do you mean by low-level? It must have its own file format, surely? Has anyone looked at the source-code, or should I do that to satisfy my curiosity? Rgds, Brian -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
