Another question about Encryption with Amanda
I have amanda installed and working but now I am trying to set up encryption. I am using v2.5.2p1 on a Sun server running Solaris 9. I have followed the instructions from the URL: http://wiki.zmanda.com/index.php/How_To:Set_up_data_encryption I got it all set up and the key created but now I get the error: FAILURE AND STRANGE DUMP SUMMARY: server.simpson.edu /export/home/pdc/Patches lev 0 FAILED [missing result for /export/home/pdc/Patches in server.simpson.edu response] I can back this up not using the encryption but it fails when I try to encrypt. I have looked at all of the logs and none of them seem to tell me what response it is missing. Has anyone else gotten this to work or have any suggestions? Thanks, Paul Crittenden Computer Systems Manager Simpson College Phone: 515-961-1680, Email: [EMAIL PROTECTED] image001.gif
(yet another) question along steps of getting operational...
Hi folks For those that remember, I had trouble getting my drive array (a exabyte X80) recognized. Now I have the X80 working, I have read stuff on/off the drive, I even have installed the following software: package version gnuawk3.10 gccCompiler 3.3 gnuplot 3.71 make 3.80 mtx 1.2.17 ncurses 5.3. perl 5.8.0 popt 1.7 readline 4.3 samba 2.2.8a tar 1.13 and of course amanda 2.4.4p1 BUT I still haven't figured out how to refer to my robot!?... (duh. running solaris 5.8) I dont see a device in /dev/rmt... (but I see the drives there...) Anyone give me a hint where the X80/X200/X220 robot might put itself when being built? Mitch
Re: (yet another) question along steps of getting operational...
[Mailed and Cc'ed] On Wed, Jul 09, 2003 at 01:37:16PM -0500, Bruntel, Mitchell L, SOLCM wrote: mtx 1.2.17 BUT I still haven't figured out how to refer to my robot!?... (duh. running solaris 5.8) I dont see a device in /dev/rmt... (but I see the drives there...) For Solaris 8 and mtx, you want to try the sgen(7D) driver for your robot first. You put appropriate entries in /kernel/drv/sgen.conf (it is commented empty by default, so you *have* no devices for it yet), do an 'add_drv sgen' and you should get device entries in /dev/scsi/changer. The sgen.conf device-type for library robots is changer. In the mtx source distribution, see contrib/config_sgen_solaris.sh. Don't run the script (in any case, there's a CVS command in it that will fail), use it as an example/template. -- Jay Lessert [EMAIL PROTECTED] Accelerant Networks Inc. (voice)1.503.439.3461 Beaverton OR, USA(fax)1.503.466.9472
Re: (yet another) question along steps of getting operational...
On Wed, Jul 09, 2003 at 11:59:23AM -0700, Jay Lessert wrote: [Mailed and Cc'ed] On Wed, Jul 09, 2003 at 01:37:16PM -0500, Bruntel, Mitchell L, SOLCM wrote: mtx 1.2.17 BUT I still haven't figured out how to refer to my robot!?... (duh. running solaris 5.8) I dont see a device in /dev/rmt... (but I see the drives there...) For Solaris 8 and mtx, you want to try the sgen(7D) driver for your robot first. You put appropriate entries in /kernel/drv/sgen.conf (it is commented empty by default, so you *have* no devices for it yet), do an 'add_drv sgen' and you should get device entries in /dev/scsi/changer. The sgen.conf device-type for library robots is changer. Mine showed up in /dev/scsi/sequential rather than changer. You might also edit st.conf to examine other lun's besides 0 (only 0 is scanned in the default file). My drive also adds /dev/rmt devices for the changer at higher lun numbers but the same scsi id. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: (yet another) question along steps of getting operational...
On Wed, Jul 09, 2003 at 03:31:13PM -0400, Jon LaBadie wrote: On Wed, Jul 09, 2003 at 11:59:23AM -0700, Jay Lessert wrote: You put appropriate entries in /kernel/drv/sgen.conf (it is commented empty by default, so you *have* no devices for it yet), do an 'add_drv sgen' and you should get device entries in /dev/scsi/changer. The sgen.conf device-type for library robots is changer. Mine showed up in /dev/scsi/sequential rather than changer. That might be, and I'm sure it works, but sequential is sgen-ese for tape drive. I guess your sgen.conf device-type-config-list has sequential instead of or in addition to changer? Even then, it's sort of strange if the robot is returning sequential (0x01) for an inquiry type ID, instead of changer (0x08), but... Anyway, changer is sgen-ese for media library robot. You might also edit st.conf to examine other lun's besides 0 (only 0 is scanned in the default file). Yup, in any case, you can't do diddly if you don't know the target and LUN setting for each device on the bus. -- Jay Lessert [EMAIL PROTECTED] Accelerant Networks Inc. (voice)1.503.439.3461 Beaverton OR, USA(fax)1.503.466.9472
Re: (yet another) question along steps of getting operational...
Bruntel, Mitchell L, SOLCM wrote: tar 1.13 That one contains known bugs, especially some that will bite you at restore time. Before going production you better install tar 1.13.25 get it from: ftp://alpha.gnu.org/gnu/tar/tar-1.13.25.tar.gz
Another Question
Nobody answered my last question on reading indices, but I
eventually determined that the tapelist file had become corrupt, which
got me four weeks' worth of indices that I hadn't had before!
Anyway, today my problem is that amflush is failing. I forgot
to change a tape last night, and dumps happened to the holding disk --
no problem there. I tried to run amflush, though, and it failed on
several filesystems. I am guessing it's a failure of the files on the
holding disk instead of the tape (as the tape does have good data!).
What can cause this sort of thing?
Here's the amflush report:
The dumps were flushed to tape DailySet159.
The next tape Amanda expects to use is: a new tape.
FAILURE AND STRANGE DUMP SUMMARY:
bertha /usr2 lev 1 FAILED [input: Can't read data: : Input/output error]
us /export/home/us0 lev 3 FAILED [input: Can't read data: :
+Input/output error]
us /export/home/us1 lev 4 FAILED [input: Can't read data: :
+Input/output error]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:00
Run Time (hrs:min) 0:14
Dump Time (hrs:min)0:00 0:00 0:00
Output Size (meg) 0.00.00.0
Original Size (meg) 0.00.00.0
Avg Compressed Size (%) -- -- --
Filesystems Dumped0 0 0
Avg Dump Rate (k/s) -- -- --
Tape Time (hrs:min)0:13 0:00 0:13
Tape Size (meg) 2198.90.0 2198.9
Tape Used (%) 16.10.0 16.1 (level:#disks ...)
Filesystems Taped 2 0 2 (1:1 2:1)
Avg Tp Write Rate (k/s) 2873.5-- 2873.5
^L
NOTES:
amflush: /home/amanda/20010829/bertha._usr2.1: taper error, leaving file on disk
amflush: /home/amanda/20010829/us._export_home_us0.3: taper error, leaving file on
disk
amflush: /home/amanda/20010829/us._export_home_us1.4: taper error, leaving file on
disk
amflush: Could not rmdir /home/amanda/20010829. Check for cruft.
taper: tape DailySet159 kb 2292256 fm 5 [OK]
^L
DUMP SUMMARY:
DUMPER STATSTAPER STATS
HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
-- -
bertha /usr2 1 FAILED ---
us -t/home/us0 3 FAILED ---
us -t/home/us1 4 FAILED ---
us -t/home/us2 2 27876472240032 80.4 N/A N/A 12:582880.9
us /var/mail 1 43807 11648 26.6 N/A N/A0:061930.9
(brought to you by Amanda version 2.4.2p2)
Any response would be appreciated.
-- Lorrie
Re: Another Question
On Wed, 29 Aug 2001 at 1:57pm, Lorrie Wood wrote no problem there. I tried to run amflush, though, and it failed on several filesystems. I am guessing it's a failure of the files on the holding disk instead of the tape (as the tape does have good data!). Don't be so sure... FAILURE AND STRANGE DUMP SUMMARY: bertha /usr2 lev 1 FAILED [input: Can't read data: : Input/output error] us /export/home/us0 lev 3 FAILED [input: Can't read data: : +Input/output error] us /export/home/us1 lev 4 FAILED [input: Can't read data: : +Input/output error] *snip* NOTES: amflush: /home/amanda/20010829/bertha._usr2.1: taper error, leaving file on disk amflush: /home/amanda/20010829/us._export_home_us0.3: taper error, leaving file on disk amflush: /home/amanda/20010829/us._export_home_us1.4: taper error, leaving file on disk amflush: Could not rmdir /home/amanda/20010829. Check for cruft. taper: tape DailySet159 kb 2292256 fm 5 [OK] taper ran into an Input/output error trying to put those disk images onto tape. In reality, taper is just telling you what the OS told it. Check your system logs for related messages -- they should tell you what type of Input/output error occurred. I've seen old tape drives/tapes/combos thereof which will write random amounts of data (sometimes a whole night's worth, sometimes not) before giving such errors. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Another Question
On Wed, Aug 29, 2001 at 06:04:51PM -0400, Joshua Baker-LePain wrote: On Wed, 29 Aug 2001 at 1:57pm, Lorrie Wood wrote no problem there. I tried to run amflush, though, and it failed on several filesystems. I am guessing it's a failure of the files on the holding disk instead of the tape (as the tape does have good data!). Don't be so sure... But I do restores from amanda stuff all the time -- the last two I/O errors were in flush reports, not dump reports. Hm. taper ran into an Input/output error trying to put those disk images onto tape. In reality, taper is just telling you what the OS told it. Check your system logs for related messages -- they should tell you what type of Input/output error occurred. I don't see it in the logs of either the server or the client. Moreover, an error *reading* data would seem to point to the dump file, wouldn't it? I've seen old tape drives/tapes/combos thereof which will write random amounts of data (sometimes a whole night's worth, sometimes not) before giving such errors. But it backs up (and restores!) consistently -- the only problem is whenit has to dump to disk, and I have to flush from disk. I care about this, as I'll soon be doing some large dumps on Friday nights, which will have to be held there until I get in Monday morning, and, well, they won't be any good to me if they're corrupt... -- Lorrie
Re: Another Question
Check your system logs. If you think there's an I/O error reading the dump file, I'd suggest dd if=/your/dump/file of=/dev/null which should elicit a similar error while trying to read your whole file. I'd also suggest your favorite disk utility. On Linux that'd be badblocks which can be asked to read every block on a partition, counting which ones it runs into difficulty with. I'd expect most Unix-like OSs have some such utility. If you confirm disk errors on your dump disk, run don't walk to your hard drive vendor for a new hard drive. Your data is no doubt worth a whole lot more than you'd pay for a hard drive!! On Wed, Aug 29, 2001 at 03:23:49PM -0700, Lorrie Wood wrote: On Wed, Aug 29, 2001 at 06:04:51PM -0400, Joshua Baker-LePain wrote: On Wed, 29 Aug 2001 at 1:57pm, Lorrie Wood wrote no problem there. I tried to run amflush, though, and it failed on several filesystems. I am guessing it's a failure of the files on the holding disk instead of the tape (as the tape does have good data!). Don't be so sure... But I do restores from amanda stuff all the time -- the last two I/O errors were in flush reports, not dump reports. Hm. taper ran into an Input/output error trying to put those disk images onto tape. In reality, taper is just telling you what the OS told it. Check your system logs for related messages -- they should tell you what type of Input/output error occurred. I don't see it in the logs of either the server or the client. Moreover, an error *reading* data would seem to point to the dump file, wouldn't it? I've seen old tape drives/tapes/combos thereof which will write random amounts of data (sometimes a whole night's worth, sometimes not) before giving such errors. But it backs up (and restores!) consistently -- the only problem is whenit has to dump to disk, and I have to flush from disk. I care about this, as I'll soon be doing some large dumps on Friday nights, which will have to be held there until I get in Monday morning, and, well, they won't be any good to me if they're corrupt... -- Lorrie -- Dan Wilder
Re: Another Question
Hello, [EMAIL PROTECTED] said: [...] Anyway, today my problem is that amflush is failing. I forgot to change a tape last night, and dumps happened to the holding disk -- no problem there. I tried to run amflush, though, and it failed on several filesystems. I am guessing it's a failure of the files on the holding disk instead of the tape (as the tape does have good data!). What can cause this sort of thing? I had some similar trouble once when my holding disk went bad. You might try reading each file from the disk in its entirety. For example: dd if=/home/amanda/20010829/bertha._usr2.1 of=/dev/null bs=32k Check that the records in/out that dd reports matches the file size. If that works for all of the images and dd doesn't report any IO errors, then I guess the tape is what's left to look at. You might try running amflush again onto a different tape. -Ben -- Benjamin LewisThank goodness modern convenience is a Database Analyst/Programmer thing of the remote future. Purdue University Computing Center -- Pogo, by Walt Kelly [EMAIL PROTECTED]
Another question...
I am not sure what to make of this. Do I need some form of SSL server running? Amanda Backup Client Hosts Check ERROR: localhost: [host localhost: port 3201 not secure] ERROR: plath.knox.net: [host plath.knox.net: port 3201 not secure] Client check: 2 hosts checked in 1.104 seconds, 2 problems found. (brought to you by Amanda 2.4.1p1) If anyone has any advice it would be much appreciated. Thanks again. Isaac
Re: Another question...
I am not sure what to make of this. Do I need some form of SSL server running? ERROR: localhost: [host localhost: port 3201 not secure] No, you just need to install Amanda properly. Several of the Amanda programs are setuid-root to be able to get privileged ports. You've probably lost that. The easiest way to fix the problem is "make install" again as root. Here's what you should end up with (your group may be different): -rwsr-x--- 1 root backup287220 Feb 4 18:46 libexec/calcsize -rwsr-x--- 1 root backup860624 Feb 4 17:02 libexec/dumper -rwsr-x--- 1 root backup239124 Feb 4 18:46 libexec/killpgrp -rwsr-x--- 1 root backup 1015976 Feb 4 17:02 libexec/planner -rwsr-x--- 1 root backup236404 Feb 4 18:46 libexec/rundump -rwsr-x--- 1 root backup237412 Feb 4 18:46 libexec/runtar -rwsr-x--- 1 root backup 1028616 Feb 4 17:02 sbin/amcheck Isaac John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Sorry, another question -- eject
I'm also curious if there is a way to get around a problem I seem to have every now and then. Specifically, I can issue the mtx -f /dev/sg4 eject (sg4 being the first tape drive) and I will randomly get an error like this: [operator@lycan:/usr/local/etc/amanda/DailySet1]# mtx -f /dev/sg4 eject mtx:eject failed Now I can simply submit the eject command again and it will work, but I'm worried about trying to automate anything now because I'm not sure if I'll have problems with the eject command. Any thoughts? Joe
Re: Sorry, another question -- eject
This is from the FAQ that comes with mtx. It looks like the eject is for ejecting magazines from certain autoloaders, not tapes from drives. May be why it's only working some of the time. Does 'mtx -f /dev/sg4 unload slotnumber drive number' work? 8- Q: How do I eject the magazine of my autoloader? A: Many low-end DAT autoloaders support the removable media 'EJECT' command sent to the robotics device, even though it's not documented (or required) in the SCSI standards. If the loader is at /dev/sgb, simply do 'mtx -f /dev/sgb eject' and see what happens. (If nothing happens, your autoloader doesn't support 'eject'). Some high-end libraries have their own proprietary way for ejecting magazine trays, generally involving abuse of the 'transfer' command and 'eepos' addendums, but this is totally non-standard and undocumented. On Thu, 15 Feb 2001, Joseph Del Corso wrote: I'm also curious if there is a way to get around a problem I seem to have every now and then. Specifically, I can issue the mtx -f /dev/sg4 eject (sg4 being the first tape drive) and I will randomly get an error like this: [operator@lycan:/usr/local/etc/amanda/DailySet1]# mtx -f /dev/sg4 eject mtx:eject failed Now I can simply submit the eject command again and it will work, but I'm worried about trying to automate anything now because I'm not sure if I'll have problems with the eject command. Any thoughts? Joe -- Jason Hollinden SMG Systems Admin
