Re: Problem backing up
160 Mb, not that much huh, and it gives me the answer in just 1.5 second or so.. And I'm not quite sure that the duration of 1.5 second is okay... Is the command used to make an inventory of the data to backup? GNU tar is very clever about noticing it is writing to /dev/null and essentially does nothing. Try the command again but pipe the output like this: gtar ... --file - | cat /dev/null Would it help if I should exclude these files? You mean the sockets? You don't need to. The latest version of Amanda ignores those messages. Or can I only exclude directories? Is there an example exclude.gtar file? I've been unlucky in finding one up to now. Exclude lists are a black art. One of the Amanda users is writing a document on how to do them, but it's not ready yet. There are some examples in the chapter: http://www.backupcentral.com/amanda.html You might also look at: ftp://gandalf.cc.purdue.edu/pub/amanda/gtartest-exclude I don't know if I can simulate a backup without using the backup tapes (thus not increasing the tapenumber and amount of backups made). If I know that, it would help me, so I can simulate and test... Only one Amanda thing can go on at a time. That's why you could not run amcheck while amdump was running. When nothing is running, you can test by creating a configuration just like the one you have and making a few changes: * Set tapedev to /dev/null and comment out any tape changer entries. This will throw the images away. * Set the record dumptype option to no so your tests do not affect the sequence of real backups. Make sure you keep the log files (logfile), database area (infofile), index files (indexdir) and tapelist (same directory as amanda.conf or tapelist in amanda.conf) separate between the two configurations. Thanks again for additional help. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amrecover and index record
sethost localhost First recommendation is to *not* use localhost (in your disklist). There are some issues, such as what happens if you decide to switch to a different tape server. Using the fully qualified host name for all machines, including the tape server, will be better in the long run (IMO). No index records for disk for specified date If date correct, notify system administrator So, did you contact the system administrator? :-) That's a joke. I can't believe we have a message like that in Amanda. Every time I see something like that from a vendor, I start screaming I **am** the administrator, you miserable piece of software, and I don't have a clue what you're whining about!. :-) Anyway, back to your problem ... What date did amrecover say it used? Looking in your index directory, you should have a directory named localhost and another named _etc. Look in there for the gzip'd index files (in particular, for the datestamp amrecover mentioned). Are there any? Are they owned by the Amanda user (the one you configured amindexd to run as in inetd.conf)? Are they non-zero length? Do they seem to have good data in them (should be paths and file names)? On the tape server, what's in /tmp/amanda/amindexd*debug? What happens if you run amadamin gilsdorf find localhost /etc? Frank John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amanda failure following upgrade
Upgraded Amanda yesterday from 2.4.1p1 to 2.4.2p2 ... amcheck runs successfully. Any idea why there is a failure in the amdump ? ... bali /usr5 lev 0 FAILED [bali: [hostnames do not match: bali bali.wads worth.org] I'm surprised amcheck didn't fail. This message comes from amandad which they both use. Here's what happened: * amandad took the IP address of the machine connecting to it and converted that to a host name with gethostbyaddr. It got back bali. * It took that name and did a host name lookout with gethostbyname. It got back bali.wadsworth.org. Looks like you have a host name lookup problem. There are a couple of trivial test programs at: ftp://gandalf.cc.purdue.edu/pub/amanda/gethostbyaddr.c ftp://gandalf.cc.purdue.edu/pub/amanda/gethostbyname.c They use the exact same call Amanda uses. You cannot trust grepping through /etc/hosts or running nslookup. Those depend on how your system is configured to do lookups. sicily /usr1 lev 0 FAILED [disk /usr1 offline on sicily?] sicily /dev/root lev 0 FAILED [disk /dev/root offline on sicily?] sylt /usr7 lev 0 FAILED [disk /usr7 offline on sylt?] sylt /usr4 lev 0 FAILED [disk /usr4 offline on sylt?] sylt /dev/root lev 0 FAILED [disk /dev/root offline on sylt?] If amcheck did not complain about these, the next thing to look at is the /tmp/amanda/sendsize*debug file. In particular, look at the first and last lines and see how long the estimates took. You may need to crank up etimeout in amanda.conf. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amanda failure following upgrade
John, For reasons that I don't understand, predating my time at this site, the Sun systems use bin for amanda user and the SGI systems use root for amanda user. Rather than allow enhanced root access via NFS I selected an equally questionable solution, chmod o+x on the executable. # df worked, initially # file failed but now works. Oddly enough I didn't see any errors when trying to (manually) execute the program from the client (with no parameters, not quite certain of the behaviour but thought I'd see some type of access failure). [sylt] /usr/local/libexec 3 file rundump rundump: Cannot read rundump: Permission denied Its be great is either amcheck or some other post installation utility actually ran all these checks prior to a full-live run. Don't mean to be critical, don't know how we'd function without Amanda, its a wonderful tool, just that there are so many possible ways a distributed program like this can fail that cataloging and testing for these things would be a very valuable addition. I think we probably have it licked now, will flag you tomorrow if I run into something else I don't understand. thanks very much, Brian As far as the other two clients sendsize.20010628122106.debug shows (the errors are the same on both clients). ... cannot execute /usr/local/libexec/killpgrp: Exec format error cannot execute /usr/local/libexec/killpgrp: Exec format error sendsize: exec /usr/local/libexec/rundump failed or no dump program available: Exec format error ... I wouldn't be too bothered by a failure to execute because of root-nfs access restrictions but I'd thought that Exec format errors where do to architecture issues. Both of those programs are setuid root. If you're delivering them to the client via NFS, you may need to change your mount options (or the export options, I always forget which side controls it) to allow setuid. Irix may translate that problem into exec format error. If that doesn't help, try logging on to the client and run: df /usr/local/libexec/rundump file /usr/local/libexec/rundump (run them as the Amanda user). The first will confirm the file is coming from where you think it should. The second should tell you about the architecture it was built for. Brian John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: dds3 or dds4?
On Thu, Jun 28, 2001 at 08:55:04AM +0200, Christoph Sold wrote: Tom Strickland schrieb: On Wed, Jun 27, 2001 at 06:28:24PM +0200, Christoph Sold wrote: Tom Strickland schrieb: On Wed, Jun 27, 2001 at 03:58:28PM +0200, Christoph Sold wrote: Tom Strickland schrieb: We're on the verge of ordering a DDS drive (this week). It'll probablybe an HP Surestore - but the question is DDS3 or DDS4? There's theobvious difference in capacity, but beyond that are there any other differences? Speed is an obvious one - any others? After some near disasters with DDS tapes, I suggest also considering DLT1 tapes. Those never failed, even after long storage periods. They come even pretty cheap. If only! If I was admin for a commercial enterprise, I'd go with DLT or similar - but as a charity branch we just can't afford it. Huh? This single DLT1 drive has cost less than 4000 Marks -- thats less than $2000. Speaking of cheap, I again suggest looking at DLT1 drives. Designed to compete with DDS drives. I've just done some sums: total for HP SureStore DDS3i, SCSI card, 20 tapes, delivery, VAT: 998.52UKP total for HP SureStore DDS4i etc: 1408.71 UKP total for HP DLT1, SCSI card, 20 tapes, delivery, VAT: 2441.415 Well, unless I'm being wildly ripped off somewhere, it looks as though DDS is the only affordable solution. Probably DDS3, I'm afraid. I may be able to work something out, but at the moment I don't have the funds to be able to chip in myself. Did you cinsider DLT1 holds 40G uncompressed, compared to 4G for DDS4? You probably don't need 20 tapes. I can do with 10: 6 daily tapes, backed up monday through friday, 4 weekly tapes. Should cut the cost in half. Oops - my mistake. I meant 10 tapes. Anyway, the order's been made: DDS4. The only way that we could afford that was if I waived my costs. I am low on cash at the moment (next job starts in 1 month), so it wasn't easy. I would have gone with DLT if possible. Thanks to all for the advice - very helpful and patient. Tom
Re: Excluding hosts from amcheck?
[EMAIL PROTECTED] (Knut A. Syed) writes: Is it possible to exclude some of the hosts listed in disklist from amcheck? I have some laptops which I do not want to be warned about if they are not connected during amcheck. Knut, Unless you patch amcheck for a regexp parameter (or similar), I can offer two nasty work arounds: 1) Cron job for amcheck: amcheck ... (no -m or -M)|grep -v ...|mail 2) Put the laptops into a different configuration. The developers should be able to tell you how to put two configs on one tape. If not I'd use a non existent tape device (not /dev/null!) and have the desktop configuration back up that holding disk for the laptops. Using two configurations gives you an even tape usage for the desktop machines, because missing laptops don't induce spikes into the total backup size. (And you can run the laptop config at a different time, e. g. during lunch time). HTH, Johannes Nieß
Re: Off-site backup by extra tapes
My plan is to get a second rack of tapes, and set tapecycle to 20. Then every time Amanda gets through the current rack, I'll swap it with the other one and take it off site. If I forget or am unable to get the off-site rack on time, the worst that happens is a backup or two sit on the holding disk and can be flushed when I'm able to swap racks. ... Am I wrong in any of my assumptions, or missing something? Sounds like this would work for your environment. You might look a few days back in the archive for Subject 2 sets of tape. I posted another (untested) idea that might apply, at least in part. Christopher Masto John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Problems backing up
amstatus gives me this interesting news: amstatus report --- Using /usr/local/etc/amanda/hosting2/amdump from Fri Jun 29 12:24:55 MET DST 2001 cobalt01.somewhere.nl:/etc 0 2624k finished (12:25:18)cobalt01.somewhere.nl:/home 0 162630k dumping 43744k ( 26.90%) (12:26:41)cobalt01.somewhere.nl:/var 0 16192k finished (12:26:41) SUMMARY part real estimated size sizepartition : 3estimated : 3 181400kfailed : 0 0k ( 0.00%)wait for dumping: 0 0k ( 0.00%)dumping to tape : 0 0k ( 0.00%)dumping : 1 43744k 162630k ( 26.90%) ( 24.11%)dumped : 2 18816k 18770k (100.25%) ( 10.37%)wait for writing: 0 0k 0k ( 0.00%) ( 0.00%)writing to tape : 0 0k 0k ( 0.00%) ( 0.00%)failed to tape : 0 0k 0k ( 0.00%) ( 0.00%)taped : 2 18816k 18770k (100.25%) ( 10.37%)3 dumpers idle : not-idletaper idlenetwork free kps: 5165holding space : 134240k ( 45.20%)dumper0 busy : 0:01:42 ( 99.79%) taper busy : 0:00:00 ( 0.13%)0 dumpers busy : 0:00:00 ( 0.00%)1 dumper busy : 0:01:42 (100.00%) no-bandwidth: 0:01:12 ( 70.44%) start-wait: 0:00:30 ( 29.39%) /amstatus report --- This means that the backup has been started but hangs during the process... a time out of 1 hour doesn't help very much.. On the Cobalt machine I ran TOP, with the following processes at the very bottom of the list, while on top until it hung! top report --- 14308 amanda 0 0 740 740 676 S 0 0.0 0.1 0:00 sendbackup14309 amanda 0 0 728 728 668 S 0 0.0 0.1 0:02 sendbackup14310 root 0 0 812 812 520 S 0 0.0 0.1 0:03 gtar14311 amanda 0 0 0 0 0 Z 0 0.0 0.0 0:00 sh defunct /top report --- Does this help any further? or is there any way in which I can see at which particular file it hangs itself? Thanks again..
Re: Too many filesystems to AMANDA?
John R. Jackson wrote: amandad.20010626104712.debug ... GNUTAR //x.x.es/Cinetsrv 0 1970:1:1:0:0:0 1 [several more] [...] It's those last few lines before the that are important. Could you post a sample of them? Also if you copy all the GNUTAR lines from the packet to another file, how big is it? GNUTAR //.yy.zz/Cinetsrv 0 1970:1:1:0:0:0 1 GNUTAR //o.yy.zz/Dinetsrv 0 1970:1:1:0:0:0 1 GNUTAR //o.yy.zz/Cinetsrv 0 1970:1:1:0:0:0 1 GNUTAR //.yy.zz/Dinetsrv 0 1970:1:1:0:0:0 1 GNUTAR //.yy.zz/Cinetsrv 0 1970:1:1:0:0:0 1 GNUTAR //fff.yy.zz/Dinetsrv 0 1970:1:1:0:0:0 1 GNUTAR //fff.yy.zz/Cinetsrv 0 1970:1:1:0:0:0 1 GNUTAR //r.yy.zz/Cinetsrv 0 1970:1:1:0:0:0 1 GNUTAR //eee.yy.zz/Elogs 0 1970:1:1:0:0:0 1 GNUTAR //eee.yy.zz/Einetsrv 0 1970:1:1:0:0:0 1 GNUTAR //eee.yy.zz/Cinetsrv 0 1970:1:1:0:0:0 1 GNUTAR //vv.yy.zz/Cinetsrv 0 1970:1:1:0:0:0 1 GNUTAR /usr/local/ 0 1970:1:1:0:0:0 1 GNUTAR /var/xxx// 0 1970:1:1:0:0:0 1 exclude-file=*hh.yy.zz* ** GNUTAR /var/m/ 0 1970:1:1:0:0:0 1 exclude-file=./k GNUTAR /yyy/ 0 1970:1:1:0:0:0 1 GNUTAR /kkk/ 01970:1:1:0:0:0 1 exclude-file=./ppp The size it's 928 bytes 64K Do you have any other clue? Thanks. I strongly suspect the packet is truncated ( 64K), which basically means there are too many entries. [...] -- Enrique Rodríguez Lázaro
Re: amrecover and index record
# ll /var/lib/amanda/gilsdorf/index/pinguin.gilsdorf.de/_etc drwxr-sr-x2 root root 64 Jun 29 09:27 . drwxr-sr-x3 root root 55 Jun 29 09:27 .. -rw---1 root root20008 Jun 29 09:27 20010629_0.gz Why is it owned by root? What user is amindexd running as (look at your inetd.conf or xinetd config file)? I found a strange output in /var/lib/amanda/gilsdorf/amdump.1: SETTING UP FOR ESTIMATES... setting up estimates for pinguin.gilsdorf.de:/etc pinguin.gilsdorf.de:/etc overdue 11502 days for level 0 Like many pieces of software, sometimes Amanda sets internal values to odd values to force something to happen. I suspect that's all you're seeing here. For instance, it might be trying to make absolutely certain a level zero is performed. However, I'd also recommend checking the log files and the curinfo database to make sure you don't have some permission problems there. As with the index file, they should be owned by the Amanda user, not root (unless you configured your system using --with-user=root, which is unusual). Assuming your Amanda user is *not* root, you should never, ever, run any Amanda command (except amrecover) as root. They can leave files laying around with the wrong ownership. Frank John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amrecover and index record
On 29 Jun, John R. Jackson wrote: -rw---1 root root20008 Jun 29 09:27 20010629_0.gz Why is it owned by root? What user is amindexd running as (look at your inetd.conf or xinetd config file)? amindexd is running as root. I have to do my dump as root because I use tar. reiserfs on Linux doesn't hava a dump command. So user amanda doesn't have the permission to do a backup I think the problem is tar. The FAQ is saying there are some problems with tar 1.13.18 and amrecover. I'm using tar 1.13.19 but maybe I should wait for 1.14.x Thank you for helping me Frank PGP signature
big filesystem
Hi Everybody:
Again I have problems with another filesystem is not too big but the machine is slow and it is outside the firewall. I had this problem before and I increased the firewall idle to 60 minutes and I used as dumptype "comp-server" (compression fast but on the tape server)and it worked until the last week. The size is 2.2 Gb it is not too big but for my machines seems that it is.
I have as etimout 6000 and dtimeout 1800 but I don;t think so that they are the problem.
This is the amanda report that I received this morning
These dumps were to tape miro_daily-10.
Tonight's dumps should go onto 6 tapes: miro_daily-11, miro_daily-12, miro_daily-13, miro_daily-14, miro_daily-15, miro_daily-16.
FAILURE AND STRANGE DUMP SUMMARY:
duchamp.to /Local/Users lev 0 FAILED [mesg read: Connection reset by peer]
duchamp.to /tomandandy/usrlocal lev 1 STRANGE
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:35
Run Time (hrs:min) 2:34
Dump Time (hrs:min)0:48 0:19 0:29
Output Size (meg) 392.1 272.0 120.1
Original Size (meg) 902.7 588.0 314.7
Avg Compressed Size (%)42.6 46.3 35.5 (level:#disks ...)
Filesystems Dumped 22 1 21 (1:18 2:2 3:1)
Avg Dump Rate (k/s) 140.1 243.7 71.4
Tape Time (hrs:min)0:09 0:06 0:03
Tape Size (meg) 392.8 272.0 120.7
Tape Used (%) 3.22.21.0 (level:#disks ...)
Filesystems Taped22 1 21 (1:18 2:2 3:1)
Avg Tp Write Rate (k/s) 757.9 831.6 631.7
FAILED AND STRANGE DUMP DETAILS:
/-- duchamp.to /Local/Users lev 0 FAILED [mesg read: Connection reset by peer]
sendbackup: start [duchamp.tomandandy.com:/Local/Users level 0]
sendbackup: info BACKUP=/usr/bin/gnutar
sendbackup: info RECOVER_CMD=/usr/bin/gnutar -f... -
sendbackup: info end
\
/-- duchamp.to /tomandandy/usrlocal lev 1 STRANGE
sendbackup: start [duchamp.tomandandy.com:/tomandandy/usrlocal level 1]
sendbackup: info BACKUP=/usr/bin/gnutar
sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/usr/bin/gnutar -f... -
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
? gtar: ./mailman/logs/qrunner: file changed as we read it
| Total bytes written: 39434240 (38MB, 755kB/s)
sendbackup: size 38510
sendbackup: end
\
NOTES:
planner: Forcing full dump of duchamp.tomandandy.com:/Local/Users as directed.
planner: Incremental of magritte.tomandandy.com:/home bumped to level 3.
planner: Full dump of whiteley.tomandandy.com:/Local/Users/skot promoted from 25 days ahead.
taper: tape miro_daily-10 kb 402176 fm 22 [OK]
DUMP SUMMARY:
DUMPER STATSTAPER STATS
HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
-- -
duchamp.toma -ocal/Users 0 FAILED ---
duchamp.toma -y/usrlocal 1 38510 5056 13.1 0:51 99.1 0:06 794.5
duchamp.toma /var/mail 1 65850 33536 50.9 2:52 194.9 0:41 826.9
magritte.tom -ocal/Users 19860 8384 85.0 0:33 251.6 0:11 774.5
magritte.tom /home 39960128 1.3 2:21 0.9 0:01 122.0
magritte.tom /public 1 10 32 320.0 0:00 82.0 0:20 3.2
magritte.tom /tomandandy 2 13216 13216 --0:44 297.6 0:14 960.0
magritte.tom /usr/local 11650256 15.5 0:01 194.0 0:02 190.2
manray.toman /Local 1 41740 2080 5.0 11:14 3.1 0:05 455.9
matta.tomand /Local 1 44910 19808 44.1 1:56 170.3 0:25 789.7
miro.tomanda /Local 1 14070 2880 20.5 1:07 42.9 0:05 644.2
miro.tomanda /usr/local 16370576 9.0 0:24 23.6 0:02 404.4
picasso.toma /Local 1 19380 9472 48.9 0:13 733.0 0:22 429.8
tanguy.toman /Local 1 30180 13280 44.0 2:17 97.1 0:17 795.6
tanguy.toman /usr/local 1 130 32 24.6 0:02 14.2 0:02 38.0
whiteley.tom -plications 11410 96 6.8 0:46 2.1 0:01 99.1
whiteley.tom -al/Library 24230608 14.4 0:58 10.5 0:02 423.7
whiteley.tom -Users/andy 1 760 64 8.4 0:10 6.6 0:01 69.9
whiteley.tom -Users/dave 1 10 32 320.0 0:01 41.7 0:02 38.2
whiteley.tom -ers/lauren 1 16520 13088 79.2 0:49 267.3 0:16 815.9
whiteley.tom -sers/leigh 12030128 6.3 1:11 1.8 0:01 121.1
whiteley.tom -Users/skot 0 602150 278528 46.3 19:03 243.7 5:35 831.6
whiteley.tom /usr/local 11440192 13.3 0:10 18.9 0:01 154.9
(brought to you by Amanda version 2.4.2-19991216-beta1)
does anybody can explain to me what's wrong?
Thanks a lot
Note: thank you for your help before, I split the filesystem (17 GB) and it was fine.
Sandra
Alternative prefix and sysconfigdir problem
I would like to install AMANDA into --prefix=/usr/local/amanda, but after installation the configuration files still want to be in /usr/local/amanda/etc/amanda/DailySet1, which is just plain fugly. I tried --with-configdir and --with-sysconfigdir options, but neither help, all executables still try to look in /usr/local/amanda/etc/amanda/DailySet*, but I want the path to be /usr/local/amanda/etc/DailySet*. Thanks in advance. -- Dan Three days of testing can save 10 minutes reading manuals.
Re: Too many filesystems to AMANDA?
GNUTAR /var/xxx// 0 1970:1:1:0:0:0 1 exclude-file=*hh.yy.zz* ** Two questions about this part of the file. First, was the line really split like above, or is that just an artifact of you getting the data into the E-mail? Second, I realize (or assume) you changed the data and replaced sensitive things with repeated characters (e.g. xxx), which is fine. But is that what the exclude-file= part of that line really looked like (aside from the character substitution)? In particular, were those asterisks there? And was the space there between the two parts? What does the dumptype for this client/disk look like? In particular, the exclude information. Do you have any other clue? I originally thought the problem was overflowing a packet, but the above makes me think it might be a syntax problem for this disk in your amanda.conf. If that does not turn out to be it, I sent you a patch I recently posted to amanda-hackers to get around the 64 KByte UDP packet size. You might give it a try. Make sure you use the third try version :-), as I've posted it more than once. Enrique Rodríguez Lázaro John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Problems backing up
Does this help any further? ... Not really. or is there any way in which I can see at which particular file it hangs itself? It's not necessarily hanging on a particular file. It could be that after some random period, your network dies (for that connection), or any number of other problems. The file in the holding disk should be accurate to within 32 KBytes of what GNU tar has done so far (unless you have software compression enabled). So one way to see roughly where it is would be generate your own catalogue: amrestore -p /path/to/holding/disk/file cobalt01 | gtar tvf - If you have multiple holding disk chunks for this disk, use the one with the shortest name (the one that does *not* have the .1, .2, .3 type suffixes). You could also install lsof (ftp://vic.cc.purdue.edu/pub/tools/unix/lsof or it's available from various places pre-built) and run it on the GNU tar. That should tell you what it has open. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] P.S. Please turn off send as HTML in your mailer. It's just a waste of bandwidth.
Re: big filesystem
duchamp.to /Local/Users lev 0 FAILED [mesg read: Connection reset by peer] This says the client side (or your firewall) closed the connection while dumper (on the tape machine) was trying to read the image. First, I'd recommend upgrading to the real 2.4.2p2. What you're running is 18 months old and will be very hard to debug since it was a beta snapshot. You might look at /tmp/amanda/sendbackup*debug (which will be much easier with 2.4.2p2 because of unique debug file names) and see if it had anything to say about problems processing this file system. It would also be interesting to look on the client and see if the backup is still trying to run. Sandra John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
gtar error
Hello Everyone! I have had good success in finishing the compile of Amanda and now have it installed. I am however getting an error from amdump concerning gtar. Here it is: FAILURE AND STRANGE DUMP SUMMARY: sbs.sbsala /home lev 0 FAILED [/usr/bin/gtar returned 2] Amdump writes the image to the holding disk fine, but then fails on the tape write. I am able to label the tapes, so I can actually write to them, but it doesn't like gtar. Gtar works fine when I run it manually; I can create, list and extract tar files and it always returns and exit code of 0. Does Amanda require anything special about tar? Permissions? Location? /usr/bin/gtar is a link; is that a problem? Here: lrwxrwxrwx 1 root system26 Jun 29 10:40 /usr/bin/gtar - ../../opt/freeware/bin/tar -rwxr-xr-x 1 root system148365 Mar 08 20:05 /opt/freeware/bin/tar Any ideas? Thanks a bunch! Anthony Valentine Unix System Admin/Oracle DBA Spenard Builders Supply [EMAIL PROTECTED]
Re: gtar error
FAILURE AND STRANGE DUMP SUMMARY: sbs.sbsala /home lev 0 FAILED [/usr/bin/gtar returned 2] Amdump writes the image to the holding disk fine, but then fails on the tape write. ... That's not what that message means. Amanda does not use gtar to write to tape. It runs gtar on the client and collects that (via stdout across the network) into the holding disk. The write to tape is done by Amanda itself. So the error message says gtar on the client failed. That, in turn, means the holding disk file is not valid, and it also means the tape was not used at all (for this client/disk). Was there another section of the E-mail labeled FAILED AND STRANGE DUMP DETAILS, and did it have anything to say about this client/disk? What version of Amanda are you using? If it's 2.4.2p2 (or if you built Amanda using --with-pid-debug-files), what's in the /tmp/amanda/sendbackup*debug file on this client for that disk? Anthony Valentine John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Portrange, port insecure, I'm very confuse...
Hi I can't understood about portrange. If I choose an port 1024, I have set user=root, and I don't want this. But if I choose an port 1024, amdump complains 'port not secure'!!! So, I must set user=root??? What can I do? |\_/| /###\ _|#(!) (!)#|_ --\#( Y )#/-- /#' `#\ [# #] /\|| ||/\ |#|| ||#| |#||###||#|# 00OOO OOO00 # ###=== SuLamItA GaRciA Analista de Suporte [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ 16465301 http://www.inf.ufsc.br/~sulamita Nossa geração não lamenta tanto os crimes dos perversos quanto o estarrecedor silêncio dos bondosos Martin L. King
User Configuration for Amanda
I'm currently trying to get Amanda running on my Compaq Tru 64 UNIX system and seem to be having a problem with user permissions. I understand that a typical AMANDA configuration uses a user other than root, however I haven't found much information (maybe I'm not looking in the right place) about how to set up that other user. There are files on the system which are only readable by the root user, so I'm wondering how another user can read those files unless it is also a privileged user. Can anyone give me an overview of a typical user setup for a UNIX server? Thanks, Rob
Re: Portrange, port insecure, I'm very confuse...
I can't understood about portrange. ... You're not the only one :-). It's pretty confusing. I posted an overview of how Amanda uses ports to amanda-hackers last week. You might look in the archives for Subject Use of UDP/TCP ports in Amanda. If I choose an port 1024, I have set user=root, and I don't want this. But if I choose an port 1024, amdump complains 'port not secure'!!! So, I must set user=root??? What can I do? At the moment, you must set --with-portrange (the TCP ports) to values greater than or equal to 1024. You must set --with-udpportrange (the UDP ports) to values less than 1024. In addition, you'll need to set up your firewall/NAT to let both ranges of ports through as is. However, there is a bug in 2.4.2p2 that will cause amrecover to fail in the above setup. I'm working on a fix for that. SuLamItA GaRciA John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: User Configuration for Amanda
... There are files on the system which are only readable by the root user, so I'm wondering how another user can read those files unless it is also a privileged user. ... If you use the system dump program (e.g. dump or vxdump or whatever your vendor calls it), that reads from the raw disk devices so the Amanda user just needs read access to that (*). If you use GNU tar, Amanda runs it under a program called runtar that it provides, and runtar is setuid root. Rob John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] (*) Actually, some systems insist on dump being run by root, and for those Amanda provides rundump ala runtar.
CD as tape device?
Would it be possible to set up the tape device so that one could use a CD burner for backups? Best regards, --Thomas Kleymann
Re: CD as tape device?
Would it be possible to set up the tape device so that one could use a CD burner for backups? You want the amanda-242-tapeio branch from CVS. That generalizes the Amanda tape I/O subsystem and one of the drivers is called file, which writes to a set of disk files to emulate a tape. You could then take that area and write it to a CD. The amanda(8) man page in that branch has been updated to document this. --Thomas Kleymann John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: User Configuration for Amanda
For things that you want to keep accessed by certain uids, you can change the group and make it group readable. That's what I had to do to get AMANDA to be able to read my raw devices (partitions) for backing up. You can just create a user called 'amanda' and a group called 'backup'. Make 'backup' group readable on whatever you don't want to be owned by amanda. Well that's just one way to do it. There are others, but it's worked for me... AMANDA in general should be owned by the user you specified in the ./configure command line. As long as you do that the permissions problems shouldn't be too big a deal... HTH, Chris On Fri, 29 Jun 2001, Rob Earl wrote: I'm currently trying to get Amanda running on my Compaq Tru 64 UNIX system and seem to be having a problem with user permissions. I understand that a typical AMANDA configuration uses a user other than root, however I haven't found much information (maybe I'm not looking in the right place) about how to set up that other user. There are files on the system which are only readable by the root user, so I'm wondering how another user can read those files unless it is also a privileged user. Can anyone give me an overview of a typical user setup for a UNIX server? Thanks, Rob I'm a free-range carnivore.
Re: gtar error
FAILURE AND STRANGE DUMP SUMMARY: sbs.sbsala /home lev 0 FAILED [/usr/bin/gtar returned 2] What is inside /tmp/amanda/sendbackup* or /tmp/amanda/sendsize* about the disk? Olivier
Re: User Configuration for Amanda
I use GNU tar, never used dump, but I created a group amanda, a user amanda, like a plain group and user. I configured --with-user=amanda --with-group=amanda I made Under root, I made install and that's it, I did not need to modify ANY group or ownership of the files. It works automatically as it is. OK, I had to modify ownership of the /dev/tape device. Olivier
