Re: Can I use only one tape for backing up all the week?
Simon Mayr wrote: And hopefully the holding disk is not crashing at the same time as the backup client crashes. Maybe this is not exactly what you meant, but I will report it anyway, just to make clear what can happen in this world... I *never* put a tape (or the right tape for that matter ;-)) in the drive when AMANDA starts. This way I force all images to be copied to the holding disk and remain there till next day. After AMANDA finishes, a trivial script copies the files from the holding disk to an MO disk. I use as many MO disks as tapes for this purpose. They have roughly the same capacity too, which comes handy. When I run amflush next day, I will have the images on both the tape and the MO disk :-) Some days ago I started the usual daily amflush operation. In the middle of this, a power outage occured :-(((. What happens in this case is that some of the files in the holding disk have already been transfered to tape, so they are not on the holding disk any more. The tape, on the other side, did not have its headers updated (not the AMANDA headers, but its low level headers - on my system this is done at the end of the flushing, after the rewind command is issued), so the drive will not find the transfered files on it. The result was that all the transfered images were lost :-( My double net strategy saved me: I copied the images from the MO disk back to the holding disk and started amflush again :-) -- Regards Chris Karakas Dont waste your cpu time - crack rc5: http://www.distributed.net
Re: Linux, AIT2 and hardware compression
On Fri, 9 Feb 2001 at 10:36pm, Mitch Collinsworth wrote
mt status says the same thing no matter what I do with mt comp,
mt compression, mt setdensity, etc. And now I've tried with
mt 0.6, too. Strange.
That's right, there's no indication in the 'mt stat' line whether hardware
compression is on or off. But it seems to me that, with my AIT-1 drive,
'mt compression {0|1}' is the way to go. You can test it by writing
similar data to the tape in both compressed and uncompressed modes -- the
throughput should be significantly higher in compressed mode. Paul
Bijnens sent a Perl script to do just this to the list last week. Check
the archives under AIT-1 and tapetype.
--
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University
Re: Can I use only one tape for backing up all the week?
On Mon, 12 Feb 2001, Chris Karakas wrote: Some days ago I started the usual daily amflush operation. In the middle of this, a power outage occured :-(((. What happens in this case is that some of the files in the holding disk have already been transfered to tape, so they are not on the holding disk any more. The tape, on the other side, did not have its headers updated (not the AMANDA headers, but its low level headers - on my system this is done at the end of the flushing, after the rewind command is issued), so the drive will not find the transfered files on it. The result was that all the transfered images were lost :-( Huh?! Upon reading this I had two distinct reactions: 1) Whatever this device is, it sounds like it no longer conforms to the commonly accepted definition of a tape drive. Please tell us what it is so we can avoid buying one. I hope the manufacturer is honest enough to market it with a large warning label: "WARNING: This is not your grandfather's tape drive. Data loss may occur! Buyer beware, etc, etc" and 2) Are you sure about this? I.e. have you tried a dd against such a tape and really not been able to pull anything off it? Also, how exactly does your system update these low level headers? My double net strategy saved me: I copied the images from the MO disk back to the holding disk and started amflush again :-) Given you description of this "tape drive"'s operation I would say you are completely justified in not trusting it. YIKES!! -Mitch
AMRECOVER: NEED HELP!!!
Hi all.. I'm having a lot of troubles in restoring amanda backups... I have an HP's T20i Travan Tape in a Linux 2.2.14-5.0 kernel box... When I run: /usr/sbin/amrecover -C DailyBack -d /dev/nst0 I select the file I want to restore, I start the 'extract' command and I obtain: " ... Extracting files using tape drive /dev/nst0 on host localhost. The following tapes are needed: DailyBack109 Restoring files into directory /tmp/amanda Continue? [Y/n]: Y Load tape DailyBack109 now Continue? [Y/n]: Y EOF, check amidxtaped.debug file. amrecover: short block 0 bytes UNKNOWN file amrecover: Can't read file header extract_list - child returned non-zero status: 1 ..." The amidxtaped.debug says: " ... amidxtaped: debug 1 pid 25604 ruid 11 euid 11 start time Mon Feb 12 12:58:03 2001 amidxtaped: version 2.4.1p1 SECURITY USER root bsd security: remote host server.concept user root local user operator amandahosts security check passed 6 amrestore_nargs=6 -h -p /dev/nst0 localhost ^sda1$ 20010210 Ready to execv amrestore with: path = /usr/sbin/amrestore argv[0] = "amrestore" argv[1] = "-h" argv[2] = "-p" argv[3] = "/dev/nst0" argv[4] = "localhost" argv[5] = "^sda1$" argv[6] = "20010210" amrestore: 0: skipping start of tape: date 20010210 label DailyBack109 amrestore: 1: skipping aqua._mnt_raid_devel.20010210.1 amrestore: fast-forward: Errore di input/output amidxtaped: amrestore terminated normally with status: 2 Rewinding tape: done amidxtaped: pid 25604 finish time Mon Feb 12 12:58:18 2001 ... " Can you help me ? Thanks in advance!! Carlo Alberto
amrecover
Hi all.. when I run: amrecover -C test -d /dev/rmt/1lbn amrecoversetdisk //gbprr2/test amrecoveradd * . Added /. Added /... amrecoversetmode smb SAMBA dumps will be extracted using smbclient amrecoverextract Extracting files using tape drive /dev/rmt/1lbn on host gbsun1. The following tapes are needed: test-01 Restoring files into directory /tmp/amanda (unless it is a Samba backup, that will go through to the SMB server) Continue? [Y/n]: y Load tape test-01 now Continue? [Y/n]: amrecover NO FILES ARE RESTORED The amidxtaped.debug says: amidxtaped: debug 1 pid 7152 ruid 0 euid 0 start time Mon Feb 12 15:36:51 2001 amidxtaped: version 2.4.2 SECURITY USER root bsd security: remote host gbsun1 user root local user root bsd security check to root from root@gbsun1 passed 6 amrestore_nargs=6 -h -p /dev/rmt/1lbn gbsun1 ^//gbprr4/test$ 20010212 Ready to execv amrestore with: path = /usr/local/sbin/amrestore argv[0] = "amrestore" argv[1] = "-h" argv[2] = "-p" argv[3] = "/dev/rmt/1lbn" argv[4] = "gbsun1" argv[5] = "^//gbprr4/test$" argv[6] = "20010212" amrestore: 0: skipping start of tape: date 20010212 label test-01 amrestore: 1: restoring gbsun1.__gbprr4_test.20010212.0 Error 32 (Broken pipe) offset 32768+32768, wrote 0 amrestore: pipe reader has quit in middle of file. amrestore: skipping ahead to start of next file, please wait... amidxtaped: amrestore terminated normally with status: 2 Rewinding tape: done amidxtaped: pid 7152 finish time Mon Feb 12 15:37:02 2001 The amidxtaped.debug says: Can you help me ? Thanks in advance!! Mit freundlichen Gr|_en ___ Robert PirontInstitut fuer Elektrische Tel.: +49-241-807660 Anlagen und Energiewirtschaft +49-241-25102 RWTH-Aachen Fax.: +49-241-197Schinkelstrasse 6 mailto:[EMAIL PROTECTED]D-52056 Aachen http://www.iaew.rwth-aachen.de/home/pi
toner supplies
PLEASE FORWARD TO THE PERSON RESPONSIBLE FOR PURCHASING YOUR LASER PRINTER SUPPLIES VORTEX SUPPLIES -SPECIALS OF THE DAY ON LASER TONER SUPPLIES AT DISCOUNT PRICES-- LASER PRINTER TONER CARTRIDGES COPIER AND FAX CARTRIDGES WE ARE --THE-- PLACE TO BUY YOUR TONER CARTRIDGES BECAUSE YOU SAVE UP TO 30% FROM OFFICE DEPOT'S, QUILL'S OR OFFICE MAX'S EVERY DAY LOW PRICES ORDER BY PHONE:1-888-288-9043 ORDER BY FAX: 1-888-977-1577 CUSTOMER SERVICE: 1-888-248-2015 E-MAIL REMOVAL LINE: 1-888-248-4930 UNIVERSITY AND/OR SCHOOL PURCHASE ORDERS WELCOME. (NO CREDIT APPROVAL REQUIRED) ALL OTHER PURCHASE ORDER REQUESTS REQUIRE CREDIT APPROVAL. PAY BY CHECK (C.O.D), CREDIT CARD OR PURCHASE ORDER (NET 30 DAYS). IF YOUR ORDER IS BY CREDIT CARD PLEASE LEAVE YOUR CREDIT CARD # PLUS EXPIRATION DATE. IF YOUR ORDER IS BY PURCHASE ORDER LEAVE YOUR SHIPPING/BILLING ADDRESSES AND YOUR P.O. NUMBER NO SHIPPING CHARGES FOR ORDERS $49 OR OVER ADD $4.75 FOR ORDERS UNDER $49. C.O.D. ORDERS ADD $4.5 TO SHIPPING CHARGES. FOR THOSE OF YOU WHO REQUIRE MORE INFORMATION ABOUT OUR COMPANY INCUDING FEDERAL TAX ID NUMBER, CLOSEST SHIPPING OR CORPORATE ADDRESS IN THE CONTINENTAL U.S. OR FOR CATALOG REQUESTS PLEASE CALL OUR CUSTOMER SERVICE LINE 1-888-248-2015 OUR NEW, LASER PRINTER TONER CARTRIDGE, PRICiES ARE AS FOLLOWS: (PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER) HEWLETT PACKARD: (ON PAGE 2) ITEM #1 LASERJET SERIES 4L,4P (74A)$44 ITEM #2 LASERJET SERIES 1100 (92A)-$44 ITEM #3 LASERJET SERIES 2 (95A)---$39 ITEM #4 LASERJET SERIES 2P (75A)-$54 ITEM #5 LASERJET SERIES 5P,6P,5MP, 6MP (3903A)--$44 ITEM #6 LASERJET SERIES 5SI, 5000 (29A)--$95 ITEM #7 LASERJET SERIES 2100 (96A)-$74 ITEM #8 LASERJET SERIES 8100 (82X)---$145 ITEM #9 LASERJET SERIES 5L/6L (3906A0--$35 ITEM #10 LASERJET SERIES 4V-$95 ITEM #11 LASERJET SERIES 4000 (27X)-$72 ITEM #12 LASERJET SERIES 3SI/4SI (91A)$54 ITEM #13 LASERJET SERIES 4, 4M, 5,5M---$49 HEWLETT PACKARD FAX (ON PAGE 2) ITEM #14 LASERFAX 500, 700 (FX1)--$49 ITEM #15 LASERFAX 5000,7000 (FX2)--$54 ITEM #16 LASERFAX (FX3)$59 ITEM #17 LASERFAX (FX4)$54 LEXMARK/IBM (ON PAGE 3) OPTRA 4019, 4029 HIGH YIELD---$89 OPTRA R, 4039, 4049 HIGH YIELD-$105 OPTRA E$59 OPTRA N--$115 OPTRA S--$165 - EPSON (ON PAGE 4) ACTION LASER 7000,7500,8000,9000---$105 ACTION LASER 1000,1500-$105 CANON PRINTERS (ON PAGE 5) PLEASE CALL FOR MODELS AND UPDATED PRICES FOR CANON PRINTER CARTRIDGES PANASONIC (0N PAGE 7) NEC SERIES 2 MODELS 90 AND 95--$105 APPLE (0N PAGE 8) LASER WRITER PRO 600 or 16/600$49 LASER WRITER SELECT 300,320,360-$74 LASER WRITER 300 AND 320--$54 LASER WRITER NT, 2NT--$54 LASER WRITER 12/640$79 CANON FAX (ON PAGE 9) LASERCLASS 4000 (FX3)---$59 LASERCLASS 5000,6000,7000 (FX2)-$54 LASERFAX 5000,7000 (FX2)--$54 LASERFAX 8500,9000 (FX4)--$54 CANON COPIERS (PAGE 10) PC 3, 6RE, 7 AND 11 (A30)-$69 PC 300,320,700,720 and 760 (E-40)$89 IF YOUR CARTRIDGE IS NOT LISTED CALL CUSTOMER SERVICE AT 1-888-248-2015 90 DAY UNLIMITED WARRANTY INCLUDED ON ALL PRODUCTS. ALL TRADEMARKS AND BRAND NAMES LISTED ABOVE ARE PROPERTY OF THE RESPECTIVE HOLDERS AND USED FOR DESCRIPTIVE PURPOSES ONLY.
Re: problems with faq-o-matic
On Feb 12, 2001, Joseph Del Corso [EMAIL PROTECTED] wrote:
print on closed filehandle FAQ::OMatic::ERRORFILE at
/home/groups/amanda/fom/lib/perl5/site_perl/5.005/FAQ/OMatic.pm line 224.
Yep. Sourceforge folks screwed up our installation of FOM. We've
already asked them to fix it a few days ago, but no news so far :-(
http://sourceforge.net/support/?func=detailsupportsupport_id=113868group_id=1
Meanwhile, this alternate URL will at least let you browse the
existing entries: http://www.amanda.org/fom-serve/cache/1.html
I'll add it to our web pages.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
strange dumper error
Admins et al, After searching for a coupla days through the archives with limited success I resort to a direct problem request: I am running a 6 machine Linux cluster on Red Hat 6.2, I am using Amanda 2.4.1p1 and backing all machines up to one using dump. I had been successfully dumping and restoring, as required, several filesystems off each machine when one day three of the 4 filesystems on one machine refused to be dumped and basically hung the dumper process. Three weeks ago one of the other machines demonstrated similar symptoms, after a reboot, when one of it's two filesystems refused to dump. I have had to remove these filesystems from disklist to allow the other filesystems to be backed up. I have tried to run these filesystem backups individually and to another backup system I have running under Tru64, with the same results. Amcheck reports no errors. Here is an extract from the log that may offer some clues: STRANGE dumper servername /usr/local 0 [sec 50316.841 kb 70336 kps 1.4 orig-kb 0] sendbackup: start [servername:/usr/local 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: Sun Feb 11 18:56:58 2001 | DUMP: Date of last level 0 dump: the epoch | DUMP: Dumping /dev/hda6 (/usr/local) to standard output | DUMP: Label: none | DUMP: mapping (Pass I) [regular files] | DUMP: mapping (Pass II) [directories] | DUMP: estimated 222184 tape blocks. | DUMP: Volume 1 started at: Sun Feb 11 18:56:59 2001 | DUMP: dumping (Pass III) [directories] | DUMP: dumping (Pass IV) [regular files] | DUMP: 1.30% done, finished in 9:17 | DUMP: 2.16% done, finished in 10:06 | DUMP: 3.22% done, finished in 12:24..etc, this continued on until I killed the process several hrs later. And from amdump for the same run (note the file to large message(?)) driver: send-cmd time 27.966 to dumper1: FILE-DUMP 01-2 /usr/var/amanda_3/20 010205/lvsp._usr_local.0 lvsp /usr/local 0 1970:1:1:0:0:0 -2097087 DUMP |;bsd-au th;compress-fast; driver: state time 27.966 free kps: 2140 space: 1628268 taper: idle idle-dumpers : 8 qlen tapeq: 0 runq: 3 stoppedq: 0 wakeup: 86400 driver-idle: file-too-large driver: interface-state time 27.966 if : free 540 if LE0: free 1 if LOCAL: f ree 1 driver: hdisk-state time 27.966 hdisk 0: free 1628268 dumpers 2 driver: result time 460.329 from dumper0: DONE 00-1 2748 1728 432 [sec 432.2 12 kb 1728 kps 4.0 orig-kb 2748] Although I have been using Amanda for some time, this is my first go at this list, so please let me know if more info can help resolve this problem. Thanks in advance. John Gormley Senior Unix Systems Administrator Southern Cross University Lismore NSW Australia. [EMAIL PROTECTED]
Re: strange dumper error
On Feb 13, 2001, John Peter Gormley [EMAIL PROTECTED] wrote:
I am running a 6 machine Linux cluster on Red Hat 6.2, I am using Amanda
2.4.1p1 and backing all machines up to one using dump.
Which version of DUMP? The one that shipped with Red Hat Linux 6.2
was pretty much un-maintained and riddled with bugs. Get a recent
dump release from dump.sourceforge.net and give it a try. `fsck'ing
the filesystem *might* help, too.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
