Backup and recovery CD
A number of commercial backup vendors ship bootable CDs with a copy of their backup application installed. You can use these CDs to restore a system that was totally toasted, due to massive disk failure, being hacked, etc. I'm wondering if anyone has ever developed something similar for AMANDA. I'm envisioning something like the Red Hat installer, which boots up, lets you drop into a limited shell and lets you partition disks. The AMANDA bootable CD would boot up, let you format disks and give you a limited shell, and then let you run amrestore by connecting to the tape drive (or whatever archival media you are using) of your remote backup server. Just curious if anyone has ever gone down this road and if so, how far did you get? Thanks, Kevin -- Kevin M. Myer Systems Administrator Lancaster-Lebanon Intermediate Unit 13 (717) 560-6140
Solaris hosts amrecover oddity
Hi, I'm finding some oddities with trying to restore anything that was backed up from a Solaris host. My amanda backup server is running Red Hat 7.3, with their amanda packages, compiled from RPM (2.4.2p2-7). The Solaris boxes are running amanda 2.4.2p2, compiled from source, with the following options: /configure --without-server --with-user=backup --with-group=daemon --with-index-server=ironwood --with-gnutar=/usr/local/bin/gtar --with-readline=no What happens is that no matter where I run amrecover from (be it the Solaris box that was backed up or the backup server or another Linux box), I only see a few directories/files available for restore. For example, on the Solaris box, in the level 0 gnutar-lists file, it shows all the directories on the system. A backup report shows approximately 4Gb being backed up during that full backup. But, if I run amrecover, there's only a smidgeon of that visible: # /usr/local/sbin/amrecover IU13 -s juniper -t juniper AMRECOVER Version 2.4.2p2. Contacting server on juniper ... 220 juniper AMANDA index server (2.4.2p2) ready. 200 Access OK Setting restore date to today (2002-12-12) 200 Working date set to 2002-12-12. 200 Config set to IU13. 200 Dump host set to newt. $CWD '/' is on disk '/' mounted at '/'. 200 Disk set to /. / amrecover> ls 2002-12-04 export/ 2002-12-04 opt/ 2002-12-04 usr/ There should be all the files and other directories there as well (like /etc, /bin/, etc.). The only pattern that I can somewhere ascertain is that the three above directories all contain files that are have a longer filenames: /export/home/myer/lmbench-2alpha12/BitKeeper/other/BitKeeper/etc/SCCS amrecover> ls 2002-12-04 s.logging_ok-staelin-at-hpli8.hpli.hpl.hp.com-2 OR /opt/sfw/mysql-3.23.33-sun-solaris2.7-sparc/sql-bench/Results amrecover> ls 2002-12-04 ATIS-Adabas-Linux_2.0.35_i686-cmp-adabas,mysql So where are the other files and directories? The only thing that has changed is that the index-server option I passed to configure when I compiled amanda on the Solaris box is no longer valid (i.e its not ironwood anymore, its juniper) but I thought that specifying amrecover with -s would override that. The logs on the backup server would indicate that indeed, it did backup 4Gb of data. Any ideas? I've looked through the logs but nothing is jumping out at me. Running amrecover from the Solaris host and setting "sethost" and "setdisk" to a Linux server and parition respectivly shows me everything backed up on that server. So its very specifically a problem with running amrecover anywhere and trying to restore a Solaris box to anywhere. Thanks, Kevin -- Kevin M. Myer Systems Administrator Lancaster-Lebanon Intermediate Unit 13 (717) 560-6140
Backup server won't backup itself - times out
Hello, I'm using Amanda 2.4.2p2 on a Red Hat Linux 6.2 box (Dell PowerEdge 4400, dual 733Mhz Pentium III). It works great for backing up about 15 different servers - except it won't back itself up 95% of the time. The machine does have some larger partitions (36Gb), which are file shares but in general, these shares are excluded from backup because I backup them from a Macintosh client, so as to preserve Mac specific items (and since its easier to restore the files from the Mac side since there are also meta-files on the Linux side). However, I don't think the larger partitions are the cause of the problem. The specific error messages that I am seeing are (for each of the partitions - there are eight): acorn /mnt/web lev 0 FAILED [Request to acorn timed out.] During a backup session, the logs indicate that runtar executes for each partition but the problems show up in the logs for amandad: amandad: dgram_recv: recvfrom() failed: Connection refused amandad: waiting for ack: Connection refused, retrying amandad: dgram_recv: recvfrom() failed: Connection refused amandad: waiting for ack: Connection refused, retrying amandad: dgram_recv: recvfrom() failed: Connection refused amandad: waiting for ack: Connection refused, retrying amandad: dgram_recv: recvfrom() failed: Connection refused amandad: waiting for ack: Connection refused, retrying amandad: dgram_recv: recvfrom() failed: Connection refused amandad: waiting for ack: Connection refused, giving up! So apparently, something is timing out. I did have problems in the past with backing up clients on the other side of our firewall but that was resolved by specifying port ranges and increasing the tcp keep alive value on the backup server. However, this traffic is certainly never reaching the firewall, because its the local host thats being backed up. I thought maybe the problem was with the machine having two interfaces on different networks but it doesn't seem to matter which interface I specify - it still times out. Any ideas of what to look for? Thanks, Kevin -- Kevin M. Myer Systems Administrator Lancaster-Lebanon Intermediate Unit 13 (717) 560-6140
Re: Problems with Solaris 8 BSM auditing and amanda 2.4.2p2
On Tue, 29 May 2001, Scot W. Hetzel wrote:
> From: "Kevin M. Myer" <[EMAIL PROTECTED]>
> > In my logs, I see:
> >
> > May 28 16:00:00 newt inetd[105]: [ID 858011 daemon.warning]
> > /usr/local/libexec/amandad: Hangup
> > May 28 16:00:02 newt last message repeated 38 times
> > May 28 16:00:02 newt inetd[105]: [ID 667328 daemon.error] amanda/udp
> > server failing (looping), service terminated
> >
> It's an inetd problem, apparently when you enable kernel auditing, the
> maximum number of server instances per 60 second interval is lowered for
> inetd. You need to increase this value until inetd stops reporting a
> looping condition.
>
> See your inetd man page for how to set this value.
I'm aware of the inetd limit, which is hard coded at 40 connections per 60
seconds. The syntax for changing that limit is slightly different under
Solaris than Linux which I found out when I tried to change that last week
(you use -r as an option to inetd as opposed to
{wait,nowait.} but thats not exactly the problem that I'm seeing.
If you do a packet trace, there are only four packets exchanged so forty
amandad's should never be spawned and in this case, I'm only running
amcheck.
What appears to be the problem and which I should have made clearer is
that inetd is not interpretting the return value of the forking child
properly and aparently instead is attempting to spawn forty copies of
amandad. So it is running into the inetd connection limit but its never
actually launching anything.
Incidentally, Amanda works on my Solaris 7 boxen with BSM enabled so I
guess what I should have asked is this:
First, does anyone have Amanda running with Solaris 8 and BSM auditing?
Secondly, if not, would you classify the signalling problem as a Solaris
problem or an amanda problem? I'm pretty certain it is a Solaris problem
but I want to make sure that its not a bug that still allows amandad to
run under less-observed conditions but makes it barf under an audited one
(ala Schrodinger's cats). I'll submit as a bug to Sun - hopefully someone
can confirm this behaviour though.
Kevin
--
Kevin M. Myer
Systems Administrator
Lancaster-Lebanon Intermediate Unit 13
(717)-560-6140
Problems with Solaris 8 BSM auditing and amanda 2.4.2p2
Hello, I recently upgraded our only Solaris 8 box from Solaris 8 Maintenance Update 2 to MU4. In addition, I hardened some of the security on the box, among other things enabling BSM auditing. Now, amandad will not run from inetd, although I can launch it from the command line without a problem. The upgrade docs for Solaris warn of possible problems with applications linked to libraries that have changed but I've rebooted, as well as recompiled amanda and the problem persists. In my logs, I see: May 28 16:00:00 newt inetd[105]: [ID 858011 daemon.warning] /usr/local/libexec/amandad: Hangup May 28 16:00:02 newt last message repeated 38 times May 28 16:00:02 newt inetd[105]: [ID 667328 daemon.error] amanda/udp server failing (looping), service terminated This occurs each time inetd attempts to launch amandad. As soon as I disable kernel auditing and reboot, amandad launches fine from inetd. I don't feel like downgrading this box to Solaris 8MU2 since the upgrade took four hours () just to see if it works with that version and with auditing. So is this an amandad problem or a Solaris problem or both? If anyone is a Sun contract customer, the error messages and behaviour that is logged is very similar to bug # 4335695, although that deals with the attempted execution of non-existent applications by inetd. Now I guess I have to decide which is more important - auditing a system while its getting cracked or hosed or being able to restore a system after its cracked or hosed. I guess I'll opt for the backup but I'm curious why the two don't play nice with each other. Kevin -- Kevin M. Myer Systems Administrator Lancaster-Lebanon Intermediate Unit 13 (717)-560-6140
Re: Large partition not backing up
On Mon, 7 May 2001, John R. Jackson wrote: > >... the backup of my file server parition > >is failing with a rather uninformative error message: > > > >ironwood /mnt/files lev 0 FAILED [dump to tape failed] > > There should have been other messages besides this one, perhaps at the > top of the report or in the NOTES section. There are but they are useless in diagnosing why its failing. Here's what I've got as far as messages: FAILURE AND STRANGE DUMP SUMMARY: ironwood /mnt/files lev 0 FAILED [dump to tape failed] NOTES: planner: Forcing full dump of ironwood:/mnt/files as directed. > > >... I exclude a number of directories because > >they are backed up with my Macintosh backup program and sendsize > >calculates a size of 15Gb to be backed up. The file server partition also > >holds the amanda holding disk directory. ... > > If you're trying to back up the file system that has the holding disk > area, you should use "holdingdisk no" in the dumptype to force it to go > direct to tape. Actually, I was using an exclude file to exclude the amanda directory. I've switched it over to a "holdingdisk no" config. Hopefully a direct dump to tape will solve this problem. [Update - the backup ran over night with this option: the exact same messages were output as listed above]. I'm curious what is causing this though. My debug files show nothing out of the ordinary. There are no errors listed and the sendsize estimate completes fine. The only thing that doesn't happen is sendbackup is never executed for this filesystem. Its as if its silently failing and it couldn't be happening to a worse partition than my main file server/home directory partition. Ugh. Kevin -- Kevin M. Myer Systems Administrator Lancaster-Lebanon Intermediate Unit 13 (717)-560-6140
Large partition not backing up
Hi, Using amanda-2.4.2p2 (but this was happening with earlier versions as well) on a Red Hat Linux 6.2 server, the backup of my file server parition is failing with a rather uninformative error message: ironwood /mnt/files lev 0 FAILED [dump to tape failed] I don't see anything in the logs that indicate why its failed, although I will offer my suspicions. The partition being backed up is a 38Gb partition and has 30Gb in use. I exclude a number of directories because they are backed up with my Macintosh backup program and sendsize calculates a size of 15Gb to be backed up. The file server partition also holds the amanda holding disk directory. What I am theorizing is that there is not enough space on the dump disk to dump the entire parition at once and hence it fails. In my amanda.conf I have: comment "main holding disk" directory "/mnt/files/amanda/dumps" use -200 Mb chunksize 1Gb At one point, there seemed to be an option to have a negative chunksize, whereby amanda would write directly to tape if a chunk was larger than that chunksize. That would have solved my problem but that solution is gone now. Was something else implimented for situations like this? Thanks, Kevin -- Kevin M. Myer Systems Administrator Lancaster-Lebanon Intermediate Unit 13 (717)-560-6140
Re: Mac OS X Server problems w/ gzip
On Wed, 15 Nov 2000, Sandra Panesso wrote: > Hi Kevin > > I Want to know if you have tried to run amanda on Mac OS X Beta. If you did > please tell me how was it. My question is because I am testing to run amanda > on Mac OS X Beta but I found some problems when i tried to compiled it. I > used ./configure --with-user= --with-group= --with-updportrange= > --with-portrange= I have not tried AMANDA with Mac OS X Beta. I do know that I had to compile a new version of tar to use with OS X Server and specify a --with-gnutar=/usr/local/bin/tar option to AMANDA. /usr/bin/tar is NOT gnutar and although there is a gnutar installed (/usr/bin/gnutar), its version 1.12 and I wanted to install 1.13.X. Hope that helps. Kevin -- Kevin M. Myer Systems Administrator Lancaster-Lebanon Intermediate Unit 13 (717)-560-6140
Re: Mac OS X Server problems w/ gzip
On Thu, 9 Nov 2000, Mitch Collinsworth wrote: > Have you tried compress client fast yet or are you still doing client > best? Yes, actually, I had been using client fast for all my backups. Maybe I would do better with client best :) Still, the thing that irks me most about it is not that the backup is slow - its that Apple has made it nigh on impossible to debug anything under Mac OS X Server. If I could just run ktrace on a running backup, I'm sure it would shed some light on the matter. But like I said, its not that big an issue - as long as we have the network bandwidth and tape space and/or can do the compression on the backup server, things will be fine. Kevin -- Kevin M. Myer Systems Administrator Lancaster-Lebanon Intermediate Unit 13 (717)-560-6140
Re: Mac OS X Server problems w/ gzip
On Wed, 8 Nov 2000, Chris Karakas wrote: > When I first used AMANDA, I used it without compression. Then I upgraded > the tape drivers (which used an inherend "block" compression, > transparent to the user), the new ones did not support any inherent > compression, so I had to use the usual "client" compression. I was > amazed to see how much longer it took. Where AMANDA used to take 2-3 > hours to finish, now it took 6-8! Thats all fine and good but my AMANDA server backs up 13 servers. 3 run Solaris, 8 run Linux and 1 runs OS X Server. I can do full backups of all the servers in less than three hours, with client-side compression, with the exception of the OS X Server. It takes over 8 hours to compress and backup 400 Mb of data on that machine (a 400MHz G4 machine with a Gig of RAM). So its not merely an issue of gzip compression adding time to the backups. gzip is just really, really slow when used with AMANDA under Mac OS X Server. Command line issued tar/gzip pipes seem to work reasonably fast on the OS X Server. Its not a big deal - I've moved all compression to the backup server at this point, but it is an oddity I was hoping to figure out. Kevin -- Kevin M. Myer Systems Administrator Lancaster-Lebanon Intermediate Unit 13 (717)-560-6140
Mac OS X Server problems w/ gzip
Hello, Awhile back, I had posted about problems I was having with using AMANDA with Mac OS X Server. The problems I was seeing related to extremely long backup times, in excess of 8 hours to backup only 400MB of data. Apple has disabled ktrace debugging of the kernel so there wasn't much I could do to figure out where the problem is. However, recently, I decided to do a set of dumps with compression turned off. It turns out, thats where the slowdown is occuring. For some reason, the compression pipe from gzip to tar is extremely slow under Mac OS X Server. Since Mac OS X Server is in part based on FreeBSD, I was wondering if anyone has noticed similar situations with FreeBSD? Also, has anyone tested AMANDA with Mac OS X Beta and do similar problems exist there? Thanks, Kevin -- Kevin M. Myer Systems Administrator Lancaster-Lebanon Intermediate Unit 13 (717)-560-6140
