RE: Tape technology
I've just started using SDLT, and it's the best thing since sliced bread - fast - very fast, high capacity (110G native). Very nice. |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Brian Jonnes |Sent: Friday, 6 September 2002 18:43 |To: [EMAIL PROTECTED] |Subject: 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] | |
RE: statistics
|The 1.13-25 version is on alpha.gnu.org now for about a year, but |the tarballs of either will compile just fine on your machines as |long as the developer stuff is on them. | |FWIW, 1.13-19 is also reported to work well with amanda. I was |automaticly recommending the latest just because its the latest I |guess :-) | Yeah, I'm running 1.13-19 atm, and it's hassle free apart from the reiser partition new(er) toys == increased happiness :o)
RE: Any amanda gui tools?
can you do something like this with amrecover? I usually use that when I need to pull a file off a tape, but I don't know if it'll easily drop out a list of files for you to compare / diff / etc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Trevor Fraser |Sent: Thursday, 5 September 2002 21:45 |To: [EMAIL PROTECTED] |Subject: Any amanda gui tools? | | |Hello all. | |I was asked if there was a tool, not necessarily graphical, |but that will be |better, that can compare what is on a tape to the directory |the information |on the tape comes from and notify the user of any missing |files. Is there |anything like this around? | |The aim is to find an efficient way of seeing what file was |accidentally |deleted (don't know name/location), without going through a |pain staking |process of checking 20 GB of files against a tape. | | |Let me know. |Thanks, Trevor. | |= |Stussy said:Knowledge is King! |= | |
RE: statistics
yes - that's right. the slow part is your computer compressing the data. The
offline message is a yet to be crafted question for this list - amanda
isn't backing up the reiserfs partition on one of the machines. The drive is
a SDLT110, there are 3 servers, and a dedicated 40G holding disk. After
setting it up this way, the performance of amanda skyrocketed (by having a
dedicated holding disk, fast backup drive, one server getting multiple
clients to do client-side compression).
Cheers,
Chris
--
These dumps were to tape Loyalty003.
The next tape Amanda expects to use is: Loyalty004.
FAILURE AND STRANGE DUMP SUMMARY:
diablo /dev/hde1 lev 0 FAILED [disk /dev/hde1 offline on diablo?]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min) 0:04
Run Time (hrs:min) 6:51
Dump Time (hrs:min) 9:09 8:47 0:22
Output Size (meg) 19111.8 16576.7 2535.1
Original Size (meg) 35566.2 31388.3 4177.9
Avg Compressed Size (%) 53.7 52.8 60.7 (level:#disks ...)
Filesystems Dumped 12 11 1 (1:1)
Avg Dump Rate (k/s) 594.5 536.8 1994.5
Tape Time (hrs:min) 0:34 0:30 0:04
Tape Size (meg) 19112.2 16577.1 2535.2
Tape Used (%) 18.6 16.1 2.5 (level:#disks ...)
Filesystems Taped 12 11 1 (1:1)
Avg Tp Write Rate (k/s) 9584.5 9556.1 9775.1
NOTES:
planner: Adding new disk diablo:/dev/hde1.
planner: Full dump of gemini:/dev/sda5 promoted from 1 day ahead.
planner: Full dump of bob:/dev/sdc1 promoted from 1 day ahead.
planner: Full dump of bob:/dev/sda4 promoted from 1 day ahead.
planner: Full dump of gemini:/dev/sda6 promoted from 1 day ahead.
planner: Full dump of bob:/dev/sdb1 promoted from 1 day ahead.
planner: Full dump of bob:/dev/sda3 promoted from 1 day ahead.
planner: Full dump of gemini:/dev/sda3 promoted from 1 day ahead.
planner: Full dump of gemini:/dev/sda1 promoted from 1 day ahead.
planner: Full dump of bob:/dev/sda1 promoted from 1 day ahead.
planner: Full dump of diablo:/dev/hda3 promoted from 1 day ahead.
planner: Full dump of diablo:/dev/hda1 promoted from 1 day ahead.
taper: tape Loyalty003 kb 19570912 fm 12 [OK]
DUMP SUMMARY:
DUMPER STATS TAPER STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
-- -
bob /dev/sda1 0 1636282 490848 30.0 32:19 253.1 0:558997.6
bob /dev/sda3 0 132318 27328 20.7 2:36 175.3 0:0216471.5
bob /dev/sda4 0 1241536 786336 63.3 6:302016.4 1:219731.9
bob /dev/sdb1 0 1157677 577760 49.9 22:47 422.6 1:019507.0
bob /dev/sdc1 0 79762334850560 60.8 39:502029.8 8:139831.1
bob /dev/sdd1 1 42781942595968 60.7 21:421994.5 4:269775.0
diablo /dev/hda1 0 2113691 919424 43.5 30:23 504.4 1:438910.0
diablo /dev/hda3 0 30202 4672 15.5 0:17 269.1 0:014178.1
diablo /dev/hde1 0 FAILED ---
gemini /dev/sda1 0 1717516 557536 32.5 123:15 75.4 1:088226.4
gemini /dev/sda3 0 953407 280096 29.4 27:42 168.5 0:446435.9
gemini /dev/sda5 0 139187958458624 60.8 211:53 665.4 14:239803.3
gemini /dev/sda6 0 1263950 21376 1.7 29:29 12.1 0:073192.7
(brought to you by Amanda version 2.4.2p2)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of greg
Sent: Friday, 6 September 2002 08:30
To: [EMAIL PROTECTED]
Subject: statistics
Does this look right?
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:06
Run Time (hrs:min)11:48
Dump Time (hrs:min) 11:42 11:42 0:01
Output Size (meg) 24171.424171.40.0
Original Size (meg) 54320.454318.32.1
Avg Compressed Size (%)44.5 44.51.5 (level:#disks ...)
Filesystems Dumped3 2 1 (1:1)
Avg Dump Rate (k/s) 587.4 588.00.8
Tape Time (hrs:min) 11:41 11:41 0:00
Tape Size (meg) 24171.524171.50.1
Tape Used (%) 64.5 64.50.0 (level:#disks ...)
Filesystems Taped 3 2 1 (1:1)
Avg Tp Write Rate (k/s) 588.5 588.5 29.3
It is saying it took 11 hrs to dump 54GB or 24GB compressed. I have a
quantum DLT8000-40 which is rated
at 6MB/s or 12MB/s compressed. 11hrs seems a long time even considering
gzip as the software compression.
Is there something I am missing here?
-greg
RE: statistics
Thanks Gene! Hopefully you've answered my question without me needed to ask it :o) I'm assuming I need to upgrade tar on the client machine, not the amanda server...? Are there any source tarballs of tar floating around? The tar located: ftp://ftp.gnu.org/gnu/tar/ is 1.13.19 which comes with RH7.1... there's an rpm for 1.13.25 but i'll need to upgrade some libs error: failed dependencies: libc.so.6(GLIBC_2.2.3) is needed by tar-1.13.25-4 which I'm not keen to do unless I really have to. Cheers, Chris |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Gene Heskett |Sent: Thursday, 5 September 2002 12:26 |To: Chris Herrmann; 'greg'; [EMAIL PROTECTED] |Subject: Re: statistics | | |On Wednesday 04 September 2002 18:53, Chris Herrmann wrote: |yes - that's right. the slow part is your computer compressing the | data. The offline message is a yet to be crafted question for | this list - amanda isn't backing up the reiserfs partition on one | of the machines. The drive is a SDLT110, there are 3 servers, and | a dedicated 40G holding disk. After setting it up this way, the | performance of amanda skyrocketed (by having a dedicated holding | disk, fast backup drive, one server getting multiple clients to | do client-side compression). | |Re reiserfs. If you are using dump, it knows nothing about |reiserfs. But late (1.13-25) versions of tar should be just fine. | |[...] | |-- |Cheers, Gene |AMD K6-III@500mhz 320M |Athlon1600XP@1400mhz 512M |99.13% setiathome rank, not too shabby for a WV hillbilly |
RE: Travan TR5 drives...
umm... solved months ago! i posted a reply to the list then with the solution. Thanks for replying though Phil :o) Cheers, Chris |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Phil Cooper |Sent: Friday, 1 February 2002 21:19 |To: Chris Herrmann; [EMAIL PROTECTED] |Subject: RE: Travan TR5 drives... | | |Chris | |I had the exact same problem a few months back. The solution |is to enable |IDE-SCSI support (I used loadable modules on RH7.1). You can |then access |the device with nst0, instead on nht0. It will then work like a champ. | |I mentioned this on the list at the time if you want to check |the archives. | |Hope this helps | |Phil | |PS If you can work out how to load the required modules on |system startup, |please let me know | | |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Chris Herrmann |Sent: 01 February 2002 01:19 |To: [EMAIL PROTECTED] |Subject: Travan TR5 drives... | | |Hi all, | |I've just installed amanda on a linux 2.4.17 box, compiled |with IDE tape |drive support... everything seemed happy, until I tried |labelling my first |tape. | |The box is a dell poweredge 500SC. | |tape devices are /dev/ht0 /dev/nht0 | |The tape device is identified correctly as a Seagate TR5... |has a TR5 tape |in it. | |When labelling, it checks the label ok, rewinds, writes a new |label ok, then |rewinds again to see if the write it just did is still ok, and |here it hung |(hard-hang i.e. pull out the powercord). | |I used the tapetype listed on amanda.org: | |define tapetype tr5 | |comment TR-5 Seagate STT22N-RFT |length 9598 mbytes |filemark 15 kbytes |speed 720 kps |} | |Has anyone had any grief with this? Anyone gotten them to work? | |Thanks, | |Chris Herrmann |Far Edge Technology | |p. 02 99553640 |f. 02 99547994 |m. 0403 393309 |http://www.faredge.com.au |
Travan TR5, 500SC, Linux 7.1 amanda...
Yay!!! I'm reading and writing!!! Many thanks to (in no particular order): Seth Mos, Robert Wideman, Matt Domsch and Ashley from the amanda lists... I got it working by using ide-scsi, and the following lilo.conf entry: append=/dev/ht0=ide-scsi and... Then put this in /etc/rc.d/rc.local: rmmod ide-tape modprobe ide-scsi hdparm -d0 /dev/hdd mt -f /dev/st0 stoptions no-blklimits Ok... Now the reason I was having trouble getting it to automagically detect the ide-cum-scsi drive was because the ide-tape stuff was compiled into the kernel, rather than being a module. this meant that it couldn't rmmod ide-tape :o( . recompiled the kernel with ide-tape as a module, and it's all happy now. Cheers! Chris Herrmann Far Edge Technology p. 02 99553640 f. 02 99547994 m. 0403 393309 http://www.faredge.com.au
oops
and phil cooper! sorry! Chris Herrmann Far Edge Technology p. 02 99553640 f. 02 99547994 m. 0403 393309 http://www.faredge.com.au
Travan TR5 drives...
Hi all, I've just installed amanda on a linux 2.4.17 box, compiled with IDE tape drive support... everything seemed happy, until I tried labelling my first tape. The box is a dell poweredge 500SC. tape devices are /dev/ht0 /dev/nht0 The tape device is identified correctly as a Seagate TR5... has a TR5 tape in it. When labelling, it checks the label ok, rewinds, writes a new label ok, then rewinds again to see if the write it just did is still ok, and here it hung (hard-hang i.e. pull out the powercord). I used the tapetype listed on amanda.org: define tapetype tr5 comment TR-5 Seagate STT22N-RFT length 9598 mbytes filemark 15 kbytes speed 720 kps } Has anyone had any grief with this? Anyone gotten them to work? Thanks, Chris Herrmann Far Edge Technology p. 02 99553640 f. 02 99547994 m. 0403 393309 http://www.faredge.com.au
more info...
Just changed the tape type slighty because it's the atapi version... Slightly different (maybe) for the ATAPI version: define tapetype STT2A comment just produced by tapetype program length 9500 mbytes filemark 103 kbytes speed 914 kbytes } dmesg gives me a whole lot of information about the tape (from ide-tape) - what modes it supports, speed, buffers etc etc. Chris Herrmann Far Edge Technology p. 02 99553640 f. 02 99547994 m. 0403 393309 http://www.faredge.com.au
HP Ultriux
Hi, has anyone had any experience using amanda with the HP Ultrium drives, particularly with the 9 tape autoloaders and 6drive/60 tape arrays? Thanks, Chris Herrmann Far Edge Technology p. 02 99553640 f. 02 99547994 m. 0403 393309 http://www.faredge.com.au
FW: Chris, some time ago we requested changes/corrections to two of our screens in the flash display you
Hi Aman - some ads for you to change -Original Message- From: John Baird [mailto:[EMAIL PROTECTED]] Sent: Thursday, 28 June 2001 15:53 To: Stephen Brown; [EMAIL PROTECTED] Subject: Chris, some time ago we requested changes/corrections to two of our screens in the flash display you Chris, some time ago we requested changes/corrections to two of our screens in the flash display you organise here at RNS. The fund-raising ad has a spelling mistake. it should read gratefully received Also the breast screen one should read they're all over 50 could you fix these please and advise when done, thanks john John Baird Instructional Designer Multi-media Producer Head, Medical Illustrations RNS Hospital, St Leonards NSW 2065 Australia vox +61(0)2 9926 7723 fax +61(0)2 9926 6035 [EMAIL PROTECTED] * This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of NSW Health. *
secure backups
Hi all, Just wondering if anyone out there is doing secure backups - ie. encrypting the contents of the backup so that what is on the tape is an encrypted tar or tar.gz file rather than amanda's standard tape write... Can I plug in in rsa keys, public keys? Responses to me, and I'll summarise what I find out back to the list. Cheers, Chris Herrmann Far Edge Technology p. 02 99553640 f. 02 99547994 m. 0403 393309 http://www.faredge.com.au
oh oh...
Hi, Amanda started returning these results a couple of days ago... FAILED AND STRANGE DUMP DETAILS: /-- gemini sda5 lev 0 FAILED [/sbin/dump returned 3] sendbackup: start [gemini:sda5 level 0] sendbackup: info BACKUP=/sbin/dump sendbackup: info RECOVER_CMD=/bin/gzip -dc |/sbin/restore -f... - sendbackup: info COMPRESS_SUFFIX=.gz sendbackup: info end | DUMP: Date of this level 0 dump: Thu May 17 03:01:30 2001 | DUMP: Date of last level 0 dump: the epoch | DUMP: Dumping /dev/sda5 (/home) to standard output | DUMP: Label: none | DUMP: mapping (Pass I) [regular files] | DUMP: mapping (Pass II) [directories] | DUMP: estimated 3210845 tape blocks. | DUMP: Volume 1 started at: Thu May 17 03:01:45 2001 | DUMP: dumping (Pass III) [directories] | DUMP: dumping (Pass IV) [regular files] | DUMP: 4.66% done, finished in 1:42 | DUMP: 12.08% done, finished in 1:12 | DUMP: 20.04% done, finished in 0:59 ? DUMP: bread: lseek fails ... So I took the server down to runlevel 1, e2fsck'd the drive checking for physical bad blocks as well as damaged inodes etc. It said that it found a problem with 1 file, which it repaired. Brought it back up, and the next night had the same problem. Thought it might have been related to 1 very large, recently saved file (1.3G), but made it much smaller (400M) and it's still happening. Anything I can check for? Is there anyway I can identify where on the disk it's failing, and try removing that file? Thanks, Chris Herrmann Far Edge Technology p. 02 99553640 f. 02 99547994 m. 0403 393309 http://www.faredge.com.au
troy o brien
I've just checked troy obrien, and today he's played 25 times already, since 9am he's played 5 times, which means that he's playing almost 3 times an hour. I'm about to change him to high priority... done. Cheers, Chris Herrmann Far Edge Technology p. 02 99553640 f. 02 99547994 m. 0403 393309 http://www.faredge.com.au
amrecover, solved...
Hi all, Thanks to John for his assistance. Ended up getting it to work because I'd made a mess of the xinet.d configuration - the index service was pointing at something that existed, but was of no assistance (not going to pretend to know what the file in question did). Fixed that, and then had some grief with it not letting me run amrecover as root - telling me that root couldn't run it as backupuser@host . Did the dodgy, and did: chown root.backupuser amrecover chmod ug+x amrecover chmod u+s amrecover which set the owner of the file to root, and the backupuser's group. I then gave root the backup user permission to execute the file, and set the setuid bit, which means (i think) that if a user in the backupser group executes the file they will execute it as if they were root. And this works, and i'm a much happier admin :o) Cheers, Chris Herrmann Far Edge Technology p. 02 99553640 f. 02 99547994 m. 0403 393309 http://www.faredge.com.au
amrecover
Hi, I'm having some amrecover grief. When I run it, it returns: root@gene amanda]# amrecover -C CORBETT -s gene -t gene -d /dev/nst0 AMRECOVER Version 2.4.1p1. Contacting server on gene ... amrecover: Unexpected server end of file If I leave out various bits of information (tape host, index server etc) it returns the same message. amrecover.debug looks like: [root@gene amanda]# cat amrecover.debug amrecover: debug 1 pid 8510 ruid 0 euid 0 start time Tue May 8 15:51:41 2001 [root@gene amanda]# If I browse the directories where the index is it all looks alright - I can see the config/index/hostname/devicename directories... what is amrecover looking for? The hostname matches in all cases... Thanks, Chris Herrmann Far Edge Technology p. 02 99553640 f. 02 99547994 m. 0403 393309 http://www.faredge.com.au
RE: progress... slowly
John - you're a genius :o)
*** A TAPE ERROR OCCURRED: [cannot overwrite active tape CORBETT006].
*** PERFORMED ALL DUMPS TO HOLDING DISK.
THESE DUMPS WERE TO DISK. Flush them onto a new tape.
Tonight's dumps should go onto 1 tape: a new tape.
FAILURE AND STRANGE DUMP SUMMARY:
gene /dev/sda2 lev 1 FAILED [can't dump no-hold disk in degraded
mode]
STATISTICS:
Total Full Daily
Dump Time (hrs:min)0:01 0:00 0:00 (0:01 start)
Output Size (meg) 52.80.0 52.8
Original Size (meg)98.20.0 98.2
Avg Compressed Size (%)53.8--53.8
Tape Used (%) 0.30.00.3 (level:#disks ...)
Filesystems Dumped2 0 2 (1:2)
Avg Dump Rate (k/s) 348.8-- 348.8
Avg Tp Write Rate (k/s) -- -- --
NOTES:
planner: Full dump of gene:/dev/sda2 promoted from 2 days ahead.
DUMP SUMMARY:
DUMPER STATS TAPER
STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS
KB/s
-- -- --
gene /dev/sda2 1
FAILED
gene /dev/sda5 12576718784 72.90:22 864.9N/A
N/A
gene /dev/sda6 17481835328 47.22:13 264.7N/A
N/A
This means that it worked exactly as I expected it to.
One other quick question for you - are any of these fixes etc added to the
FAQ? Not that I can really talk, I suppose... if those of us who are lucky
enough to have a problem solved all posted it in a digestable format on the
FAQ-O-MATIC then I'm sure the volume of enquires would drop.
Thanks :o)
Chris
-Original Message-
From: John R. Jackson [mailto:[EMAIL PROTECTED]]
Sent: Sunday, 4 February 2001 02:12
To: Chris Herrmann
Cc: Amanda Users (E-mail)
Subject: Re: progress... slowly
Well I'm not getting the tapelist error any more, after fixing owners of
files, setuid bits etc, but now get this after amdump finishes running...
...
driver: FATAL infofile update failed (gene,/dev/sda5)
This says one of the Amanda database files (or a directory down to
it) is locked up, i.e. wrong ownership. Look for a directory named
"curinfo" in your amanda.conf directory (or whatever you set "infofile"
to in amanda.conf). That, and everything under it, must be owned by
the Amanda user and writable.
taper: FATAL syncpipe_get: w: unexpected EOF
I think this is fixed in 2.4.2.
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
RE: driver: dumper0 died while dumping
just a thought, that may not be the answer... try setting your chunksize to something like 1Gb (or 200M, if that works for you). This means that if it's backing up 2.5G, no individual file in the holding disk area will be bigger than that chunksize. We needed it because our backup was trying to write chunks 3 or 4G big, and failing. e2fs can't currently hold bigger than a 2G file, can't provide any advice on other filesystems, however. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robinson David F Dr DLVA Sent: Thursday, 1 February 2001 08:07 To: '[EMAIL PROTECTED]' Subject: RE: driver: dumper0 died while dumping This problem goes away if I specify a much lower value for the 'use' parameter on the holdingdisk. The original value specified was 30Gb. This would be more than enough space for the backup (approximately 2.5Gb). If I switch this value to 200Mb the backup works. If I use amstatus to watch the dump as it proceeds, it appears that the entire dump is being written to the holding disk. The dump is apparently dying when trying to move the file to the tape. Any suggestions as to why this behaves this way? David
RE: tapelists permissions being changed...
Ok... Not using amadmin or amlabel... yep - I meant the setuid bit :o) (told you the dumb stick had already been through) amdump.1 looks like: -rw---1 operator root 8131 Feb 1 02:49 amdump.1 operator is the amanda user taper looks like: -rwxr-x---1 root disk32767 Aug 21 10:34 taper amdump: -rwxr-x---1 root disk 3277 Aug 21 10:34 amdump Digging through a working config we run here, and looking at the one in question, I think it's a mix of screwy setuid bits, wrong user ownership of files. So operator.disk now owns all of the files except for the ones that are setuid root. Will see how it goes tonight... Thanks, Chris
RE: DDS4 parameters
We use:
define tapetype HP-DAT40{
comment "Produced by Tape Type Program"
length 16613mbytes
filemark 452kbytes
speed 2612kbytes
}
For a Sony Python
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jason Winchell
Sent: Sunday, 28 January 2001 13:07
To: [EMAIL PROTECTED]
Subject: DDS4 parameters
Does anyone know the parameters for DDS4, 150m, 20GB/40GB tapes?
---
Jason Winchell
RE: operator access not allowed
I thought that the programs were supposed to be user root, group disk or operator, and that **some** of the programs were setuid root: (courtesy John) FYI, here's the proper list of setuid programs: -rwsr-x--- 1 root backup244716 Dec 1 14:19 libexec/calcsize -rwsr-x--- 1 root backup804540 Dec 1 14:23 libexec/dumper -rwsr-x--- 1 root backup233312 Dec 1 14:19 libexec/killpgrp -rwsr-x--- 1 root backup945028 Dec 1 14:23 libexec/planner -rwsr-x--- 1 root backup231016 Dec 1 14:19 libexec/rundump -rwsr-x--- 1 root backup231852 Dec 1 14:19 libexec/runtar -rwsr-x--- 1 root backup953900 Dec 1 14:23 sbin/amcheck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mitch Collinsworth Sent: Tuesday, 23 January 2001 13:03 To: Efrem Edwards Cc: [EMAIL PROTECTED] Subject: Re: operator access not allowed On Mon, 22 Jan 2001, Efrem Edwards wrote: FAILURE AND STRANGE DUMP SUMMARY: mail /home/httpd/html/users lev 0 FAILED [mail: [access as operator not allowed from [EMAIL PROTECTED]] Can someone help me with this. To start with, have you followed the suggestions in docs/FAQ ? -Mitch
RE: Questions and Answers and Thanks
I've found that when gzip is running on my own, and clients systems it's usually using 95+% of one cpu, which isn't a problem for us or them because the machines either have a spare cpu, or aren't doing anything at the time. more of a problem for bigger sites where your server will always be busy... The dumper itself usually takes very little cpu time. --- I still noticed that the dumper process is the bottleneck, but dumper now gets a performance of about 3 - 4 Kbps (iso sometimes down to 250bps). Are you sure it's dumper? Or is that just the symptom? For instance, it could be the dump program on the client, disks on the client, SCSI termination (or lack there of), bad cables, bad controller, your network connection, other workload on the system at the same time, disk/controller/bus contention between the backed up disk and holding disk, ditto for the tape drive if the image goes direct to tape, etc. Gerhard den Hollander John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Smbclient amanda
Hi all,
having some grief getting amanda to backup an NT box (smb share).
NT 4.0 sp6a
share is "backup"
backup user owns the share, the directory, and all files within it
amandapass is setup as follows:
//bursar-new/backup$ somepassword BURSAR-NEW
BURSAR-NEW is the workgroup of the machine being backed up ie. it's not a
user in the main domain.
There's a line in disklist:
svr-new //bursar-new/backup$ comp-smb
and comp-smb is defined as:
define dumptype comp-smb {
global
comment "backing up smb partitions with compression"
compress server best
program "GNUTAR"
priority low
}
If I run amcheck I get:
Amanda Tape Server Host Check
-
/data/amanda: 5651920 KB disk space available, using 5549520 KB.
ERROR: cannot overwrite active tape NEWC0015.
(expecting tape NEWC0005 or a new tape)
NOTE: skipping tape-writable test.
Server check took 32.177 seconds.
Amanda Backup Client Hosts Check
Client check: 1 host checked in 0.569 seconds, 0 problems found.
(brought to you by Amanda 2.4.1p1)
***
(done before my tapechange, obviously).
Amandad.debug contains:
Amanda 2.4 REP HANDLE 000-883B0508 SEQ 979854423
OPTIONS ;
running /usr/bin/smbclient bursar-new\\backup$ -E -U backup -W
BURSAR-NEW -c quit
OK //bursar-new/backup$
*
and here looks to be a culprit... the share contains only 1 large file (3.5G
or so), and smbclient doesn't appear to understand how to read a file that
big.
calculating for amname '//bursar-new/backup$', dirname
'//bursar-new/backup$'
sendsize: getting size via smbclient for //bursar-new/backup$ level 0
sendsize: running "/usr/bin/smbclient '\\bursar-new\backup$' X -d 3 -U
backup -E -W BURSAR-NEW -c 'archive 0;recurse;dir'
"
added interface ip=127.0.0.1 bcast=127.255.255.255 nmask=255.0.0.0
added interface ip=xxx.xxx.xxx.xxx bcast=xxx.xxx.xxx.xxx nmask=255.255.255.0
Client started (version 2.0.7).
resolve_lmhosts: Attempting lmhosts lookup for name bursar-new0x20
resolve_wins: Attempting wins lookup for name bursar-new0x20
bind succeeded on port 0
Got a positive name query response from xxx.xxx.xxx.xxx ( xxx.xxx.xxx.xxx )
Connecting to xxx.xxx.xxx.xxx at port 139
Domain=[NEWADMIN] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0]
directory recursion is now on
received 3 entries (eos=1)
. DA0 Thu Jan 18 23:23:25 2001
.. DA0 Thu Jan 18 23:23:25 2001
daily A -192142336 Thu Jan 18 22:54:55 2001
49669 blocks of size 262144. 29096 blocks available
Total bytes listed: -192142336
.
(no size line match in above smbclient output)
*
is this what's causing the problem? If so, how do I get around it?
Cheers,
Chris
PS. Backups work fine aside from this one partition.
RE: Diagnosing client-side errors
i thought you needed to use /dev/sdan where n is the number of the partition -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, 16 January 2001 19:30 To: [EMAIL PROTECTED] Subject: Re: Diagnosing client-side errors Ben Elliston hath declared on Tuesday the 16 day of January 2001 :-: I am trying to back up a single partition having just installed Amanda. I thought I'd try with this in my `disklist': scooby sda8 always-full I get the following error, but can't work out what I'm doing wrong. Any tips? In general, how can I diagnose client-side problems? Does that device actually exist ? Does the amanda user on the client have permission to access it ? Actually, I've just realized that even though the examples for disklist show using the device, I have been using the filesystem mount point, i.e. dalom /usr comp-high Does this make much difference ? -- Robert "bobb" Crosbie. System Administrator, Internet Ireland.
hmm. What's wrong with this picture?
STATISTICS:
Total Full Daily
Dump Time (hrs:min)0:48 0:48 0:00 (0:00 start, 0:00
idle)
Output Size (meg) 927.1 927.10.0
Original Size (meg) 0.00.00.0
Avg Compressed Size (%) -- -- --
Tape Used (%) 5.65.60.0
Filesystems Dumped3 3 0
Avg Dump Rate (k/s) 331.2 331.2--
Avg Tp Write Rate (k/s) 331.1 331.1--
---
Who says you can't create value from nothing huh?
:o)
RE: /dev/rd/c0d0* on linux
I'm using a mega-raid controller as well - you shouldn't be using linux to raid it - use the bios setup to define raidxx for the disks. The configured drive(s) should then be referred to as sda1,2 etc. For example, we configured our 3 disks as 1 raid 0 drive, which means that our disk list looks like: gemini sda1 comp-root -1 local # / gemini sda3 comp-user -1 local # /var gemini sda5 comp-high -1 local # /home gemini sda6 comp-high -1 local # /public gemini sda7 holding-disk-1 local # /data holding disk Good luck, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mike Cathey Sent: Friday, 12 January 2001 05:08 Cc: [EMAIL PROTECTED] Subject: /dev/rd/c0d0* on linux Hi all, I'm setting up amanda-2.4.2 CVS on a linux box with a MegaRAID controller. The raid partitions are /dev/rd/c0d0p* and amanda didn't like that. I manually modified config.h on this client due to time constraints, but I would expect that a cleaner method of finding such devices could be arranged in the configure script... Cheers, Mike Cathey
RE: Disaster Recovery Recipe
You should be able to read it off by catting /dev/st0 or similar; One question I'd like to add is, is it possible to store the updated indexes on the tape - I ask because in case of disaster, you'd ideally want to be able to know that you need tapes 5,6,7 and no others to bring your system back to it's last backed up state. I haven't looked really hard (and so may be totally in error), but I think that the indexes are stored underneath each configuration, and only updated after a backup (which is fair enough). Can these indexes be written to tape as well, meaning that from the last backup tape, it should be possible to get amanda to tell you which tapes you exactly which tapes you need? Cheers, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bradley Glonka Sent: Thursday, 11 January 2001 00:12 To: [EMAIL PROTECTED] Subject: Disaster Recovery Recipe Hi There, I'm trying to put together a procedure to recover data if the amanda server goes down. Is there a recipe for doing this? I'm mainly interested in reading amanda tapes without amanda. Thanks Brad
