Re: 2.5.0 problems on Solaris 8
On Fri, Apr 21, 2006 at 09:41:54AM -0400, stan wrote: I'm starting to upgrade my clients. The HP-UX boxes (10.20) went flawlessly. But I'm having a few issues with my first Solaris 8 machine. Now in the interest of full disclosure, these machines are supported by a 3rd party OEM, and the machine I use for a build machine was recently rebuilt by them to address a kernel memory leak issue, so odds are good what I'm seeing is a result of their meddling, but I could use some help figuring this out. [snip] My first amcheck failed. I tried to run amandad by hand, and found that the dynamic linker was failing to find libgcc_s.so.1. I looked in .cshrc and .profile, and found that they had broken LD_LIBRARY_PATH. I fixed this, restarted inetd, and was able to run an amcheck. So far so good. LD_LIBRARY_PATH is at best a kludge. Needing to use it is always a sign that something's broken. (Having a 537 character PATH generally is, as well.) But, the next backups from this machine failed, and when I look in the debug file, I find this: ld.so.1: /opt/amanda/libexec/noop: fatal: libgcc_s.so.1: open failed: No such file or directory I'm a bit confused by what sets up the search path for shared libraries under Solaris 8, when they are invoked as services like Amanda does. Is there a way to give the binaries a hard coded search path? Yes, pass the -R/path/to/library flag to the linker at build time. For Solaris systems, every -L given to the linker should have a corresponding -R. libgcc_s.so.1 is a bit of a special case, since gcc is implicitly linking that one in when needed. Figure out where it lives and pass the appropriate -R option via LDFLAGS when building.
Re: 2.5.0 problems on Solaris 8
On Fri, Apr 21, 2006 at 03:47:29PM -0400, stan wrote: On Fri, Apr 21, 2006 at 11:25:02AM -0700, Mike Delaney wrote: Yes, pass the -R/path/to/library flag to the linker at build time. For Solaris systems, every -L given to the linker should have a corresponding -R. libgcc_s.so.1 is a bit of a special case, since gcc is implicitly linking that one in when needed. Figure out where it lives and pass the appropriate -R option via LDFLAGS when building. OK, should I manual add this to te Makefiles? Or is there a way to tell configure this? Perhaps an environment variable? LDFLAGS is an environment variable: $ export LDFLAGS=-R/path/to/gcc/libraries $ ./configure $ make
Re: Attempt to contact amanda gives sshd error -- dont know why sshd is involved!
On Thu, Mar 30, 2006 at 03:34:02PM -0500, Lengyel, Florian wrote: I have no idea what this means. I started a new thread in good faith. You did not start a new thread. You replied to an unrelated message and simply changed the Subject: header, thereby hijacking the thread. Starting a new thread involves composing a brand new message, not replying to an existing message.
Re: Rebuilding amanda for a new tar version
On Fri, Feb 10, 2006 at 04:28:52PM -0500, Guy Dallaire wrote: I've just discovered that tar 1.14 might actually be buggy. On many of my linux boxes (clients and server) I have gnu tar 1.14 or 1.13.25 I'm understanding that I should instead download the latest tar version (or 1.15) and install this in /usr/local/bin and use this instead of the system's default in /usr/bin I will only have to redo the config using --with-gnutar=/usr/local/bin/tar on my linux box and then re-make amanda using the same parameter I used originally. Alternatively, you could just rebuild the tar RPM for the new version, upgrade it, and leave Amanda alone. The question I have is: When I will do the make install at the end, will it overwrite my amanda configuration files and disklists etc ? No, make install doesn't put anything in the config directory.
Re: distlist order ?
On Mon, Oct 24, 2005 at 01:57:58PM -0400, Jon LaBadie wrote: I've not used them, but aren't there some disklist config options to specify do these at a specific time or delay these for some time after starting amdump? There's the starttime dumptype option to specify a fixed not before time of day, but using that for this purpose means estimating when the dumps of all the other systems are likely to be done.
Re: Will retry behavior
On Tue, Aug 30, 2005 at 05:19:29PM -0400, [EMAIL PROTECTED] wrote: NOTES: taper: tape weekly1 kb 35900256 fm 14 writing file: No space left on device taper: retrying zeus: /hmssql.0 on new tape: [writing file: No space left on device] taper: tape weekly2 kb 35878464 fm 3 writing file: No space left on device taper: retrying athena: /F.0 on new tape: [writing file: No space left on device] taper: tape weekly3 kb 0 fm 0 [OK] --- The result is that athena and zeus are failed. :( I think you're misreading the message. The first line says that amanda failed to write a DLE to tape weekly1 beacuse the tape was full. The second line says that it retried taping DLE zeus:/hmssql.0 on a new tape [the last attempt failed because the first tape was full]. There's nothing there that says that zeus:/hmssql.0 didn't make it on to tape. The same goes for the 3rd and 4th lines w.r.t. athena:/F.0. If those dumps really had failed to tape, there would have been a big NOTICE IN ALL CAPS up at the very top of the report stating that some DLEs had failed to tape.
Re: HD backup strategy ?
On Wed, Aug 17, 2005 at 03:03:59PM +0300, Toomas Aas wrote: Jon LaBadie wrote: Haven't seen anyone on the list mention using it, but Iomega introduced some interesting hardware last year. I think they call it Rev, basically a small, removalble hard drive cartridge. Think high capacity, tiny zip drive as it has 35GB native capacity and a builtin compressor. Along with their single slot device, they also introduce an autoloader that can hold 10 cartridges. Funny, I just stumbled upon this on another mailing list yesterday. Looks like IOMega continues to live up to its reputation: http://lists.freebsd.org/pipermail/freebsd-questions/2005-July/094114.html Or someone didn't look hard enough. While most systems device drivers do detect REV drives as CD-ROMs, that doesn't prevent one from writing to it. And while the filesystem format isn't ISO-9660, it's not some Iomega proprietary thing either: it's UDF. Basically, from the system's perspective REV drives look and act like high capacity DVD-RAM units. I've been using one with SuSE Linux for several months now.
Re: runtar: error [must be invoked by amanda]
On Wed, Jul 13, 2005 at 11:07:25PM +0200, Stefan G. Weichinger wrote: Jon LaBadie wrote: On Wed, Jul 13, 2005 at 10:13:04PM +0200, Stefan G. Weichinger wrote: I would like to have some motivated amanda-hackers who try to move all these configure-time-params into amanda.conf ... When this is done, shouldn't the continued paring of amanda.conf include removal of those things not specific config related? Perhaps it is time for a new system-wide config file with the types of parameters of amanda user ... Give me more ... Let's think something like /etc/amanda/amanda.conf /etc/amanda/tapetype.conf /etc/amanda/config/daily/daily.conf /etc/amanda/config/daily/daily.disklist Along that line, here's an idea: if the parser were to be modified such that you could redefine something that had already been specified earlier in the amanda.conf file, the includefile parameter could be used to inherit a common base amanda.conf and override the things that need to be different. Some tools, amrecover in particular, could be made to look for the amanda.conf as $sysconfdir/$config_name/amanda.conf, and if not found then fall back to $sysconfdir/amanda.conf. (I'm not sure that behaviour would be appropriate for most of the server side, though.)
Re: How smart is AMANDA
On Tue, Jul 12, 2005 at 04:18:28PM -0600, Chris Saunders wrote: I will be the only one doing these backups and I would like the process to be as automated as possible. Our linux boxes run traffic simulation models that can take 25 to 30 hours to run. Our engineers relentlessly run these boxes almost non-stop. Our simulations are extremly heavy on the I/O, so running a backup while a simulation is running is out of the question. And since these simulations take so long to run, telling my engineers they cannot use the machine over the weekend because of a scheduled backup would not work at all. So I need a smart backup plan that can adjust to different schedules based on machine avaliability, but at the end of the week have a dump of each machine. Any ideas? Is there a way for AMANDA to determine if a machine is busy or idle and do the backup only when it is idle? On the same token can it pause its backup of that box if another simulation is started. Amanda does not have the ability to work around other processing happening on the clients. I'm not aware of any backup software that does. The typical method of handling a compute farm such as this is to arrange for the compute nodes to not have any data on them that needs to be backed up in the first place. Input data for the jobs gets copied from a remote fileserver to local disk, the job runs, the output gets copied back to the fileserver, and the input and intermediate files get removed from the local disk. Failure recovery of the compute nodes is handled by an auto-install setup (kickstart, autoyast, jumpstart, etc.). Disk died? Replace disk, boot from network, and reinstall hands off. The key here is getting the postinstall scripts complete to the point where you can kick off the install and forget about it, knowing that the system will get configured exactly the way it needs to be without any further intervention.
Re: Backup to Hard Drive
On Thu, Jun 16, 2005 at 02:24:02PM -0400, Gene Heskett wrote: On Thursday 16 June 2005 10:52, Cody Holland wrote: I'm a newb to Amanda, and would like to backup everything to a server running Raid0. I'm sure this is very possible, I just cannot find any docs on it. Any help would be greatly appreciated. However, under recovery situations where you may be doing a bare metal rebuild, I'd be a bit spooked of a raid as there is a possibility under those total disaster conditions, that the raid may not be available without a lot of pre-configuring of the md driver. I'd be more worried about using a RAID-0 device to store my backups: loose any one disk and the volume is toast, and each disk in the stripe increases the likelyhood of a failure. Compared to that, having to configure a software RAID driver to access a pre-existing volume when rebuilding the OS on the server is a mere annoyance.
Re: handling off-site tape storage
On Tue, Jun 07, 2005 at 01:13:57PM +1000, Keenan, Greg John wrote: I'm curious how admins out there handle the off-site storage situation. The requirement here is that full weekly backups are stored off-site for 4 weeks, full monthly backups for 6 months etc. For the weekly fulls, I'd just send the whole dumpcycle offsite (assuming dumpcycle=1week) for 4 weeks. My preference in that situation would be to have the current week's tapes in the library, the previous week onsite in a firesafe in case they're needed to restore something recent, and the remainder offsite. For the monthlys, I run a separate config with dumpcycle=0 (i.e. always full) against the same disklist as my regular nightly config. Those get sent offsite. For yearly archives, pick one month out of that set, mark the tapes noreuse, and keep them offsite for a longer period.
Re: AMANDA with GPG
On Tue, May 31, 2005 at 02:07:09AM -0400, Jon LaBadie wrote: On Mon, May 30, 2005 at 10:17:11PM -0700, Mike Delaney wrote: With the gzip wrapper installed on a client, but not the server, backups work fine (once you fix the obvious redirection bug in the script), but restores don't: With amrecover, gzip gets run on the server, not the client, so you never get the opportunity to decrypt the backup. Does this mean that amrecover does not recognize/honor the compress client ... directive of a dumptype? Effectively, yes. What appears to be happening behind the scenes is that amrecover causes amrestore -h to be run on the server, which decompresses the image there before transmitting it back to the client.
Re: AMANDA with GPG
On Sat, May 28, 2005 at 08:20:42PM +0200, [EMAIL PROTECTED] wrote: Hello, amanda-users, just a short call for opinions: Who uses gpg-amanda, as described at http://security.uchicago.edu/tools/gpg-amanda/ ? I am thinking about including this in the docs and would like to hear your thoughts. I was experimenting with it in combination with 2.4.4p2 a few days ago. It definately has some limitations. With the gzip wrapper installed on a client, but not the server, backups work fine (once you fix the obvious redirection bug in the script), but restores don't: With amrecover, gzip gets run on the server, not the client, so you never get the opportunity to decrypt the backup. With amrestore, you have the same problem since amrestore has to be run on the server, though in this case you can manually insert gpg between amrestore and tar/ufsrestore/etc. If you install the wrapper on the server as well, things get even more fun since AMANDA uses gzip to compress the indexes - now the indexes are encrypted, and amrecover won't work for any client. Additionally, the private key(s) have to live on the server, not the client since amrestore will be trying to decrypt the backup when it decompresses.
Re: holding disk with vtapes?
On Tue, May 17, 2005 at 02:16:38PM -0400, John Young wrote: Folks, If you are using vtapes on a RAID for your backup media, is there any point to also using a holding disk? I can easily understand the use of a holding disk if you are using real tapes but am not sure what it buys you if you are using vtapes. Any comments? Parallelism. With no holding disk, dumps are done in serial to the vtape, just as they would be for a real tape.
Re: gpg with amanda
On Tue, May 10, 2005 at 05:39:21PM -0400, Eric Dantan Rzewnicki wrote: I had a link for using gpg with amanda, but can't find it. Does anyone have the URL handy? http://www.google.com/search?q=gpg+amanda
Re: amanda and solaris 10 smf
On Mon, May 09, 2005 at 11:13:01AM -0800, LaVonna Sydow wrote: I am trying to configure amanda on a Solaris 10 server that will backup only itself. When I run amcheck, I get: selfcheck request timed out. Host down? svcs shows: online 11:05:10 svc:/network/amidxtape/tcp:default online 11:05:10 svc:/network/amandaidx/tcp:default maintenance 11:07:05 svc:/network/amanda/udp:default svcs -x shows: svc:/network/amanda/udp:default (amanda) State: maintenance since Fri May 06 12:12:48 2005 Reason: Restarter svc:/network/inetd:default gave no explanation. See: http://sun.com/msg/SMF-8000-9C Impact: This service is not running. Two possibilities come to mind: a.) Something in the service definition for svc:/network/amanda/udp is broken. Check and compare the output from running inetadm -l against the three services. b.) You've discovered a bug in the new inetd implementation. Follow the instructions in the URL above and chase it down with Sun. If this: http://forum.sun.com/thread.jspa?threadID=24302 is you, then I don't see anything obvious wrong with the service definition.
Re: Is the Dell Powervault 132T a changer device?
On Wed, Apr 27, 2005 at 03:03:39PM -0400, Carlos Scott wrote: Hello all, It's the first time i try to setup Amanda and i'm a little confused. I don't think i got the changer device idea right. Does the Dell Powervault 132T Tape Library qualify as a changer device? I thought so but the mtx command tells me otherwise: [EMAIL PROTECTED] DailySet1]# /usr/sbin/mtx -f /dev/sg1 inquiry Product Type: *Tape Drive* Vendor ID: 'IBM ' Product ID: 'ULTRIUM-TD2 ' Revision: '37RH' Attached Changer: No You're performing the inquiry on the tape drive itself, not the library. Typically, the drive is SCSI target 1 on the bus, with the library as target 0. Try with '-f /dev/sg0'.
Re: backup Oracle DB at AMANDA server
On Fri, Mar 04, 2005 at 06:07:19PM +0100, Paul Bijnens wrote: Last time I looked at doing backups of Oracle (Ora 6-7-8), I approached it as follows: first set each tablespace in hot backup mode (alter tablespace TS begin backup) then doing a filesystem backup of all the directories with datafiles, using plain amanda DLE's, then setting each tablespace out of hot backup mode, (alter tablespace TS end backup); then force a redo log switch (alter system switch logfile) and then doing a backup of the archived redologs. Ouch. If that database is seeing any signifigant activity during the backup, you're going to be generating *alot* of redo with that approach. Putting the whole database in backup mode at once is typically frowned upon unless you're using something like mirror splitting or snapshots so you can turn backup mode off after a few seconds. Is Oracle 9-10 any different for hot backup mode (i.e. more complicated than it need to be?). Not that I'm aware of. alter tablespace begin backup is still there, and reportedly they've added an alter database begin backup to put all tablespaces in backup mode at once for the snapshot crowd. RMAN is, however, the preferred backup method these days - it's typically much faster than copying the datafile, either cold or in backup mode, and doesn't cause the database to generate additional redo the way backup mode does. Currently, I run RMAN backups of our databases to disk, and let Amanda pick up both the RMAN output and the archive logs. I keep the last three RMAN runs around, plus all archive logs that RMAN hasn't backed up at least 3 times. That way, even if the Amanda run overlaps the RMAN run and a disaster occurs before the next time Amanda runs, I can still restore from the previous RMAN run + archive logs. Unfortunately, this doesn't scale too well, since you need anywhere from 2-3 times as much space for the RMAN output as your database + archive logs require (and I've got nearly as much space taken by archive logs as I have datafiles). For larger databases, I be inclined to go the alter database begin backup + snapshot route.
Re: Installing on SPARC Solaris 8 - ld.so.1 error
On Tue, Feb 15, 2005 at 03:23:27PM -0800, Steve H wrote: Hello all, Has anyone experienced an issue with Solaris 8? I have installed readline, and the libreadline.so.5 is located in /usr/local/lib. When I try to start Amandad, the system throws an error stating: ld.so.1: /usr/local/libexec/amandad: fatal: libreadline.so.5: open failed: No such file or directory Can't quite figure out how to fix this...Any help is appreciated. The location of libreadline.so.5, /usr/local/lib isn't in either of amandad's runtime library search path or the system default library search path. Two options: 1. Set your LDFLAGS environment variable to include -R /usr/local/lib and recompile AMANDA. 2. Run crle -u -l /usr/local/lib to add /usr/local/lib to the system's default library search path.
Re: mounting/identifying a new tape drive
On Thu, Feb 03, 2005 at 12:47:34PM -0500, Jon LaBadie wrote: On Thu, Feb 03, 2005 at 11:53:36AM -0500, Gil Naveh wrote: Hello, I have a Solaris 9 box and we bought a new tape drive model Certance LTO-2. Currently, I am trying to identify the tape drive using amtapetype command but it does not work. For a tape drive to work on Solaris there must be an appropriate entry in the st (Scsi Tape) driver configuration file /kernel/drv/st.conf. On my Solaris 9 system (x86, but it should not matter) there are no entries for 'certance' or for 'ultrium 2' drives. Sometimes I've installed drives that had instructions to edit the file to add driver configuration information for the new drive. Your's didn't? Was it listed by the vendor as Solaris supported? You should normally only need to edit st.conf for drive types not natively supported by the driver. LTO-2 has had native support in Solaris 9 since Jan 2003 (introduced in patch 113324-03, which was obsoleted by 113277-08).
Re: Can Amanda use an Iomega REV drive as a tape?
On Tue, Feb 01, 2005 at 11:42:19PM -0500, Gene Heskett wrote: On Tuesday 01 February 2005 18:42, Tom Simons wrote: Can/should Amanda use an Iomeg REV drive as an output tape? We've got 2 servers both running RedHat AS 3.0, with 35gb 70gb hard drives on each, and we're intersted in running Amanda on one of the servers to back up both ( more servers to follow). The backup server has a 35gb Iomega REV drive, which RedHat sees as /cdrom2. Has anyone used a REV drive with Amanda? I can imagine that it may be possible, with some variation of the FILE: device, and as Jon mentioned, they have a 10 disk changer available which to me, would make it *much* more appealing given a reasonable price for both the drive and the media.. Single drives retail for ~ $350 - $450 depending on type (internal IDE, external USB, etc.). Media lists for ~ $50 ea. The autoloader appears to list for ~ $2200. So the hardware is a bit cheaper than a (new) comparable capacity tape unit, but the media is more expensive. Jon (or anyone else with some thoughts here) how would one go about dealing with the fact that the Iomega drive is probably a random access drive, meaning it would need to use the FILE: device, *and* treat it as a robotic changer mechanism to bring the proper disk into the drive proper? The first thing would be to investigate and find out if the mtx driver can control the robot. Assuming mtx can control the beast, it shouldn't be too difficult to modify chg-zd-mtx to mount and unmount the media. Without the robotics, and just feeding it the disk cartridge by hand, and using the FILE: device, it seems to me that wouldn't be too hard to setup assuming that Tom can build snapshot 2.4.5b1-20041221.tar.gz, obtainable from the amanda.org front page via link near the bottom of the page. For those of us who haven't been keeping up with the betas, what's the must have feature in that one? I've been using 2.4.4p2 with my REV without complaints. Whats the rated read/write speeds on that drive Tom? For amanda to be useable, it needs to be able to do a more or less normal backup in not more than 3-4 hours total elapsed time. Can it fill that sized disk in a reasonable time frame? I'm currently putting about 20GB on there per run in the space of about 3 hours. Mind, that's going straight to tape and with one really slow host (which also happens to be the Amanda server) in the mix. Iomega claims they're 8x faster than tape, with the fine print qualifying that as 8x faster than DDS4. It probably won't beat, say, an LTO-2 for speed.
Re: Can Amanda use an Iomega REV drive as a tape?
On Wed, Feb 02, 2005 at 10:43:50AM -0500, Gene Heskett wrote: On Wednesday 02 February 2005 04:12, Mike Delaney wrote: [...] Has anyone used a REV drive with Amanda? I can imagine that it may be possible, with some variation of the FILE: device, and as Jon mentioned, they have a 10 disk changer available which to me, would make it *much* more appealing given a reasonable price for both the drive and the media.. Single drives retail for ~ $350 - $450 depending on type (internal IDE, external USB, etc.). Media lists for ~ $50 ea. The autoloader appears to list for ~ $2200. So the hardware is a bit cheaper than a (new) comparable capacity tape unit, but the media is more expensive. Humm, thats not too bad, although the $ for the changer would scare this SS recipient off I'm afraid. As would a fifty per disk when the tapelist gets up towards 20 or so. OTOH, with that 36GB capacity, I could do a dumpcycle of 2 days here, so I'd only need 4 or 5. Yeah, running a traditonal Amanda setup with that kind of media cost gets a bit pricey. One thing you could do with them, since they're random access media, is to setup a chg-disk library of several smaller vtapes on each, and treat the REV disks as magazines.
Re: Can Amanda use an Iomega REV drive as a tape?
On Tue, Feb 01, 2005 at 03:42:34PM -0800, Tom Simons wrote: Can/should Amanda use an Iomeg REV drive as an output tape? We've got 2 servers both running RedHat AS 3.0, with 35gb 70gb hard drives on each, and we're intersted in running Amanda on one of the servers to back up both ( more servers to follow). The backup server has a 35gb Iomega REV drive, which RedHat sees as /cdrom2. Has anyone used a REV drive with Amanda? I recently started using one to backup my systems at home (I'm running SuSE 9.1 on the Amanda server). Works fairly well. From the OS's perspective, the REV cartridge looks like a really large DVD-RAM, so for Amanda you'll need to setup vtapes on the cartridges. You might want to install udftools on the server and lay down a new UDF filesystem on the cartridges before trying to use them - I recall getting some odd behavior with virgin cartridges which went away after running mkudffs on them.
Re: amanda change ctime
On Thu, Jan 27, 2005 at 07:01:31AM -0500, Joshua Baker-LePain wrote: On Wed, 26 Jan 2005 at 4:27pm, Nina Pham wrote The files we are backing up are resigned on more than 1 servers, and we want to store that archive on the same place. Therefore we need to mount. As other folks have mentioned, no, you don't. However, what I haven't seen clarified yet is what OS the various servers are running. If some *nix, then install the amanda client there. If 'doze, then amanda can do the backups for you using smbclient (no need for you to mount). In the origional post, she said she was using FC2 systems, which I took to mean Fedora Core 2, i.e. Linux.
Re: amanda change ctime
On Wed, Jan 26, 2005 at 03:38:36PM -0800, Nina Pham wrote: I mount using smbmount Don't do that then. Install Amanda on all of the systems that need to be backed up, and let it work the way it was designed.
Re: amanda change ctime
On Wed, Jan 26, 2005 at 04:26:07PM -0800, Nina Pham wrote: Mike Delaney wrote: On Wed, Jan 26, 2005 at 03:38:36PM -0800, Nina Pham wrote: I mount using smbmount Don't do that then. Install Amanda on all of the systems that need to be backed up, and let it work the way it was designed. The files we are backing up are resigned on more than 1 servers, and we want to store that archive on the same place. Therefore we need to mount. No, you do not. The whole point of Amanda is to backup files on multiple systems across a network to a single place. No network filesystem mounts are required. The server contacts the clients, which backup their files and send the archives back to the server which writes them to tape.
Re: no index records
On Sun, Oct 17, 2004 at 10:25:17PM -0400, Joe Konecny wrote: snip I think I may have found the problem. Somehow I screwed up permissions on /tmp to drwxr-xr-x. Changed to drwxrwxrwx and things look much better. I'll know more after I switch the tape in the morning. /tmp is normally mode 1777, not 0777 (that last 'x' should be a 't').
Re: Newbie questions - Amanda and tapechanger
On Mon, Oct 11, 2004 at 02:45:40PM +0200, Michael Schaller wrote: Am I right: Amanda WILL change tapes AUTOMATICALLY between different DLEs in ONE configuration if the rest of the tape doesn't fit for the next DLE Yes. If runtapes is 1, Amanda will move onto the next tape if a DLE won't fit in the remaining space. What it won't do is put part of that DLE on one tape and part on another. If Amanda hits EOT with runtapes 1, she'll switch tapes and restart taping that DLE from block 0. What happens, if Amanda takes two DLEs in PARALLEL (is that possible??) and these two DLEs together will exceed the tape?? Amanda never tapes two DLEs in parallel. Parallel dumps go to the holding disk and when the dumps are finished they are put on tape in a serial fashion. If a DLE won't fit in the holding disk, it will be dumped directly to tape.
Re: TAPE
On Wed, Sep 22, 2004 at 04:47:06PM -0300, Leandro wrote: I have 2 tapes: Quantum Super DLT 320 HP DDS-3 4MM DAT connected to Sun Enterprise 250 Are these tapes compatible with Amanda? I can't find information about that. Generally speaking, if your OS supports the drives, Amanda does.
Re: Numeric uids
On Mon, Jul 29, 2002 at 05:43:34PM -0700, Nate Eldredge wrote: Summary: Is there a way to make amanda pass arbitrary options to tar, in particular --numeric-owner? It appears, as of 2.4.2p2 anyway, that the arguments to runtar are being hardcoded in sendbackup-guntar.c. I suppose you'll need to patch --numeric-owner into your build of amanda to make it use that option. -- Mike Delaney [EMAIL PROTECTED] ...Microsoft follows standards. In much the same manner that fish follow migrating caribou. Now I have this image in my mind of a fish embracing and extending a caribou. -- Paul Tomblin and Christian Bauernfeind in the SDM
Re: Configure error
On Wed, Jul 17, 2002 at 01:46:30PM -0500, Quinn, Richard C. wrote: Scott Sanders [EMAIL PROTECTED] wrote: Try setting the variable CC=gcc;export CC CC was already set to gcc and /usr/local/bin is listed first in $PATH It sounds like your gcc may have been compiled to use the native SUNW assembler and linker, in which case the (I assume) GNU ld and as in /usr/local/bin won't cut it -- the assembly syntax is different. Make sure the packages listed in http://www.science.uva.nl/pub/solaris/solaris2.html#q6.2 are installed and try it with /usr/ccs/bin ahead of /usr/local/bin in your $PATH. -- Mike Delaney [EMAIL PROTECTED] ...Microsoft follows standards. In much the same manner that fish follow migrating caribou. Now I have this image in my mind of a fish embracing and extending a caribou. -- Paul Tomblin and Christian Bauernfeind in the SDM
Re: Tape Drives, why?
On Sun, Jun 30, 2002 at 01:14:43AM -0700, Anthony A. D. Talltree wrote: 100 gigabyte hard disk is less than $200 Where? I'm not even aware of a 100G disk being sold. Seagate and IBM sell 120 GB ATA drives. Street price is around $120-140. Seagate also has a 180 GB SCSI/FC-AL disk in their catalog, which for the moment is the largest single spindle on the market. Lists for $1800, street price seems to be in the neigborhood of $1300. Worse, tapes don't last, they have a three year shelf life if they are stored properly Say *what*??? This is absurd. Indeed. DLTs claim a projected shelf life of 30 years, however shelf life is really only a concern for archival storage (and after 30 years, finding a drive and a system that will talk to it could be as much of a problem as reading a tape that's degraded over time. I hear the few working 7 tracks left are in fairly high demand.). For a daily backup medium, pass count is much more important. and the tape doesn't physically break when it winds around the spools... ? The only tape medium with any kind of breakage issues of which I'm aware is the TK50, where the hook would sometimes come off. If someone is trying to use a TK50 drive for backups today, they've got bigger problems. Yeah, TK50s are, um, ancient. However, DLTs use the same single reel and hook and loop system as TK50s, so they can fail in the same way. Forunately, the drives are far more reliable in that regard. I've seen only one broken DLT leader so far (knocks on wood). -- Mike Delaney [EMAIL PROTECTED] ...Microsoft follows standards. In much the same manner that fish follow migrating caribou. Now I have this image in my mind of a fish embracing and extending a caribou. -- Paul Tomblin and Christian Bauernfeind in the SDM
Re: runtape question, probably a FAQ
On Thu, May 02, 2002 at 10:49:00AM +1000, Robert Kearey wrote: Is there a way to configure amanda so that runtapes is calculated dynamically to fit in that partciular amdump? Using two or more tapes for a dump is wasteful when there's only 10% of tape used for that dump. The runtapes parameter is an upper bound on the number of tapes amanda _may_ use in a single run, not the number that will be used. If all of the data for a particular run fits on one tape, then only that one tape is used. -- Mike Delaney [EMAIL PROTECTED] ...Microsoft follows standards. In much the same manner that fish follow migrating caribou. Now I have this image in my mind of a fish embracing and extending a caribou. -- Paul Tomblin and Christian Bauernfeind in the SDM
Re: build and install for different machines.
On Wed, Apr 24, 2002 at 06:31:10PM +1000, [EMAIL PROTECTED] wrote: Our shop runs a small number of development systems with compilers, and a larger number of machines on which I will want to install the client only. Furthermore none of the development machines are the backup server. What I want to do is build the client and server pieces (for suns, in case you're wondering) on one machine, and distribute them to where they have to go. I don't need much customisation for each machine, just something I can plonk down and install. There does not appear to be a neat way to build a gzip, tarball or solaris package of the server or the client for installation somewhere else. I don't particularly want to install a development environment on the backup server, and in any case this wouldn't solve the client part. It's really just a matter of making sure that all of the backup tools amanda will be calling on any of the clients (ufsdump, gtar, vxdump, etc.) are present in the same location on the build machine and specifying the configure options (--with-tape-server, --with-tape-device, etc.) to reflect the environment amanda will be running in. Build and install as normal on your build machine, and tar or package up the results. -- Mike Delaney [EMAIL PROTECTED] ...Microsoft follows standards. In much the same manner that fish follow migrating caribou. Now I have this image in my mind of a fish embracing and extending a caribou. -- Paul Tomblin and Christian Bauernfeind in the SDM
