Holding incrementals on disk
Hi. You wrote in the Amanda FAQ: ``This can be wasteful, specially if you have a small amount of data to back up, but expensive large-capacity tapes. One possible approach is to run amdump with tapes only, say once a week, to perform full backups, and run it without tape on the other days, so that it performs incremental backups and stores them in the holding disk. Once or twice a week, you flush all backups in the holding disk to a single tape.'' Can you expand on this? What should I use for the cycle parameters in amanda.conf? How should I flush the incrementals in the holding disk to tape? Thanks, Ben
Questions and Answers and Thanks
Hmm, Favor #1: can the reply to adress on the digests be set to @amanda.org ;) * [EMAIL PROTECTED] [EMAIL PROTECTED] (Fri, Jan 19, 2001 at 06:34:02AM -) First off, thanks to all who answered my priorities question. ;) Second. I noticed when looking through the logs that the *dumper* performance is around the 1Kps (or less) on my system , whereas the *taper* gets a performance of about 7 Kps. So apparently it's not the speedn of my tapedrive that's the bottleneck, but soemthing within amanda. I have now turned compression off and im hoping this will imporve matters. Are there any other ways to tweak amanda.conf to improve dumper performance (I've set the bandwith parameters to large values since it's on local disks and I've specified local in my disklist. define interface local { comment "a local disk" use 40 Mbps } define interface le0 { comment "100 Mbps ethernet" use 4000 kbps } Also, from yestersdays digest lsof: We tried to get lsof installed on our solaris box 2 months ago but it failed to run after the install - we got a 32/64 bit error message. I assume you then contacted the author (who happens to be my boss) and he got it fixed for you, right? That program runs on bajillions of OS's and versions. It would be truly amazing if it does not work at your site. I have lsof running on Sol 2.6 7 and 8 and it rules, now if only your boss would decide to port it to Irix 6.5 . One of my biggest frustrations with Irix .. I cannot get lsof to compile and work on it ;) ) Message: 22 Date: Fri, 19 Jan 2001 11:20:44 +1100 (EST) From: Ben Elliston [EMAIL PROTECTED] Subject: HP-DAT.ps I want to use this template for labels. I just tried printing the template (through Ghostscript) and get an empty PCL output file. Is there something weird with this PostScript file that I should know about? yeah, it's not a full postscript file, but it's part of it (the beginning) the rest will be attached by amanda when it runs amreport. Most notably, there is now (showpage) at the end which means it will not work on all PS devices. (showpage) is what tells a PS device to actually display what it has built sofar. Ghostscript immediately displays (at least in X11 mode) what it gets, hence the differences. If you wanna print it, use amreport . On a related note, I managed to hack some logos in the postscript label templates (well most of the code is already there). If anyone is interested Ill see if I can work the hack into a small perl script ;) Kind regards, -- Gerhard den Hollander Phone +31-10.280.1515 Technical Support Jason Geosystems BV Fax +31-10.280.1511 (When calling please note: we are in GMT+1) [EMAIL PROTECTED] POBox 1573 visit us at http://www.jasongeo.com 3000 BN Rotterdam JASON...#1 in Reservoir CharacterizationThe Netherlands This e-mail and any attachment is/are intended solely for the named addressee(s) and may contain information that is confidential and privileged. If you are not the intended recipient, we request that you do not disseminate, forward, distribute or copy this e-mail message. If you have received this e-mail message in error, please notify us immediately by telephone and destroy the original message.
Re: DAILY AMANDA MAIL REPORT FOR January 18, 2001
Hi! Iam just beginning to work with amanda! At the last days there were no problems, but this mail of the daily amanda backup just shows me a lot of failures which I have never seen! beethoven /home lev 1 FAILED [dumps way too big, must skip incremental dumps] zeus /home1 lev 1 FAILED [dumps way too big, must skip incremental dumps] tunix /home lev 1 FAILED [dumps way too big, must skip incremental dumps] zeus /home5 lev 1 FAILED [dumps way too big, must skip incremental dumps] zeus /home6 lev 1 FAILED [dumps way too big, must skip incremental dumps] zeus /home4 lev 1 FAILED [dumps way too big, must skip incremental dumps] tunix /home1 lev 1 FAILED [dumps way too big, must skip incremental dumps] Notes: planner: Dump too big for tape: full dump of servnix:/home delayed. planner: Dump too big for tape: full dump of batman:/home4 delayed. planner: Dump too big for tape: full dump of info-e:/home4 delayed. taper: tape daily41 kb 30781504 fm 38 writing file: short write taper: retrying info-fa0:/home2.0 on new tape: [writing file: short write] taper: tape daily42 kb 30773952 fm 5 writing file: short write driver: going into degraded mode because of tape error. thanks for help Ayten. -- -- Ayten Sen Datensicherung Uni-Paderborn Bro E3.148 Tel: PB - 60 33 18 , privat: 05251/686208 E-mail: [EMAIL PROTECTED], [EMAIL PROTECTED] ---
how can I know which levels?
Hi people, How can I check which levels of Amanda will made in backup tape? (what kind of command i can use to do that? exist any?) Thanks in advanced, Diogo Batista Salgueiro Curitiba - Paran - Brasil
Re: Problem with Backing up 1 host
Could it be that the firewall gets stricter rules at night? I doubt the problem was an actual time-out, since three minutes is just too short a time for an estimate time-out. The firewall does not change rules. I, again, had the same exact problem last night. Can I turn on some debugging to try to narrow this down? Thanks. Michael Russell [EMAIL PROTECTED] Mathematical Technologies, Inc. Providence, RI 02906 USA
Re: Ejecting tapes
At 07:23 AM 1/19/01 +0100, Jens Bech Madsen wrote: Ben Elliston [EMAIL PROTECTED] writes: Is there a way for Amanda to eject the tape at the end of a run so that I can simply remove it each day (and to indicate that the tape run has actually completed)? Or should I just run `mt offline' myself? Yes. You can set your crontab entry that starts amanda to eject the tape: 0 23 * * * /usr/local/sbin/amdump Daily1 mt offline Technically, you have ejected the tape yourself, but the tape will be waiting for you when you arrive at the office in the morning. Andrew Robinson * Andrew W. Robinson | Voice: +1 (504)-889-2784 * * Computerized Processes Unlimited, Inc. | FAX:+1 (504)-889-2799 * * 4200 S. I-10 Service Rd., Suite 205| E-Mail: [EMAIL PROTECTED] * * Metairie, LA 70001 | WWW: http://www.cpu.com * * "Consulting System Integrators" *
Re: Ejecting tapes
On Fri, Jan 19, 2001 at 08:53:49AM -0600, Andrew Robinson wrote: At 07:23 AM 1/19/01 +0100, Jens Bech Madsen wrote: Ben Elliston [EMAIL PROTECTED] writes: Is there a way for Amanda to eject the tape at the end of a run so that I can simply remove it each day (and to indicate that the tape run has actually completed)? Or should I just run `mt offline' myself? Yes. You can set your crontab entry that starts amanda to eject the tape: 0 23 * * * /usr/local/sbin/amdump Daily1 mt offline Technically, you have ejected the tape yourself, but the tape will be waiting for you when you arrive at the office in the morning. Or run amanda from a wrapper script. Which we do anyway, to accomplish certain other preparations and cleanup. 0 23 * * * /backup/bin/amanda-wrapper.sh amanda-wrapper.sh may contain things such as -- Scheduling of archival backups, which may be a bit more than "cron" understands. -- Taking snapshots of databases for backup purposes -- gathering other bits and pieces deemed inconvenient for inclusion in disklists, onto a convenient rotating archive. For example, snapshots of /etc from all the hosts in the office. Or an rsync of material on hosts connected by low-speed link, which renders normal backups impractical. -- And of course, ejecting the tape. -- - Dan Wilder [EMAIL PROTECTED] Technical Manager Correspondent SSC, Inc. P.O. Box 55549 Phone: 206-782-7733 x123 Seattle, WA 98155-0549 URLhttp://www.linuxjournal.com/ -
Re: Holding incrementals on disk
Ben Elliston wrote: Hi. You wrote in the Amanda FAQ: ``This can be wasteful, specially if you have a small amount of data to back up, but expensive large-capacity tapes. One possible approach is to run amdump with tapes only, say once a week, to perform full backups, and run it without tape on the other days, so that it performs incremental backups and stores them in the holding disk. Once or twice a week, you flush all backups in the holding disk to a single tape.'' Can you expand on this? No or wrong or active tape in drive means for amanda: put the backups into holding disk and leave them there. If you specify reserve 100 in config it will degrade any level 0 backups to level 1. If not it takes only 100-reserveoption percent for level 0 in holding disk. If you leave out the tape lets say for a week, all the backups will be in the holding disk, provided its large enough. Then if the right tape is in drive it will happily put a lot of level 0 backups onto it, due as they are. When the holding disk holds some amount of incrementals, you place another valid tape in drive and flush them manually. What should I use for the cycle parameters in amanda.conf? No change there. The cycles just reflect the time you want to keep backups and the frequency you want to have a complete backup. Just make sure your holding disk is big enough. How should I flush the incrementals in the holding disk to tape? Thanks, simply run amflush configname (as your amanda user) with a valid tape for your configuration in drive. Ben Or you can try another approach: You can use two different configs. Not really different, as the only changes are the name and the pattern for the label string. This way you could have without_tape and with_tape as confignames and all the tapes labelled for config with_tape on weekdays you run amdump with config without_tape and on weekends with with_tape. as it would be in my crontab: 0 22 * * 1-6 amdump without_tape 0 22 * * 7 amdump with_tape Because the configs share the same directorys and index files etc. you can amflush the without_tape backups with the with_tape configuration and it's tapes. AND you can leave the tape in drive. I don't know exactly if with_tape would _always_ make level 0 backups, but I believe it would try, because of the dumpcycle parameter. To be sure you can set dumpcycle to 0, so the level 0 dumps will always be due when amdump runs. (Note that reserve should be 100 for weekdays, as you want incrementals. Or you play with the nofull and the new incronly options) I'm doing with a variation of that method, and I'm quite happy with it. Simon Mayr
Re: Questions and Answers and Thanks
On Fri, Jan 19, 2001 at 09:59:57AM +0100, Gerhard den Hollander wrote: Hmm, Favor #1: can the reply to adress on the digests be set to @amanda.org ;) * [EMAIL PROTECTED] [EMAIL PROTECTED] (Fri, Jan 19, 2001 at 06:34:02AM -) unsubscribe from [EMAIL PROTECTED] and subscribe to [EMAIL PROTECTED] The @egroups.com lists should be use only for archiving, no one should subscribe or send mail to them. Jean-Louis -- Jean-Louis Martineau email: [EMAIL PROTECTED] Departement IRO, Universite de Montreal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montreal, Canada, H3C 3J7Fax: (514) 343-5834
Basic question
Hello all , I have been trying to get amanda to work for the last week , to no avail. I am sure it is something simple. I worked out all of the installation and configuration issues , however here is the problem. I am backing up from a centralized backup server , all of the clients "sync" content to the server , and the backups are performed from a dump directory on the server. I am using a sparc-5 with a raid 5 array. The total size of the backup is around 30 gb , which theoretically should fit on our 20/40 DLT tapes, but solaris doesn't do well honoring compressed capacity. The problem is this. Every time I try and run amanda , I get an error that the dump cannot fit on a single tape , so it errors out. It also complains about not being able to switch to an incrementatl dump - is that from /etc/dumpdates ? (Until now , I have used 'star' to backup). Do I need to define the changer as a manual one ??? If so , is there documentation to show me how ? I tried changing tapes per run to 2 , but the documentation says that if you do not define a changer , then tapes per run should be set to 1. Thank you in advance for your help, Daren L. Eason, Sr. Systems Administrator III Client Services Evergreen Internet, Inc. (480)926-4500 x. 2211 http://www.evergreen.com
Priorities, amanda speed
More on the same story .. Im getting there :) Seems that the bottleneck indeed was the gzip process .. I've changed my disklist/amanda.conf to no longer compress the images, and instead rely on the hardware compression in the LTO drive (trading tape space for speed ;) ), and the results are rather dramatic. A normal amanda session with compression takes between 10 and 15 hours, running whitout compression finished in 3.5 hours . 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). Kind regards, -- Gerhard den Hollander Phone +31-10.280.1515 Technical Support Jason Geosystems BV Fax +31-10.280.1511 (When calling please note: we are in GMT+1) [EMAIL PROTECTED] POBox 1573 visit us at http://www.jasongeo.com 3000 BN Rotterdam JASON...#1 in Reservoir CharacterizationThe Netherlands This e-mail and any attachment is/are intended solely for the named addressee(s) and may contain information that is confidential and privileged. If you are not the intended recipient, we request that you do not disseminate, forward, distribute or copy this e-mail message. If you have received this e-mail message in error, please notify us immediately by telephone and destroy the original message.
Re: amanda: lev 0 FAILED [data timeout]
On Tue, 16 Jan 2001, Bruce Ferrell wrote: Looks like the network dropped out No, that's not the case. The same behaviour happens consistantly all the time, only with that computer (not the other 5 which are on the same hub which can access the network fine (it's running a mail server, httpd, ssh server). Lately what happend was something even more interesting: I had a dump of like 5-6 machines and when it got to the funny one (the one running linux which doesn't behave) it started dumping (or so it sayd) and the amanda server kept waiting and waiting. I let it sit there for a day or so. The client had sendbackup running as a process and all the other amanda processes as if it was backing up properly, but it was stalled. I had to manually kill sendbackup on that client in order for the rest of the disklist to continue it's backup. I will do some more debugging... In the meanwhile, if nobody can figure out what it is, I would also appreciate advice on what info to gather, so that you can better help debug. Tony Magni wrote: Again, only on one of my linux boxes, amcheck returns no erros, file size estimation goes all well. Backup starts, then hangs (just for the one computer). I can backup the /boot partition fine (it's only a few megs), but not the / and /home. I get strangenesses from sendbackup: /-- myhostname /dev/sda2 lev 0 FAILED [data timeout] ? dumper: strange [missing size line from sendbackup] ? dumper: strange [missing end line from sendbackup] \ and: /-- myhostname /home lev 0 FAILED [data timeout] sendbackup: start [discordia:/home level 0] sendbackup: info BACKUP=/sbin/dump sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/sbin/restore -f... - sendbackup: info COMPRESS_SUFFIX=.gz sendbackup: info end | DUMP: Date of this level 0 dump: Sun Jan 14 21:31:56 2001 | DUMP: Date of last level 0 dump: the epoch | DUMP: Dumping /dev/sdb1 (/home) to standard output | DUMP: Label: none | DUMP: mapping (Pass I) [regular files] | DUMP: mapping (Pass II) [directories] | DUMP: estimated 3704606 tape blocks. | DUMP: Volume 1 started at: Sun Jan 14 21:32:41 2001 | DUMP: dumping (Pass III) [directories] | DUMP: dumping (Pass IV) [regular files] \ To me it seems like dump is doing a good job. Also this from /tmp/amanda/amanda.debug: all seems well up until here: amandahosts security check passed amandad: running service "/usr/lib/amanda/sendbackup" amandad: sending REP packet: Amanda 2.4 REP HANDLE 000-38D00508 SEQ 979605303 CONNECT DATA 3041 MESG 3042 INDEX 3043 OPTIONS ;compress-fast;bsd-auth;index; amandad: waiting for ack: timeout, retrying amandad: got ack: Amanda 2.4 ACK HANDLE 000-38D00508 SEQ 979605303 amandad: pid 31153 finish time Mon Jan 15 20:02:05 2001 Where it had to retry to get ack. but then in sendbackup.debug: sendbackup: started index creator: "/sbin/restore -tvf - 21 | sed -e ' s/^leaf[]*[0-9]*[ ]*\.// t /^dir[ ]/ { s/^dir[ ]*[0-9]*[ ]*\.// s%$%/% t } d '" index tee cannot write [Broken pipe] And I get [data timeout] as output of amstatus. Ideas? Thank you for your support. Let me know if any of these questions are worth posting on the newsgroup. I don't post there, since I am not sure if these are common knowledge questions or not, although I have not found the answer anywhere. -- Tony Magni Department of Neurological Surgery University Hospitals of Cleveland (216)844-1306, [EMAIL PROTECTED], http://discordia.cwru.edu/tinton/ - "I know Cleveland: I spent a year there one night!" (Bill, San Francisco, 1994) -- Tony Magni Department of Neurological Surgery University Hospitals of Cleveland (216)844-1306, [EMAIL PROTECTED], http://discordia.cwru.edu/tinton/ - "I know Cleveland: I spent a year there one night!" (Bill, San Francisco, 1994)
RE: Basic question
Some people would consider fitting 30Gb on a 20Gb tape optimistic. Here's quick list of things to check that might help: 1. Are you using either software or hardware compression? If you are using both, you could wind up with backups taking more tape than expected. 2. Is/was the tape drive in compression mode when amlabel was run? Did it stay in compression mode? 3. Is/was the tape drive in compression mode when amdump started? Did it stay in compression mode? 4. If you have more than one entry in your disklist, try commenting out all but one entry. AMANDA always starts a disk she has never seen before with a level 0 backup, and if that backup doesn't fit on tape, you're just done. Spreading out additions to the disk list over several days helps her balance the level 0 backups across the dumpcycle. This is where the "can't switch to incremental" usually comes from. 5. Check your tapetype definition, and make sure that it reflects your (approximate) compressed tape capacity, if you're using hardware compression. For example, if you have a tapetype that specifies the tape length as 20Gb, AMANDA will honor that even if you could have stored 50G on that tape because your data is very compressible. Once you are sure that hardware compression is on (2 and 3 above) you can increase your tape size to reflect the additional (theoretical) capacity. The best idea I've seen on how to do this is (from JRJ, I think) to set it to the claimed capacity and expect it to run out of tape. (AMANDA handles out-of-tape very well.) Once it runs out of tape, you have an idea as to what sort of compression you're getting. My shameless plug for software compression: If you use software compression instead of hardware, you can distribute the compression load to clients where appropriate; AMANDA can plan backups based on more accurate information about tape size; tapes may be easier to recover in a tape drive that isn't an exact match; you can turn compression on or off for each disk in your disklist. -Original Message- From: Daren Eason [mailto:[EMAIL PROTECTED]] Sent: Friday, January 19, 2001 11:19 AM To: [EMAIL PROTECTED] Subject: Basic question Hello all , I have been trying to get amanda to work for the last week , to no avail. I am sure it is something simple. I worked out all of the installation and configuration issues , however here is the problem. I am backing up from a centralized backup server , all of the clients "sync" content to the server , and the backups are performed from a dump directory on the server. I am using a sparc-5 with a raid 5 array. The total size of the backup is around 30 gb , which theoretically should fit on our 20/40 DLT tapes, but solaris doesn't do well honoring compressed capacity. The problem is this. Every time I try and run amanda , I get an error that the dump cannot fit on a single tape , so it errors out. It also complains about not being able to switch to an incrementatl dump - is that from /etc/dumpdates ? (Until now , I have used 'star' to backup). Do I need to define the changer as a manual one ??? If so , is there documentation to show me how ? I tried changing tapes per run to 2 , but the documentation says that if you do not define a changer , then tapes per run should be set to 1. Thank you in advance for your help, Daren L. Eason, Sr. Systems Administrator III Client Services Evergreen Internet, Inc. (480)926-4500 x. 2211 http://www.evergreen.com
question about Solaris
I want to set up amanda on a solaris 7 system. the problem that I am having is that I can't figure out how to reference the disk drives. In SunOS you could use sd3g or sd1a or whatever. with Solaris, they are reference like c0t0d0s1 Amanda doesn't seem to like this. I have also tried giving it /usr, but it doesn't seem to like that either. thank you in advance for any help you can give me. Annadiana Abedini Sr. Systems Programmer Multnomah County - ISD Portland, Oregon
all because of blank lines!
Hello! Thank you to those who responded to me so quickly! After having it confirmed that either notation (c0t0d0s6 or /usr) *should* work, I went back and did some experimentation and found that amanda refused to work because I had blank lines after the lines that specified the disk! Anyway, thank you again for your help!! Annadiana
Installation Woes
We've been using amanda to backup 2 FreeBSD boxes and 5 PeeCee's for about two years now. But it was time to upgrade our Unix boxes as well as the Operating Systems. I managed to upgrade the two FreeBSD boxes to FreeBSD-4.1.1 Release and FreeBSD 4.2 Release, and have the main "amanda" box continue to back them up quite nicely with fresh installs of everything, including Amanda 2.4.1 Now it was time to upgrade the amanda server itself. FreeBSD 4.2 Release and Amanda 2.4.1 I've been trying everything to get it to backup the 5 PeeCee shares without luck. It happily backs up the two Unix boxes but will not touch the PeeCee's. I've been playing in the /usr/ports/misc/amanda24 directory... figured it would be a breeze to compile out of the ports. The dependency programs are all there and Amanda compiles, and works basically, except for the PeeCee shares. I did install Samba first, and it's working fine. I edited /usr/ports/misc/amanda24/Makefile to include some options I wanted: CONFIGURE_ARGS= --libexecdir=${PREFIX}/libexec/amanda \ --with-amandahosts --with-fqdn \ --with-dump-honor-nodump \ --with-smbclient=/usr/local/bin/smbclient \ --with-samba-user=samba --with-config=eagle --without-clien t \ --with-user=amanda --with-group=operator And I do a "make make install" and you'd think everything is lovely. If I "su amanda" and run '/usr/local/sbin/amcheck eagle' the check goes just fine. Now, if I edit /usr/local/etc/amanda/eagle/disklist and uncomment out the PC shares, I've been getting a few different comments, mainly: WARNING: amanda: selfcheck request timed out. Host down? Client check: 3 hosts checked in 30.295 seconds, 1 problem found. I've also got "selfcheck timed out" instead of "host down" I can look at the unix clients and the /tmp/amanda/amandad.debug file looks good (and the unix clients are working fine). It's almost like the --with-smbclient option isn't being used. I've read the FAQ and looked at the section "selfchick timed out" but nothing applies to the smbclient shares. As I've tinkered with the Makefile, I've gone back into /usr/ports/misc/amanda24 and done a: make clean make deinstall make make install But I still have no success with smbclient shares and I'm at a loss any suggestions from the list? Thanks Gerry.
Re: Basic question
In addition to what Paul Bort said ... I am backing up from a centralized backup server , all of the clients "sync" content to the server , and the backups are performed from a dump directory on the server. ... Is there some reason you're not letting Amanda run directly on the clients? What kind of clients are they? Why the sync operation? ... but solaris doesn't do well honoring compressed capacity. I doubt it has anything to do with Solaris. See Paul's notes. ... It also complains about not being able to switch to an incrementatl dump - is that from /etc/dumpdates ? (Until now , I have used 'star' to backup). Next time, **please** post the exact message you're getting. Amanda generates a lot of different warning and it's hard to know what's going on without the text. In this case, I suspect it said the disk was new and that's why it could not switch to an incremental. As Paul said, the first time Amanda sees a new client/disk, it **must** do a level 0. Do I need to define the changer as a manual one ??? ... Are you asking if that's the way to use multiple tapes in a run if you don't have a real changer? If so, then yes, setting up Amanda to use chg-manual is one way to do so. If so , is there documentation to show me how ? ... I'm working on improving that, but the short answer is that you need to set tapedev to the physical tape drive, set tpchanger to "chg-manual" and set changerfile to a base name (e.g. /var/amanda/chg-manual) that chg-manual will append various suffixes to for its own use (e.g. /var/amanda/chg-manual-slot). If you're going to run amdump from cron, look at the chg-manual script for notes on how to do that. Normally it needs /dev/tty. Daren L. Eason, Sr. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: how can I know which levels?
How can I check which levels of Amanda will made in backup tape? (what kind of command i can use to do that? exist any?) It's difficult to know what level Amanda will use in the next run. That depends on how much data there is to be backed up. If you want to know what levels it did on an already written tape, you can use amtoc or the find subcommand of amadmin. Diogo Batista Salgueiro John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Never-ending dump
I've been running an `amdump' for about 16 hours now -- the following dump (a level 0, as it happens) keeps happening over and over again. When I reach 100%, it starts again! dublin:sda4 0 1878319k dumping 1679872k (89.43%) (8:08:27) This file system is too large for the holding disk, if that makes any difference. Any idea what's going on here? I've just had to abort the backup. Thanks, Ben
Re: DAILY AMANDA MAIL REPORT FOR January 18, 2001
... this mail of the daily amanda backup just shows me a lot of failures which I have never seen! beethoven /home lev 1 FAILED [dumps way too big, must skip incremental du mps] This says that after Amanda had gathered all the dump size estimates, and kept reducing the size as much as it could, these file systems just would not fit on the amount of tape you told it it could use. It's interesting it could not bump to level 2 (if that would have helped). Have you changed the bump* amanda.conf parameters? You might post the results of running your amanda.conf through this (to remove all the comments and empty lines): sed -e '/^#/d' -e '/^$/d' planner: Dump too big for tape: full dump of servnix:/home delayed. This is more of the same. taper: tape daily41 kb 30781504 fm 38 writing file: short write taper: retrying info-fa0:/home2.0 on new tape: [writing file: short write] taper: tape daily42 kb 30773952 fm 5 writing file: short write driver: going into degraded mode because of tape error. These are normal. It says Amanda was able to write about 30 GBytes on those two tapes, but it still had more to dump so dropped into degraded mode (leaving the dumps in the holding disk). Ayten. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Never-ending dump
I've been running an `amdump' for about 16 hours now -- the following dump (a level 0, as it happens) keeps happening over and over again. When I reach 100%, it starts again! Is this 2.4.2? If so, there's a known bug that we think is fixed in the latest CVS sources. If you can't or don't want to get them, there will be a 2.4.2p1 shortly, or ask me offline and I'll send you the patch. Ben John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amanda: lev 0 FAILED [data timeout]
I will do some more debugging... In the meanwhile, if nobody can figure out what it is, I would also appreciate advice on what info to gather, so that you can better help debug. Attach a debugger to the sendbackup process and use "where" to get a call stack. Ditto for the dumper it is connected to on the server. It would help if you had the client and server built with -g (debugging symbols). John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
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]
strange dumps
Hi there, I using amanda to backup several servers, but now some of my disks started signaling the following error. Those are vx filesystems of an HP 10.20, I have done fbackup on those filesystems and I worked. I also tried to switch from compressed to noncompressed but with no luck. Has anyone any clue what has happened? TIA Arnar Gestsson SysAdm TrackWell Software Dump data FAILED AND STRANGE DUMP DETAILS: FAILURE AND STRANGE DUMP SUMMARY: odinn /home2 lev 1 STRANGE odinn /home lev 1 STRANGE /-- odinn /home2 lev 1 STRANGE sendbackup: start [odinn:/home2 level 1] sendbackup: info BACKUP=/usr/sbin/vxdump sendbackup: info RECOVER_CMD=/usr/sbin/vxrestore -f... - sendbackup: info end | vxdump: Date of this level 1 dump: Fri Jan 19 01:09:41 2001 | vxdump: Date of last level 0 dump: Thu Dec 28 01:35:40 2000 | vxdump: Dumping /dev/vg02/rlvol2 (/home2) to standard output | vxdump: mapping (Pass I) [regular files] | vxdump: mapping (Pass II) [directories] | vxdump: estimated 1527272 blocks (745.74MB) on 0.01 tape(s). | vxdump: dumping (Pass III) [directories] | vxdump: dumping (Pass IV) [regular files] | vxdump: 64.57% done, finished in 0:02 | vxdump: SIGSEGV: ABORTING! ? dumper: strange [missing size line from sendbackup] ? dumper: strange [missing end line from sendbackup] \
Amanda should know better...
I've got a 2.4.2 amanda server using samba to backup the C:\ drive of an NT workstation. That user's machine has C:\ set as one 8gig partition, and it's 6gig full. My tapes have just over 4 gig capacity compressed. (Of course there are many other partitions in this backup set, but those aren't the problem.) Amanda pulls the data from the NT disk, and writes it to 5 gigs worth of compressed disk, in 6 chunks. Now, the compressed sum of all these sections is already well beyond what the tapetype says my tape can handle. So, why is amanda even trying to write 5 gigs worth to a tape it knows can only hold 4 gig? Isn't it checking? It keeps running into EOT (like, duh) and it reschedules the same machine the next day. I've looked at the past week's backups and all I have is one or two very small incrementals, and repeated failed attempt to backup this same NT box. I thought the planner was supposed to be more intelligent than this? Here's the line for this disk from the amstatus report: joi://janet/c$0 5619328k writing to tape (18:04:52) Here's the end of the dump log: | tar: dumped 55234 files and directories | Total bytes written: 6937226240 sendbackup: size 6774635 sendbackup: end INFO taper tape DailySet201 kb 4824992 fm 3 writing file: No space left on device FAIL taper joi //janet/c$ 0 [out of tape] ERROR taper no-tape [[writing file: No space left on device]] And here's the tapetype: define tapetype EXABYTE-Eliant-820 { comment "EXABYTE-Eliant-820 ( EXB-85058HE- Rev 01 ), 120m tape, Adaptec AIC-7860 Ultra SCSI host adapter" length 4403 mbytes filemark 102 kbytes speed 909 kbytes lbl-templ "/usr/local/etc/amanda/DailySet2/EXB-8500.ps" } Here's the schedule: GENERATING SCHEDULE: joi //janet/c$ 11344 0 1970:1:1:0:0:0 3445388 114846 joi //treacy/c2$ 11344 0 1970:1:1:0:0:0 849557 28318 joi //mheitkamp/backupd$ 11343 0 1970:1:1:0:0:0 0 0 Why is amanda blowing the tape size by 25%? Why is it being stubborn about doing this disk, a low-priority user workstation, instead of doing the medium and high-priority file servers? -- Joi EllisSoftware Engineer Aravox Technologies [EMAIL PROTECTED], [EMAIL PROTECTED] No matter what we think of Linux versus FreeBSD, etc., the one thing I really like about Linux is that it has Microsoft worried. Anything that kicks a monopoly in the pants has got to be good for something. - Chris Johnson
Re: A list of implementation questions
On Thu, 18 Jan 2001, Hurf Sheldon wrote: Our amanda was set up by set up by someone who has moved on. Well now that would be me... 1: When we move the Overland to the FreeBSD PC and run amlabel, we get errors in the system log file and the DLT goes out to lunch - we setup an HP SureStore 2300 6 tape DDS as a test and saw some similar errors but after the tapes were labeled they subsided: (ch0:ahc0:0:0:1): MOVE MEDIUM. CDB: a5 20 0 0 0 3 0 1 0 0 0 0 (ch0:ahc0:0:0:1): ILLEGAL REQUEST asc:3b,d (ch0:ahc0:0:0:1): Medium destination element full ch: warning: could not map element source address 0d to a valid element type (sa0:ahc0:0:0:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state. Neither the FreeBSD list nor Overland has had any insight into this... Which FreeBSD list did you ask? Each has a different focus. Anyhow this one looks pretty obvious. "Move medium" means the changer received a command to move a tape, "Illegal request...Medium destination element full" means the destination of the move command, either a tape drive or a changer slot, already has a tape in it. What would cause this? Offhand I can think of a couple possibilities, though there may well be others I'm missing. 1) Changer scripts maintain knowledge (in a file) of a "current slot", which is which slot the currently loaded tape came from. If you're moving the changer back and forth between the HP-UX and FreeBSD machines you might be confusing the changer scripts if you're not putting the changer back in the same state it was in when it last came off that machine. Also if you move tapes around in the changer without using amtape commands this could cause the same sort of confusion. 2) Whatever changer script you're using may just not be sending the right commands. To debug this I think I would start at the lowest level of software you can, chio if that's what you're using, and make sure you can send commands to the changer and see it do the right thing in response. Once that works, move up a level to your changer script and do the same thing. Once that works move up to amtape. if the changer script is happy, amtape probably will be, too. 2: We can't directly access the NAS disks - how would we give dump instructions to a system that has it mounted via NFS or SMB? I thought Amanda used tar on Unix but a dump request to an Irix system with the NAS mounted failed "disk /remote/nas01/2 offline on nimble". A remote SMB mount can't be in turn shared so when trying to backup via smbclient we get: "PC SHARE //lassiter/N access error: host down or invalid password?" Amanda will use either dump or tar, whichever is specified in the dumptype you specify in the disklist for each filesystem. All the unix systems were using dump when I left. For the NAS you'll have to use tar. 3: How can we configure amanda to do only level 0 or only incremental backups? We'd like to (say) run level 0 over the weekend to one tape set and incrementals to another, with an eye to adding a second tape machine and do level 0 to one and incrementals to the other. David has already given you some ideas on this. I would just add that in deciding if you really want to do this, you should think carefully about what would be involved in performing a multi-level restore, and then ask yourself if you're really willing to live with that. If your daily run is taking too long I'd think about a few alternatives... a) upgrade the DLT 4000 to a DLT 8000, b) add more tapes to the tape rotation and increase dumpcycle so that level 0s are spread over a greater number of days. For the archive runs you're looking for I'd do that as a separate config with no-record, but I wouldn't eliminate the level 0s in the regular daily config. But that's just my preference. It's your call now of course. 3a: To use a second 15 tape magazine, is there a way to setup amanda.conf to count all 30 tapes sequentially? The problem seems to be that Amanda thinks there is 30 slots if there are 30 tapes, so the chio routines fail. We'd like to have it stop the tapers, ask for the next magazine and start at slot 1 again. I don't have experience with this type of setup yet, and it's been too long since I've looked at the code so I'm not sure what happens. What happens if the tape it wants isn't in the changer? Does it keep rotating through the changer until you stop it? Does it make one rotation and give up? As far as I can remember Amanda doesn't have a notion of magazines, so it doesn't know internally what the inventory of the changer is. This is knowledge that would have to be built into the changer script, which you could write or have a student tech to write. I wrote the one on the HP server and it didn't take very long. You could probably use that as a starting point. It should be pretty straightforward to rip out the "mc" commands and replace with chio commands. Then just have it check
Re: Never-ending dump
John R. Jackson wrote: I've been running an `amdump' for about 16 hours now -- the following dump (a level 0, as it happens) keeps happening over and over again. When I reach 100%, it starts again! Is this 2.4.2? If so, there's a known bug that we think is fixed in the latest CVS sources. If you can't or don't want to get them, there will be a 2.4.2p1 shortly, or ask me offline and I'll send you the patch. Will I only have to update my 2.4.2 installation on my Amanda server or will the clients need the new version too? -- [EMAIL PROTECTED] - HMC UNIX Systems Manager
Re: Never-ending dump
cmarble wrote: Is this 2.4.2? If so, there's a known bug that we think is fixed in the latest CVS sources. If you can't or don't want to get them, there will be a 2.4.2p1 shortly, or ask me offline and I'll send you the patch. Will I only have to update my 2.4.2 installation on my Amanda server or will the clients need the new version too? According to John, server only (thank goodness!) Ben
Re: Ejecting tapes
Ben Elliston wrote: Is there a way for Amanda to eject the tape at the end of a run so that I can simply remove it each day (and to indicate that the tape run has actually completed)? Or should I just run `mt offline' myself? Don't run "amdump ..." directly. Instead, write a script that calls amdump and after that does a "mt rewoffl" and whatever other stuff you like. Let cron, then, run this script. -- Regards Chris Karakas Dont waste your cpu time - crack rc5: http://www.distributed.net