RE: amrecover error did not get a reserved port
John, amrecover: did not get a reserved port: 50014 When compiled I used the flag --with-portrange=5,50100 ... Any suggestions as to what I am doing wrong? You didn't do anything wrong -- I did :-). Like a true professional I waited until I needed to do a restore before testing! So I think I probably beat you there. This is a known problem from about a year ago. Give the following patch a try. It's in the current sources. Did I miss this in the FAQs or should I add this? I didn't see it on the amanda bugs page. Regards, Jim The message has been checked for all known viruses by the Centric Telecom Virus Control Centre. (Powered by Messagelabs)
Re: amanda cycles
You're right. I think it's better to work with amanda numbering the tapes with labels like 1, 2, 3, etc, and not with Monday, Tuesday, etc. I have already considered this option, but we want to be sure of all possibilities, and the option of labelling tapes with the names of the days of the week was one of them. But the second option is better, one tape, one date. It's good Well, thanks to everybody, thanks to amanda developers, at least, amanda is working correctly in our system, a small LAN with GNU/Linux Debian. Free software is always the best option. John R. Jackson wrote: Yes, but my holding-disk has 3500 Mb. The backups are 7-8 Gb. ... The backups are 7-8 GBytes when Amanda is writing to tape. If it detects the tape is bad (including just plain not being there :-) it will fall back to degraded mode and do less work. That's not to say it will fit, but it's not as bad as you think. ... Is there a method for starting a cycle when i want And what would you want Amanda to do? It would essentially have to make up for the missing runs. Since you're skipping two runs, that would make the next run 20+ GBytes. Are your tapes that big? I agree with Joshua that the best approach is probably to let Amanda do what it can without a tape. But another approach would be to just change your crontab to not do the runs on the two missing days. The advantage to letting Amanda try is that you're likely to have some backups laying around if things go bad. I have a feeling you're also working under the impression particular tapes are used on particular days (e.g. the Monday tape is used on Monday). That's not a good way to work with Amanda. Much better is to just number the tapes and Amanda will pick the next one in sequence. It may be that under normal circumstances a particular tape gets used on a particular day, but when exceptions happen (as is coming up for you), Amanda will just slip the tape cycle to accommodate. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Hardware compression (HP DAT 40i users?)
Thanks everybody for your helpful responses. All of them had different and useful tips. I'll try to summarize and add some comments. i) Regarding compression on FreeBSD: thanks John (Merryweath) for reminding me of mt. I have now turned HW compression ON host control ON and I can manage it myself! ii) Thanks Joshua John (Jackson) for the tips on the tapelength when using hardware compression. I'll try to lie to amanda :( for a few runs and see what I get for every fs. iii) After thinking a bit on what Gene wrote regarding hardware compression (Generally speaking, the hardware compression should be disabled.) I can only say that I haven't made a final decision and I'm just doing my experience on this. I thought about leaving the task to the tape drive, mostly because both the client and the server (the only two machines we have) are sometimes running important processes that need CPU resources badly. And even when they're not, the times are not predictable (sometimes we leave things running overnight, for a whole weekend, or even for weeks ...) iv) Regarding what Gene wrote about drives switching compression back on (if they find a compressed tape): AFAIK the HP DAT 40 will read compressed tapes no matter what the compression setting is. (Even if you set the jumpers on the hardware to turn both compression and host control to OFF). But I cannot tell if this means that compression will get turned ON for writes afterward (I haven't actually tested it). And finally v) Gene said: Any partition thats that much gzipped already, should have the compression turned off, doing a straight tar of it. Again, I'm a newbie, and if I decided not to use tar, was not based on my own experience but from what I've read elsewhere. I'd like to know your points here. I have avoided tar, because earlier on when I did backups manually (i.e. without amanda) I had a few problems with tar (FreeBSD tar, v1.11.2), and upon reading several mail archives with the same or similar problems (quitting after too many errors, even when tar started extracting/reading OK) other people suggested avoiding tar in favor of dump. But again, I'm open to be converted back to tar if I can trust it. (I know that while installing amanda's freebsd port, it required gtar-1.13.25 so perhaps I should give now gtar a chance?) Thanks again everybody, Fernan
Gnu-tar exclusion lists worked...
Hi! Thanks to Jon LaBadie and John R. Jackson for helping me get gtar exclusion lists up and running -- it seems to have worked! Ricky - Richard MorseSystem Administrator MGH Biostatistics Center 50 Staniford St. Rm 560 [EMAIL PROTECTED] 617/724-9830
Does anybody purge old index files.....
Reading John's excellent chapter got me to thinking...I should purge old index files as well after I have completed my tape rotation. Since once that tape is overwritten that index in null and void. Can anybody contradict that thinking. Don
help had to reconfig disks on a server
Title: help had to reconfig disks on a server One of my servers suffered a failure yesterday and out of that I had to move some disks around but now amanda is going to think they're new disks. For example the old disk was /dev/vx/dsk/rootdg/Compuset and it's now /dev/vx/dsk/sys_dg/Compuset. Basically changed from the rootdg to the sys_dg which shouldn't be a big deal but now amanda thinks they're new disks and will try to do 0 level dumps at the same time on all of them. Any Ideas? Trevor.
Re: help had to reconfig disks on a server
You could try copying the info file of the old name to the info file of the name. I'm not sure if you would need to adjust the /etc/dumpdates as well on the server though. Just a thought... Stott, Trevor wrote: One of my servers suffered a failure yesterday and out of that I had to move some disks around but now amanda is going to think they're new disks. For example the old disk was /dev/vx/dsk/rootdg/Compuset and it's now /dev/vx/dsk/sys_dg/Compuset. Basically changed from the rootdg to the sys_dg which shouldn't be a big deal but now amanda thinks they're new disks and will try to do 0 level dumps at the same time on all of them. Any Ideas? Trevor.
Re: help had to reconfig disks on a server
On Wed, 27 Mar 2002 at 10:26am, Stott, Trevor wrote
One of my servers suffered a failure yesterday and out of that I had to move
some disks around but now amanda is going to think they're new disks. For
example the old disk was /dev/vx/dsk/rootdg/Compuset and it's now
/dev/vx/dsk/sys_dg/Compuset. Basically changed from the rootdg to the
sys_dg which shouldn't be a big deal but now amanda thinks they're new disks
and will try to do 0 level dumps at the same time on all of them.
Any Ideas?
A few.
1) Just let it happen. Amanda will do as many level 0s at a time as it
can fit, and will get the rest over the next few nights. Pro: Little
effort on your part. Cons: Missed backups for a few nights, disparate
histories of the two filesystems.
2) Port the old history (of rootdg) to sys_dg, i.e. change the name
by which amanda knows these filesystems. This isn't as easy as it seems
(although I've done it once, going from device names to mount points).
Quoting John Jackson (from last May):
\begin{quote}
Here's what you need to do:
* cd to your curinfo directory, then into the host directory.
Rename the disk directory to the new name, converting all '/'
characters to '_'. For instance, /usr/local would become
_usr_local.
* Do the same thing in the index directory, if you have that
enabled.
* Now the icky part. Hand edit (sorry) all the log.MMDD.NN
files and change the disk name to the mount point name.
* And, of course, change the disklist. And, also of course, run
amcheck (the -c and -l options are sufficient) to make sure everything
is happy.
\end{quote}
3) This might be a good time to use option 2, but convert to using mount
points in the disklist. This will avoid this problem next time the
physical device changes out from under a disklist entry.
--
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University
Error in Debian
I´am running amanda 2.4.2p2 in debian linux (installing from apt-get ) My error is : ERRROR: backup: [access as backup not allowed from backup@backup] amandahostsauth failed Who is my problem? Who is the diference in Debian and other linux distributions?
compression fast: client does compression?
I am trying to get Amanda clients to not do copression, but have the server do the compression. I had thought that this would happen by changing the dumptype record for comp-root-tar to have: compress server fast instead of compress client fast When I watch the clients (Linux, OSF/1) with top I see gzip max out the processor on the client still. I've looked around as best as I can but I can't find documentation on the dumptype fields other than in amanda.conf. If someone could point me to the documentation for this and/or tell me how to do what I want I'd be greatly appreciative. Thanks, Steve P.S. Server = Amanda-2.4.2p2 on IRIX 6.5.13m _ Steve Cousins Email: [EMAIL PROTECTED] Research AssociatePhone: (207) 581-4302 Ocean Modeling Group School of Marine Sciences 208 Libby Hall University of Maine Orono, Maine 04469
Re: Error in Debian
Hi Pablo, I believe the source of the error you mention is from the client. You may need to check the .amandahosts file on the client for the user under which the client runs. In other words, if in your INETD (or XINETD) the amanda client runs as backup, the .amandahosts in backup's home directory probably needs to be adjusted. I hope this helps you! Jeff On Wed, 2002-03-27 at 12:06, Pablo Miscevich wrote: I´am running amanda 2.4.2p2 in debian linux (installing from apt-get ) My error is : ERRROR: backup: [access as backup not allowed from backup@backup] amandahostsauth failed Who is my problem? Who is the diference in Debian and other linux distributions? -- ++ | Jeffery Smith - Systems Administrator - [EMAIL PROTECTED] | | Sky Computers, Inc. (www.skycomputers.com) | ++
Re: Error in Debian
On Wed, 27 Mar 2002 at 2:06pm, Pablo Miscevich wrote I´am running amanda 2.4.2p2 in debian linux (installing from apt-get ) One should always compile amanda from source. A lot of stuff gets compiled in, and it helps one figure out what's going on. My error is : ERRROR: backup: [access as backup not allowed from backup@backup] amandahostsauth failed Who is my problem? This is a common problem -- check FAQ-O-Matic (available via www.amanda.org). Is there a .amandahosts file in the home dir of the amanda user on the client? Or you may have DNS issues. Who is the diference in Debian and other linux distributions? I have no idea. Why does it matter? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Error in Debian
Pablo Miscevich wrote: I´am running amanda 2.4.2p2 in debian linux (installing from apt-get ) My error is : ERRROR: backup: [access as backup not allowed from backup@backup] amandahostsauth failed Who is my problem? Who is the diference in Debian and other linux distributions? I use Debian but build from source, that way you get the build options that you want. If you want to use the pre-built packages, you should check with the package maintainer to find out what build options he used. -- Terri Eads Systems Administrator [EMAIL PROTECTED] Research Applications Program (303) 497-8425 National Center for Atmospheric Research
restore error in amrecover, 2.4.2p2 on DEC UNIX 4
Using amrecover in 2.4.2p2 on Digital Unix 4.0, I'm getting a restore error. In the amrecover log I see: Exec'ing /sbin/restore with arguments: restore xbf 2 - /amanda_dev.orig amrecover: pid 4113 finish time Wed Mar 27 10:48:36 2002 And I get a message printed to screen: Block size must be a positive integer I'm trying to track this down but am getting stymied by how to do so. I would like to attempt to run /sbin/restore by hand but am not sure how to specify the image on stdin. Particularly, I'm not sure which image I'm to provide considering the image files reside remotely having been created via amanda. Advice and abuse are equally (well, almost) welcome, Eric Zylstra
Re: Error in Debian
On our systems, we ran into debian creating a local user named backup. That caused problems with our NIS backup user. So we deleted the local and everything worked. I´am running amanda 2.4.2p2 in debian linux (installing from apt-get ) My error is : ERRROR: backup: [access as backup not allowed from backup@backup] amandahostsauth failed Who is my problem? Who is the diference in Debian and other linux distributions?
Re: Hardware compression (HP DAT 40i users?)
v) Gene said: Any partition thats that much gzipped already, should have the compression turned off, doing a straight tar of it. Again, I'm a newbie, and if I decided not to use tar, was not based on my own experience but from what I've read elsewhere. Not trying to speak for Gene, but I don't think he was talking about tar vs. dump. I think he was pointing out that if your data is already compressed, sending it a tape drive that was set up to do hardware compression is not going to work well. Compressing compressed data a second time usually ends up expanding it. I use hardware compression for the reasons you mentioned -- it would kill my systems to chew up that much CPU. But if you have a wide variety of data (some file systems with lots of text that compresses really well, and others with already compressed data), then using software compression with Amanda has the major advantage that you can pick to compress or not on a file system by file system basis. I'd like to know your points here. I have avoided tar, because earlier on when I did backups manually (i.e. without amanda) I had a few problems with tar (FreeBSD tar, v1.11.2) ... Tar vs dump is a periodic war on this list. Rather than start that up yet again :-), I suggest you do one of two things: * Use what you're comfortable with regardless of what anybody else says :-) * Read through the archives for some of the pros and cons of both. Fernan John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amrecover error did not get a reserved port
Like a true professional I waited until I needed to do a restore before testing! ... A real pro! :-) This is a known problem from about a year ago. ... Did I miss this in the FAQs or should I add this? I didn't see it on the amanda bugs page. Well, the theory was that it wouldn't be years between Amanda releases. Sigh. Feel free to add it to the FAQ (make sure you mention 2.4.2p2 -- I don't think it was there prior to that and hopefully is gone afterward). You're right that it probably should also go on the patches page. It's just a matter of remembering to do it and finding the time. Jim John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Does anybody purge old index files.....
...I should purge old index files as well after I have completed my tape rotation. ... Amanda does this for you via a program called amtrmidx that is called at the end of every amdump. It figures out how long the tape cycle is, goes back to the level 0 preceeding that date, then throws away everything older than that. So you may still see some stuff in an index that is no longer valid (on tape), but the picture (directory tree) will still be complete. Don John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amrecover from holding disk in 4.2.2
If I issue the command as you've given it above, I get the same block size error. ... Good. That means you have a valid test case. If I change the 2 to a 4, it does the same. ... OK. If I remove the b and the 2 all-together, it them waits for the image file from stdin (I guess). ... OK. Then 'b'/'2' is evil for your restore (miserable vendors :-). I'm a little ignorant as far as `restore` goes and am not sure how to feed it the image file in this situation. It's not really important as we're just trying to figure out the command line syntax. But if you wanted (needed) to do the real thing, it would be something like: ssh amanda-server /path/to/amrestore -p $TAPE the-client the-disk \ | /sbin/restore xf - /file/to/restore ... Or you could change 'x' to 'i' and leave off the files to restore. That would put you in an interactive session where you could cd around and add what you wanted to be extracted (much like amrecover). I'm sorry about needing to be spoon fed. ... Not a problem (not even close). This is Digital Unix 4.0 (with the dump patch applied). It is using the plain system dump/restore as far as I know--/sbin/dump and /sbin/restore. Not sure what the dump patch is, but be that as it may ... The reason I asked about vdump is that the most recent Amanda sources (actually, I did this quite a while ago) have code that says if we are using vrestore, don't use the 'b' option, i.e. the exact fix you need. But that is based literally on the restore program being named vrestore, which doesn't seem to match your situation. So it looks like Amanda needs yet another special vendor case for this. When you ran ./configure, at the top it said what type of OS you're using (as far as ./configure is concerned). For instance: checking host system type... sparc-sun-solaris2.6 checking target system type... sparc-sun-solaris2.6 checking build system type... sparc-sun-solaris2.6 What did yours say? EZ John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
tapeless backup with amanda
Has anyone out there successfully configured amanda to backup to a spare hard drive without backing up to tape? Thanks in advance. - db
new to amanda - couple of questions
Hi all, I've heard of Amanda for some time, but am just now starting to look at it as a potential backup solution. From what I've read so far, I'm not 100% sure it will be of a big benefit to us. Here's what we are looking at it for: - single system (SPARCServer 1000) - using Veritas Volume Manager - DLT 7000 tape drive - approx. 90GB of data to be backed up (we can reduce it below 80GB if necessary to facilitate a single tape backup as we have data on CD's) - majority of the data is Oracle database Currently using tar with -X (exclude) and -I (Include) options. My question is: Since we are looking at a single system, is there a benefit to implementing Amanda as our backup solution over tar? There is no plan on expanding our backup scope from the single system in the foreseeable future. Thanks, Ron D.
Re: compression fast: client does compression?
Thanks very much John. The amadmin command helped out a lot. I found that the one client that I was testing was still set to comp-user-tar. Changing these to comp-root-tar fixed it for me. Sorry for wasting your time. My eyes saw what they wanted to in disklist I guess. It is working very well now. The clients are down to about 10% CPU usage combined between gtar and sendbackup now. One user with an old OSF/1 machine is very happy that I'm not chewing up as much CPU saving his data. Thanks very much for your help. I'll remember to search further in man amanda too! Steve _ Steve Cousins Email: [EMAIL PROTECTED] Research AssociatePhone: (207) 581-4302 Ocean Modeling Group School of Marine Sciences 208 Libby Hall University of Maine Orono, Maine 04469 On Wed, 27 Mar 2002, John R. Jackson wrote: I am trying to get Amanda clients to not do copression, but have the server do the compression. I had thought that this would happen by changing the dumptype record for comp-root-tar to have: compress server fast instead of compress client fast That should have done it, assuming your disklist told Amanda to use comp-root-tar as the dumptype, or inherited comp-root-tar and did not override the setting. When I watch the clients (Linux, OSF/1) with top I see gzip max out the processor on the client still. ... Try this on the server: amadmin config disklist client disk That will give you a listing of the various dumptype options. You should see something like this: compress SERVER FAST If you still see: compress CLIENT FAST then you're probably not getting the dumptype you think you are. I've looked around as best as I can but I can't find documentation on the dumptype fields other than in amanda.conf. They are all in the amanda(8) man page. Steve John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: tapeless backup with amanda
On Wed, 27 Mar 2002 21:45:26 + (GMT), Dan Barnes [EMAIL PROTECTED]|said: |Has anyone out there successfully configured amanda to backup to a |spare hard drive without backing up to tape? not a solution to your problem (sorry), but a question in regards to media: is there any chance of getting Amanda to back up to CD-R or even DVD-R media? -- Malcolm HerbertThis brain intentionally [EMAIL PROTECTED]left blank
Re: tapeless backup with amanda
On Wednesday, March 27, 2002, at 01:45 PM, Dan Barnes wrote:
Has anyone out there successfully configured amanda to backup to a spare
hard drive without backing up to tape?
I've set up a system using 2.4.2p2 to backup to nfs mounted drive space
just recently. If you are able to use 2.4.3, there is a setting to save
to disk. Check the docs or the mail archives.
For 2.4.2p2--
In your configuration file (amanda.conf):
1. set tapedevice to no-such-device,
2. set rawtapedev to no-such-device,
3. set changerdev to no-such-device,
4. set tapetype to DISKSAVE,
5. define tapetype DISKSAVE (this is mine, tweak as is appropriate):
define tapetype DISKSAVE {
comment Fake tape description for save to disk
length 1000 gbytes
filemark 0 kbytes
speed 2000 kbytes
}
6. modify the holding disk hd1 so it points to your backup disk, and
make its use value to be -1 (it will use the whole space for holding),
7. set reserve to 0.
I think that covers all of the unique needs of saving to disk vs. tape.
The remaining configuration is the same as if you were using tape.
Re: new to amanda - couple of questions
I've heard of Amanda for some time, but am just now starting to look at it as a potential backup solution. ... Welcome! From what I've read so far, I'm not 100% sure it will be of a big benefit to us. ... That's always a possibility, and you're wise to look before you leap. Currently using tar with -X (exclude) and -I (Include) options. My question is: Since we are looking at a single system, is there a benefit to implementing Amanda as our backup solution over tar? ... There will be several benefits. Amanda is primarily a backup manager. It is not actually backup software. In other words, Amanda will run tar for you, it won't replace tar. That's a big advantage over commercial software (although not over do it yourself). Even if you don't have a single iota of Amanda software laying around after a major disaster, you'll still be able to process the backup images from your tapes. All it takes is standard OS tools (primarily dd and mt, and whatever restore program matches what you used to create the dump image, e.g. tar). So what you'll get out of using Amanda is a lot of administration help. Such as: * Daily summary reports to make sure everything that is supposed to get backed up, did get backed up, and did so without problems. * A tool to verify a tape is readable. * Tools to remember what tapes have what backup images. * Intelligent scheduling of backup levels (incrementals vs. fulls). * Intelligent tape management (won't overwrite an active tape, etc). * Support for unattended backup runs. * Error handling support for when a run goes bad for any number of reasons. * And probably several other things that I don't remember at the moment. There is no plan on expanding our backup scope from the single system in the foreseeable future. Yeah, yeah. That's what they all say :-). Then there's just this one other machine to add. And oh, yeah, maybe that one, too. And how about those sitting off in that corner ... :-). But seriously, you're right that on first glance, Amanda appears to be oriented toward multiple clients. However it also has a lot to offer for a single system. Our three largest nightly backups are essentially single system setups. Ron D. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Hardware compression (HP DAT 40i users?)
On Wednesday 27 March 2002 09:03 am, Fernan Aguero wrote: Thanks everybody for your helpful responses. All of them had different and useful tips. I'll try to summarize and add some comments. i) Regarding compression on FreeBSD: thanks John (Merryweath) for reminding me of mt. I have now turned HW compression ON host control ON and I can manage it myself! ii) Thanks Joshua John (Jackson) for the tips on the tapelength when using hardware compression. I'll try to lie to amanda :( for a few runs and see what I get for every fs. iii) After thinking a bit on what Gene wrote regarding hardware compression (Generally speaking, the hardware compression should be disabled.) I can only say that I haven't made a final decision and I'm just doing my experience on this. I thought about leaving the task to the tape drive, mostly because both the client and the server (the only two machines we have) are sometimes running important processes that need CPU resources badly. And even when they're not, the times are not predictable (sometimes we leave things running overnight, for a whole weekend, or even for weeks ...) iv) Regarding what Gene wrote about drives switching compression back on (if they find a compressed tape): AFAIK the HP DAT 40 will read compressed tapes no matter what the compression setting is. (Even if you set the jumpers on the hardware to turn both compression and host control to OFF). But I cannot tell if this means that compression will get turned ON for writes afterward (I haven't actually tested it). That was what I found in the case of the seagate changer in this machine. It may be possible to turn it off, but it would require that the compression off command be issued somehow after the header read and rewind, and before the subsequent write operation to over-write the header. I've even fooled around using dd to rewrite the header read, set it off, and write it back. No luck with this particular drive. And the compression is slowly contaminating the rest of my tapes. :((( And finally v) Gene said: Any partition thats that much gzipped already, should have the compression turned off, doing a straight tar of it. Again, I'm a newbie, and if I decided not to use tar, was not based on my own experience but from what I've read elsewhere. I'd like to know your points here. I have avoided tar, because earlier on when I did backups manually (i.e. without amanda) I had a few problems with tar (FreeBSD tar, v1.11.2), and upon reading several mail archives with the same or similar problems (quitting after too many errors, even when tar started extracting/reading OK) other people suggested avoiding tar in favor of dump. But again, I'm open to be converted back to tar if I can trust it. (I know that while installing amanda's freebsd port, it required gtar-1.13.25 so perhaps I should give now gtar a chance?) Yes. That new a tar has no known gotchas. One or 2 of the earlier 1.13 issues had some real killers. :)) I'm a tar fan, mainly because tar doesn't care about the filesystem, ext2, ext3, reiserfs, etc. Dump is based on the inode structure of the filesystem I believe, and therefore not as 'portable'. Speedwise, on todays hardware, its a moot point IMO. YMMV as usual. Cheers, Gene
Win32 Amanda Client on Sourceforge?
Hi! How stable is the Win32 Amanda Client found on SourceForge? I have a few NT/Win2K boxes that I would like to add to my backup, and I'm looking at the different options available... Thanks, Ricky - Richard MorseSystem Administrator MGH Biostatistics Center 50 Staniford St. Rm 560 [EMAIL PROTECTED] 617/724-9830
Re: Hardware compression (HP DAT 40i users?)
On Wednesday 27 March 2002 04:07 pm, John R. Jackson wrote: v) Gene said: Any partition thats that much gzipped already, should have the compression turned off, doing a straight tar of it. Again, I'm a newbie, and if I decided not to use tar, was not based on my own experience but from what I've read elsewhere. Not trying to speak for Gene, but I don't think he was talking about tar vs. dump. I think he was pointing out that if your data is already compressed, sending it a tape drive that was set up to do hardware compression is not going to work well. Compressing compressed data a second time usually ends up expanding it. That was what I was trying to say. Also, again generally speaking, the level of compression that is done by the hardware chips can average 2 to 1 under /ideal/ conditions as the hardware is usually some variation of the 2-7 RLL method, very easy to do at high rates of speed in hardware. Some of my more sparsely filled partitions can be set for 'compress server best', with the output of a full level 0 being reduced to less than 15% of the original size before compression. My downloads directory, full of tar.gz and .bz2 files will expand 180+% using the same compression setting. Use amanda's emailed report to see if the compression should be turned off for that entry in the disklist. Unforch, when the drive is doing the compression, you have no handy compression ratio feedback mechanism and must rely on your own experiences. And with the drive doing the compressing, amanda cannot develop any info about how big the tape might be in terms of uncompressed input data, it simply measures what it puts into the pipe. With amanda doing the compression, she measures the tape capacity in terms of the already compressed data because its that data that actually goes onto the tape, not the much larger input data. So a 20gig tape will usually hit 18 to 19 at least, but thats in terms of already compressed data. OTOH, using a different program that did its own compression, I've watched in dis-belief as 11 gigs worth of text type data actually fit a DDS-2 120 meter tape, normally rated for 4 gigs. I use hardware compression for the reasons you mentioned -- it would kill my systems to chew up that much CPU. But if you have a wide variety of data (some file systems with lots of text that compresses really well, and others with already compressed data), then using software compression with Amanda has the major advantage that you can pick to compress or not on a file system by file system basis. I'd like to know your points here. I have avoided tar, because earlier on when I did backups manually (i.e. without amanda) I had a few problems with tar (FreeBSD tar, v1.11.2) ... Tar vs dump is a periodic war on this list. Rather than start that up yet again :-), I suggest you do one of two things: * Use what you're comfortable with regardless of what anybody else says :-) * Read through the archives for some of the pros and cons of both. But seperate the old version squawks from the current version squawks. Somebodies 2 year old lamenting about 1.11-xx of tar has no validity to what tar-1.13-25 does today. Put another way, consider what you read only if it applies to the version you have on hand. And 98% of the time, newer is generaly better. The other 2% will eat your lunch and leave you to pay the bill anyway. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 98.7+% setiathome rank, not too shabby for a hillbilly
