Re: Dramatic reduction in backup time
I'm running amanda on Red Hat Enterprise 3. I'm a bit new to Linux, but will try and investigate dmesg as you suggested. Otherwise, thanks very much for all your input and help. I'll see how it goes from here on. At least now I know what the probable cause is. Thanks. Michael Loftis wrote: --On August 3, 2006 9:05:03 AM -0700 Joe Donner (sent by Nabble.com) [EMAIL PROTECTED] wrote: Yes, it's the exact same tape drive I've been using extensively for testing, and all that time it had been sitting in the same position on the floor. I moved it on Monday, and then amanda took off like a lightning bolt. Wow, that's something I'll be classing as very weird, but very good. I was impressed by the 9 hours it took to do backups, but now I'm speechless... I've introduced a new tape for tonight's backup run. Will see what it tells me tomorrow. Thanks very much for your help! Yeah it sounds VERY much like a marginal SCSI cablewhat OS do you have? Sometimes termination issues will show up in dmesg, also dmesg will usually show the speed at which the device negotiatesit is shown elsewhere too depending on your OS. -- View this message in context: http://www.nabble.com/Dramatic-reduction-in-backup-time-tf2044425.html#a5646615 Sent from the Amanda - Users forum at Nabble.com.
Re: can only run amanda tests as root
Gene Heskett [EMAIL PROTECTED] 08/02/06 12:09 PM Then you don't have your amanda user in the correct group, amanda should be a member of the group disk in your case. This walks and quacks like the incorrect installation duck, amanda should be configured and built by the user amanda (or whoever is actually going to run amanda, and NOT root) and this user should be a member of the group that includes disk and backup. However, after amanda has been built by this user, then amanda must be installed by root, thereby setting up all these permissions and setuids automaticly. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :- ) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. I installed Amanda via rpm and it's been around in SuSE for a long time, so I would expect someone to have picked up this 'basic' problem and fixed it since SuSE 9.3 up to SLES 10 if it were an amanda compile / install issue (I tried this on SuSE 9.3, 10, 10.1, SLES9 10). The permissions are correct for the amanda user, and amanda's default group is the disk group. The problem is that the disk group has, by default, only read access to changer devices (/dev/sg*) in SuSE that are created dynamically during boot. The perms assigned are governed by rules in udev, which I pointed out. For what it's worth, all no changer tape devices (e.g. /dev/nst*) do give the disk group read and write perms by default so no problem there... it's only an issue if you are using a changer with SuSE (or CentOS apparently) Stephen Carter Retrac Networking Limited www: http://www.retnet.co.uk Ph: +44 (0)7870 218 693 Fax: +44 (0)870 7060 056 CNA, CNE 6, CNS, CCNA, MCSE 2003
Re: can only run amanda tests as root
On 2006-08-04 10:31, Stephen Carter wrote: I installed Amanda via rpm and it's been around in SuSE for a long time, so I would expect someone to have picked up this 'basic' problem and fixed it since SuSE 9.3 up to SLES 10 if it were an amanda compile / install issue (I tried this on SuSE 9.3, 10, 10.1, SLES9 10). The permissions are correct for the amanda user, and amanda's default group is the disk group. The problem is that the disk group has, by default, only read access to changer devices (/dev/sg*) in SuSE that are created dynamically during boot. The perms assigned are governed by rules in udev, which I pointed out. For what it's worth, all no changer tape devices (e.g. /dev/nst*) do give the disk group read and write perms by default so no problem there... it's only an issue if you are using a changer with SuSE (or CentOS apparently) CentOS??? I run CentOS 4.3, and in my /etc/udev/permissions.d/50-udev.permissions I find: [...] # disk devices hd*:root:disk:0660 sd*:root:disk:0660 [...] # tape devices [...] st*:root:disk:0660 nst*:root:disk:0660 [...] # scsi devices sg*:root:disk:0660 So, all seems fine here. -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... Are you sure? ... YES ... Phew ... I'm out * ***
Re: can only run amanda tests as root
Paul Bijnens [EMAIL PROTECTED] 08/04/06 10:24 AM CentOS??? snip So, all seems fine here. -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B- 3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] There was an earlier reply to this thread that suggested another user had this problem running CentOS, but maybe he has another issue instead. Stephen Carter Retrac Networking Limited www: http://www.retnet.co.uk Ph: +44 (0)7870 218 693 Fax: +44 (0)870 7060 056 CNA, CNE 6, CNS, CCNA, MCSE 2003
Re: can only run amanda tests as root
On Friday 04 August 2006 04:31, Stephen Carter wrote: Gene Heskett [EMAIL PROTECTED] 08/02/06 12:09 PM Then you don't have your amanda user in the correct group, amanda should be a member of the group disk in your case. This walks and quacks like the incorrect installation duck, amanda should be configured and built by the user amanda (or whoever is actually going to run amanda, and NOT root) and this user should be a member of the group that includes disk and backup. However, after amanda has been built by this user, then amanda must be installed by root, thereby setting up all these permissions and setuids automaticly. I installed Amanda via rpm and it's been around in SuSE for a long time, so I would expect someone to have picked up this 'basic' problem and fixed it since SuSE 9.3 up to SLES 10 if it were an amanda compile / install issue (I tried this on SuSE 9.3, 10, 10.1, SLES9 10). The permissions are correct for the amanda user, and amanda's default group is the disk group. The problem is that the disk group has, by default, only read access to changer devices (/dev/sg*) in SuSE that are created dynamically during boot. The perms assigned are governed by rules in udev, which I pointed out. For what it's worth, all no changer tape devices (e.g. /dev/nst*) do give the disk group read and write perms by default so no problem there... it's only an issue if you are using a changer with SuSE (or CentOS apparently) This is a frequent problem when using a 'packaged' version of amanda. The rpm packagers in particular have demonstrated many times that they do not understand how amanda treats security issues. Amanda's build gives it enough perms to do the instant job each piece needs to do, and no more. This is why, when potential users run into these sort of problems, that we universally recommend that it be built from the tarball, following amanda's instructions so that the amanda build and install can be done correctly. As for the udev permissions problem, I haven't used it yet (FC2 and RH7.3 boxes here) so I cannot advise on the exact fix, but I'm told there is a .conf file that controls this, and that it can be edited to fix the changer perms. If the local build is not an option, then one should file a bugzilla entry against the specific package(s) at Suse. I would include udev as the root of the problem in this case. Stephen Carter Retrac Networking Limited www: http://www.retnet.co.uk Ph: +44 (0)7870 218 693 Fax: +44 (0)870 7060 056 CNA, CNE 6, CNS, CCNA, MCSE 2003 -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Backup device for Amanda
Hi All, I am trying to figure out a proper backup strategy for our setup, using Amanda as the backup tool. We have roughly 20 Linux/Windows dual-boot machines and one file server with "Red Hat Enterprise Linux ES release 3" as the OS. To keep the backup procedure simple, we plan to keep all the "critical" data on this file server and only back up the data directories on this file server (No other machine would be backed up). The data to be backed up is currently roughly 100GB and may increase to more than 250GB in the next one year. I am trying to identify the proper backup devices/media for this requirement. The backup devices I am evaluating are 1. HP Ultrium 448 Tape Drive 2. HP DLT VS160 Tape Drive 3. HP SDLT 320 4. HP SDLT 600 I would like to know whether these backup devices are fully compatible with Amanda. Does anybody on this list use these backup devices in his/her setup ? Suggestions for any other suitable backup device are also welcome. Thanks In Advance Yogesh Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta.
Re: can only run amanda tests as root
On Friday 04 August 2006 05:24, Paul Bijnens wrote:
On 2006-08-04 10:31, Stephen Carter wrote:
I installed Amanda via rpm and it's been around in SuSE for a long
time, so I would expect someone to have picked up this 'basic'
problem and fixed it since SuSE 9.3 up to SLES 10 if it were an
amanda compile / install issue (I tried this on SuSE 9.3, 10, 10.1,
SLES9 10). The permissions are correct for the amanda user, and
amanda's default group is the disk group.
The problem is that the disk group has, by default, only read access
to changer devices (/dev/sg*) in SuSE that are created dynamically
during boot. The perms assigned are governed by rules in udev, which
I pointed out.
For what it's worth, all no changer tape devices (e.g. /dev/nst*) do
give the disk group read and write perms by default so no problem
there... it's only an issue if you are using a changer with SuSE (or
CentOS apparently)
CentOS???
I run CentOS 4.3, and in my /etc/udev/permissions.d/50-udev.permissions
I find:
[...]
# disk devices
hd*:root:disk:0660
sd*:root:disk:0660
[...]
# tape devices
[...]
st*:root:disk:0660
nst*:root:disk:0660
[...]
# scsi devices
sg*:root:disk:0660
So, all seems fine here.
This is not the same format as is contained in this file on my FC5 lappy,
but in all cases of a changer or a scanner assigned to a /dev/sg#, the
perms assigned appear to be root:disk and 0660. From that file:
===
# sd: 0 TYPE_DISK, 7 TYPE_MOD, 14 TYPE_RBC
# sr: 4 TYPE_WORM, 5 TYPE_ROM
# st/osst: 1 TYPE_TAPE
# sg: 8 changer, [36] scanner
ACTION==add, SUBSYSTEM=scsi , SYSFS{type}==0|7|14, \
RUN+=/bin/sh -c 'echo 60 /sys$$DEVPATH/timeout'
ACTION==add, SUBSYSTEM=scsi , SYSFS{type}==1, \
RUN+=/bin/sh -c 'echo 900 /sys$$DEVPATH/timeout'
ACTION==add, SUBSYSTEM==scsi_device RUN+=/sbin/modprobe sg
ACTION==add, SUBSYSTEM==scsi_device, SYSFS{type}==0|7|14, \
RUN+=/sbin/modprobe sd_mod
ACTION==add, SUBSYSTEM==scsi_device, SYSFS{type}==[45], \
RUN+=/sbin/modprobe sr_mod
ACTION==add, KERNEL==sg[0-9]*, BUS==scsi, SYSFS{type}==[36], \
SYMLINK+=scanner scanner-%k, MODE=0660
ACTION==add, KERNEL==sg[0-9]*, BUS==scsi, SYSFS{type}==8, \
SYMLINK+=changer changer-%k, MODE=0660, GROUP=disk
ACTION==add, SUBSYSTEM==scsi_device, SYSFS{type}==1,
SYSFS{device/vendor}==On[sS]tream, \
SYSFS{model}!=ADR*, RUN+=/sbin/modprobe osst
ACTION==add, SUBSYSTEM==scsi_device, SYSFS{type}==1,
SYSFS{device/vendor}==On[sS]tream, \
SYSFS{model}==ADR*, RUN+=/sbin/modprobe st
ACTION==add, SUBSYSTEM==scsi_device, SYSFS{type}==1,
SYSFS{device/vendor}!=On[sS]tream, \
RUN+=/sbin/modprobe st
=
I have no idea if this is correct as there's no changer, not even any scsi
stuff on this lappy, but you can compare and fix the obvious stuff at
least. And file a bugzilla entry if you get it fixed, giving details.
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Re: amanda ignoring the MAXDUMPS option?
On Friday 04 August 2006 01:07, Gene Heskett wrote: On Friday 04 August 2006 00:43, Gene Heskett wrote: Greetings; 2.5.1b1-20060714 running ATM. It seemed that I was hearing more disk thrashing than usual, so I took a look with htop and found 8 copies of dumper running on this box during the estimate phase, which is indeed the limit as set by the 'inparallel' option, but I also have a maxdumps set to 4 in that same file, AND I'm using spindle numbers in my dle's. I don't have 8 spindles in this machine, just 2, numbered 0 and 1 in the dle's. The 3rd spindle which never appears in a dle, is the vtapes drive. So why is amanda pounding on the drives with all this seek threshing? Or do I need to read a man page, as I'm screwed up in my understanding of these variables? Further adendum, 45 minutes later none of the dumpers on this box has returned an estimate, and none are using any cpu at all. All dumpers on the client have returned valid estimates according to amstatus. So I think this run will be another timeout party and wasted. Bummer. If anyone has any thoughts, I'm all ears but I'm going to bed for now. And at 07:30 am, they are still stuck, using zero cpu, and no email has been rx'd from amanda. I'm going back to 2.5.0 from 20060514, without a reboot, just a killall. I'd say it could be a kernel problem except it effects my server this run, and the client on a previous run, 2 entirely different kernels. I'd include the *20060804* log files, but there aren't any, maybe after I do the killall? htop says the dumpers are all Zombies and can't be killed. On the client box, when this occured, there was a parent shell that also went away when I did the killall, on this box there aren't any parent shells for the dumpers that are dead but not recycled. Reboot time I guess. Bummer... -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Re: can only run amanda tests as root
Gene Heskett [EMAIL PROTECTED] 08/04/06 12:03 PM This is why, when potential users run into these sort of problems, that we universally recommend that it be built from the tarball, following amanda's instructions so that the amanda build and install can be done correctly. Cheers, Gene In this instance, installing from source made no difference to the outcome of the perms that are applied to the autochanger devices by udev. I also thought along the same lines initially so when I installed from source and came across the same problem (but I didn't realise why at the time) I knew it was not an amanda issue at all. SteveC
Re: can only run amanda tests as root
On Friday 04 August 2006 08:19, Stephen Carter wrote: Gene Heskett [EMAIL PROTECTED] 08/04/06 12:03 PM This is why, when potential users run into these sort of problems, that we universally recommend that it be built from the tarball, following amanda's instructions so that the amanda build and install can be done correctly. Cheers, Gene In this instance, installing from source made no difference to the outcome of the perms that are applied to the autochanger devices by udev. I also thought along the same lines initially so when I installed from source and came across the same problem (but I didn't realise why at the time) I knew it was not an amanda issue at all. SteveC Ahh, so I was carrying coals to Newcastle. :( But was the snippet of 50-udev.rules I posted from my FC5 lappy of any assistance? -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
tapelist - how to edit
Dear all, my tapelist has become a bit confused, due to my own fault, by me adding tapes in the middle of my numbered sequence. At the moment it looks like this: 20060803 daily-5 reuse 20060802 daily-1 reuse 20060801 daily-3 reuse 20060731 daily-4 reuse 20060731 daily-2 reuse daily-5 was used last night, and amanda now wants daily-2. What is the correct way of editing this so amanda will use the daily-1 next, then daily-2, etc.? Would this be correct (I'm not sure of the implications of the dates in the tapelist, and whether I will need to adjust those dates as well)?: 20060803 daily-5 reuse 20060731 daily-4 reuse 20060801 daily-3 reuse 20060731 daily-2 reuse 20060802 daily-1 reuse Your advice will be much appreciated, as always. -- View this message in context: http://www.nabble.com/tapelist---how-to-edit-tf2050982.html#a5649657 Sent from the Amanda - Users forum at Nabble.com.
Re: Backup device for Amanda
The backup devices I am evaluating are 1. HP Ultrium 448 Tape Drive 2. HP DLT VS160 Tape Drive 3. HP SDLT 320 4. HP SDLT 600 I would like to know whether these backup devices are fully compatible with Amanda. Does anybody on this list use these backup devices in his/her setup ? Suggestions for any other suitable backup device are also welcome. amanda does not really care about your backup device, be it a tape drive, removable media or even local disks. As long as your OS can see and write to the drive (and control the robot if you have one) then you should be set. Personally i have used amanda with dds3,dds4,LTO, LTO2 and LTO3 tape drives and robots from HP and Dell without issue using MTX to control the robot. My amanda servers have allways been linux from RH7.3 upto CentOS4.3 hope that helps some
Re: Backup device for Amanda
On Fri, Aug 04, 2006 at 04:27:09AM -0700, Yogesh Hasabnis wrote: Hi All, I am trying to figure out a proper backup strategy for our setup, using Amanda as the backup tool. We have roughly 20 Linux/Windows dual-boot machines and one file server with Red Hat Enterprise Linux ES release 3 as the OS. To keep the backup procedure simple, we plan to keep all the critical data on this file server and only back up the data directories on this file server (No other machine would be backed up). The data to be backed up is currently roughly 100GB and may increase to more than 250GB in the next one year. I am trying to identify the proper backup devices/media for this requirement. The backup devices I am evaluating are 1. HP Ultrium 448 Tape Drive 2. HP DLT VS160 Tape Drive 3. HP SDLT 320 4. HP SDLT 600 I would like to know whether these backup devices are fully compatible with Amanda. Does anybody on this list use these backup devices in his/her setup ? short answers, yes and yes. longer answer, if your OS and system tools (mt, mtx, dd, tar, etc.) work with your drive, amanda will as amanda does not use its own drivers. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: can only run amanda tests as root
On Fri, Aug 04, 2006 at 07:03:39AM -0400, Gene Heskett enlightened us: This is a frequent problem when using a 'packaged' version of amanda. The rpm packagers in particular have demonstrated many times that they do not understand how amanda treats security issues. Amanda's build gives it enough perms to do the instant job each piece needs to do, and no more. This is why, when potential users run into these sort of problems, that we universally recommend that it be built from the tarball, following amanda's instructions so that the amanda build and install can be done correctly. Not to get off topic, and no offense Gene, but that second sentence is entirely inaccurate. There are several problems with Amanda RPMs which require compromises be made, but not understanding security and how amanda works is definitely *not* one of them. What some of the problems are include: - Inability to know the hostname of the amanda server (or any server for that matter) on the clients network. Since amanda requires these at build time, the only logical compromise is to use localhost - Inability to know what user the software will be built as (if rebuilding a source RPM). There are RPM mechanisms in place that fix that, though not pretty, which set ownership to the appropriate user and permissions. I would argue that the fact these are in there (at least in the RedHat-produced RPMs) counter your point about not understanding the security needs. As always, I consider http://www.math.ohiou.edu/~hyclak/casit/amanda/ a worthwhile read for anyone using an RPM-based system, and recommend that users of Amanda rebuild SRPMs for their environment. Jay has made it easier with the latest Fedora Development RPMs to do that in the future. Respectfully, Matt -- Matt Hyclak Department of Mathematics Department of Social Work Ohio University (740) 593-1263
failed dumps still taping
Is it normal for a DLE listed as failed under FAILURE AND STRANGE DUMP SUMMARY: to still be taped? I'm having different DLE's exhibit failure, perhaps three times a week. Reasons are not always timeout like the one shown below. But one thing struck me about most of them, the detailed report for the DLE still showed a lot of data dumped and taped; in some cases enough to seem to be all that I'd expect. I don't remember in my old installation having a dump fail while in progress, so perhaps I'm seeing normal behavior and never experienced it before. Here is the one from last night. It is an indirect windows client. But I've had similar results from direct Solaris and linux clients too, including the amanda host. I don't think they were all data timeouts, but I'd have to go back and check. FAILURE AND STRANGE DUMP SUMMARY: ... bigcow LastChanceC lev 0 FAILED [data timeout] bigcow LastChanceC lev 0 STRANGE FAILED AND STRANGE DUMP DETAILS: /-- bigcow LastChanceC lev 0 FAILED [data timeout] sendbackup: start [bigcow:LastChanceC level 0] ... ? NT_STATUS_SHARING_VIOLATION opening remote file \Documents and ... \ NOTES: planner: Incremental of bigcow:LastChanceC bumped to level 4. planner: Full dump of bigcow:LastChanceC promoted from 1 day ahead. DUMP SUMMARY: DUMPER STATS TAPER STATS HOSTNAME DISK L ORIG-MB OUT-MB COMP% MMM:SS KB/s MMM:SSKB/s --- -- ... bigcow LastChanceC 0 8549 5978 69.9 66:12 1541.1 6:00 16996.6 -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Backup device for Amanda
Hello, As long as the OS detects the devices amanda will be able to use them. An easy way to see whether the devices were detected by the system is to look at the /proc/scsi/scsi file after the devices are connected and the system is rebooted. Pavel Yogesh Hasabnis wrote: Hi All, I am trying to figure out a proper backup strategy for our setup, using Amanda as the backup tool. We have roughly 20 Linux/Windows dual-boot machines and one file server with Red Hat Enterprise Linux ES release 3 as the OS. To keep the backup procedure simple, we plan to keep all the critical data on this file server and only back up the data directories on this file server (No other machine would be backed up). The data to be backed up is currently roughly 100GB and may increase to more than 250GB in the next one year. I am trying to identify the proper backup devices/media for this requirement. The backup devices I am evaluating are 1. HP Ultrium 448 Tape Drive 2. HP DLT VS160 Tape Drive 3. HP SDLT 320 4. HP SDLT 600 I would like to know whether these backup devices are fully compatible with Amanda. Does anybody on this list use these backup devices in his/her setup ? Suggestions for any other suitable backup device are also welcome. Thanks In Advance Yogesh Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta. http://us.rd.yahoo.com/evt=42241/*http://advision.webevents.yahoo.com/handraisers
Re: suspiciously terrible performance of 2.5.1 beta on OpenBSD/amd64 (now a crash...)
On Wednesday 02 August 2006 16:18, David Golden wrote: so switched nearly-2.5.1 to vanilla bsd with holding disk in order to try another test with nearly-2.5.1 to try to eliminate that as the issue... but I can't! Bigger Problems: Amanda driver process just upped and dumped core - guess I got my wish for a crash... Could be entirely unrelated to previous performance problem, of course. FWIW, have filed driver core dump as bug #1534445 However, have also just found that it doesn't _always_ crash. e.g. if there's only one DLE and it's of type always-full (that uses the holding disk), it does run: *** And in that case, dump - holding disk *is* taking a terribly long time with 2.5.1b2 compared to 2.4.5p1 While 2.4.5p1 to holdin disk is presumably slowed somewhat for the local filesystems in question by some shared-spindles headthrashing, dump still only takes a few minutes at a few MB/sec in 2.4.5p1, 2.5.1b2's sendbackup dump was saying it was going to take 14-15 hours... for a 10 GB FS with 2 GB of data ? Argh. Also spotted a zombie gzip process hanging about... and I don't think indexing is actually working right. So, anyway, have opened bug #1534629 for the performance issue.
Re: can only run amanda tests as root
On Friday 04 August 2006 10:21, Matt Hyclak wrote: On Fri, Aug 04, 2006 at 07:03:39AM -0400, Gene Heskett enlightened us: This is a frequent problem when using a 'packaged' version of amanda. The rpm packagers in particular have demonstrated many times that they do not understand how amanda treats security issues. Amanda's build gives it enough perms to do the instant job each piece needs to do, and no more. This is why, when potential users run into these sort of problems, that we universally recommend that it be built from the tarball, following amanda's instructions so that the amanda build and install can be done correctly. Not to get off topic, and no offense Gene, but that second sentence is entirely inaccurate. Only if you are looking at it from the redhat/fedora side of the fence, Matt. There are several problems with Amanda RPMs which require compromises be made, but not understanding security and how amanda works is definitely *not* one of them. What some of the problems are include: - Inability to know the hostname of the amanda server (or any server for that matter) on the clients network. Since amanda requires these at build time, the only logical compromise is to use localhost With all due respect Matt, that puts a bullet through the heart of any chance to do a recovery with the recovery tools as they specifically reject the localhost as a valid name because it could be any machine anywhere. Thats one of the security things amanda enforces. Without that, recovery is a mt, dd, gzip and tar exersize. Doable, but a pita. Either that, or you have to patch that back out of amanda before the object package is built. - Inability to know what user the software will be built as (if rebuilding a source RPM). There are RPM mechanisms in place that fix that, though not pretty, which set ownership to the appropriate user and permissions. I would argue that the fact these are in there (at least in the RedHat-produced RPMs) counter your point about not understanding the security needs. Then the only way to do amanda as an rpm is in the form of a source rpm isn't it? As always, I consider http://www.math.ohiou.edu/~hyclak/casit/amanda/ a worthwhile read for anyone using an RPM-based system, and recommend that users of Amanda rebuild SRPMs for their environment. Jay has made it easier with the latest Fedora Development RPMs to do that in the future. Whats needed is that this src rpm be self building as it installs, after installing its own user, makeing that user a member of the group disk or backup as appropriate and detecting via uname responses the host servers name during the configure stage, and the install process switching users as appropriate during the build and install phases. However rpm does not that I know of, and I'm certainly not a real card carrying expert about rpm, support the continuous build and install of a src rpm in one command line execution. AFAIK it just builds the package, leaving the user to then install it in a seperate step. Maybe its time for rpm-5.0? And we were, in the present case, talking about SuSe rpms, not redhat/fedora. Redhat/fedora rpms haven't recently been enough of a problem to generate noticable traffic on the list. They were, in spades, 2-3 years ago, as I'm sure you are aware, with no little traffic defending rpms coming from the redhat camp's packager, whose name escapes me at this late date but it wasn't you. And I don't recall that it was Jay at the time either, but I could be wrong about that. But after he (whomever) had lurked and listened on the list for a while, it seemed that the problems with redhat/fedora rpms went away. So in that regard, redhat/fedora seems to have adjusted their packageing enough fix it. I guess that because amanda is so easily built and installed, I'm naturally going to do it that way. And I haven't been reticent about posting my script to do that, along with suitable caveats about what needs to be changed. I haven't changed that script but once in 6 years since I wrote it, and that was when I switched to vtapes nearly 2 years ago. Its not a very long script, but it guarantees that option compatibility is maintained from snapshot to snapshot. In any event, it turned out to not be an amanda problem, but a SuSe furnished 50-udev.rules problem and I believe the OP has now posted that he has fixed it. Respectfully, Matt -- Cheers Matt, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Re: failed dumps still taping
On Friday 04 August 2006 10:30, Jon LaBadie wrote: Is it normal for a DLE listed as failed under FAILURE AND STRANGE DUMP SUMMARY: to still be taped? I'm having different DLE's exhibit failure, perhaps three times a week. Reasons are not always timeout like the one shown below. But one thing struck me about most of them, the detailed report for the DLE still showed a lot of data dumped and taped; in some cases enough to seem to be all that I'd expect. I don't remember in my old installation having a dump fail while in progress, so perhaps I'm seeing normal behavior and never experienced it before. Here is the one from last night. It is an indirect windows client. But I've had similar results from direct Solaris and linux clients too, including the amanda host. I don't think they were all data timeouts, but I'd have to go back and check. FAILURE AND STRANGE DUMP SUMMARY: ... bigcow LastChanceC lev 0 FAILED [data timeout] bigcow LastChanceC lev 0 STRANGE FAILED AND STRANGE DUMP DETAILS: /-- bigcow LastChanceC lev 0 FAILED [data timeout] sendbackup: start [bigcow:LastChanceC level 0] ... ? NT_STATUS_SHARING_VIOLATION opening remote file \Documents and ... \ NOTES: planner: Incremental of bigcow:LastChanceC bumped to level 4. planner: Full dump of bigcow:LastChanceC promoted from 1 day ahead. DUMP SUMMARY: DUMPER STATS TAPER STATS HOSTNAME DISK L ORIG-MB OUT-MB COMP% MMM:SS KB/s MMM:SSKB/s --- -- ... bigcow LastChanceC 0 8549 5978 69.9 66:12 1541.1 6:00 16996.6 What version of amanda was signed at the bottom of that msg, Jon? ATM, I'm also having all sorts of weird goings on with 2.5.1 snapshots, and I'm rerunning last nights run after re-installing 2.5.0p2 from 20060424 because the 2.5.1 stuff failed totally. And I had to reboot to get an amcheck to run, the client on this box wasn't responding after I'd killed all its processes that had turned into zombies in the night. The above NT error doesn't match the ones I'm seeing though, no NT stuffs here, the gtar's were failing, sometimes en-mass on one machine one night, on the next machine the next night. About the only thing consistent was the fact that it failed. Sometimes they'd run 2-3 random dle's, then die. Weirdsville. A rerun is about done, and amstatus says its ok. I'll hold this till I get that email to be sure. Yup, the printed report looks good. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Support for DVD-RAM?
Hello list, we need urgently a replacement for our current solution. We used until now a own script based on dump (fsdump), which copied after the dump the dump-files to dvd-ram. But now we have to big troubles with dump and want to switch to amanda. Does anybody knows how and can help me to figure out what is to do to switch to amanda, but also with dvd-ram as backup-media? regards Hans
Compression
How can I tell what compression I am using? Also how do I make sure hardware compression is off?
Re: Compression
James Wilson wrote: How can I tell what compression I am using? Also how do I make sure hardware compression is off? Hello, If you have compression enabled you will see something like compress client fast in your amanda.conf dumptype definition and amanda uses gzip for compression by default. You can change this default by using client custom option when you define your dumptype in amanda.conf. As far as the compression on the tape drive you can use mt -f /dev/nst0 defcompression 0 to turn compression off. Pavel
restoring from DVDs
Hi All, So one of my disks crashed before I had time to test all the DVD's I backed up to can be read, so I'm currently testing that now... :-/ Haven't had any read errors yet, but I'm keeping my fingers crossed :) BTW, it was actually one disk of nice and fast RAID 0 (so I'm restoring to the one good disk). Does anybody know if data recovery from it would be possible? I hope *not*, since I'm sending it back under waranty, and I can't erase it cos its dead, although it sounded like the platter might be all scratched up... Cheers, Laurence
Re: Compression
On Fri, Aug 04, 2006 at 04:00:16PM -0700, Pavel Pragin wrote: James Wilson wrote: How can I tell what compression I am using? Also how do I make sure hardware compression is off? Hello, If you have compression enabled you will see something like compress client fast in your amanda.conf dumptype definition and amanda uses gzip for compression by default. You can change this default by using client custom option when you define your dumptype in amanda.conf. As far as the compression on the tape drive you can use mt -f /dev/nst0 defcompression 0 to turn compression off. Such directions are very OS, and sometimes even release, specific. Plus, some tape drives include hardware switches to force compression on/off or to allow software to switch it. Besides mt (and other) commands such as PP mentions, some OS use different device names for compression on/off. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Support for DVD-RAM?
On Fri, Aug 04, 2006 at 11:26:45PM +0200, Kaiser, Hans wrote: Hello list, we need urgently a replacement for our current solution. We used until now a own script based on dump (fsdump), which copied after the dump the dump-files to dvd-ram. But now we have to big troubles with dump and want to switch to amanda. Does anybody knows how and can help me to figure out what is to do to switch to amanda, but also with dvd-ram as backup-media? There is no direct support for optical media. It would be a two step approach much like you appear to be doing now. From what I read on the list, those that use dvd's make their backups to virtual tapes, amanda speak for hard disk acting like magnetic tape. They size these vtapes to match what they want to write to dvd. Then in a separate step burn the vtape directory to the dvd. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
