Re: amlabel & ftape
hello johannes, tx for the hint, but it won't work. still the same probs. if you send me the configuration, i will appreciate it. greets stefan
Re: amcheck output
On Tue, Apr 23, 2002 at 09:43:13PM -0600, Trevor Morrison wrote: > HI, > > I am running amcheck on my backup called Daily and I am getting the > following output: > > Amanda Tape Server Host Check > - > ERROR: tapelist dir /usr/local/share/amanda/Daily: not writable > Holding disk /amanda: 404144 KB disk space available, that's plenty >(expecting a new tape) > NOTE: skipping tape-writable test > NOTE: info dir /usr/local/share/amanda/Daily/curinfo: does not exist > NOTE: it will be created on the next run > NOTE: index dir /usr/local/share/amanda/Daily/index: does not exist > Server check took 9.687 seconds > > Amanda Backup Client Hosts Check > > ERROR: stud.hailix.com: [can not read/write > /usr/local/var/amanda/gnutar-lists/.: No such file or directory] > Client check: 1 host checked in 0.028 seconds, 1 problem found > > I am using the root-tar dump type. I just installed the gnu tar and > reconfigured amanda. I put no where in the amanda.conf file any such > directory /usr/local/var/amanda/gnutar-lists. Amanda and associated > progarms are ing /usr/local/etc/amanda. Any thoughts? TIA Amanda uses that directory for gnutar during the planning/estimate phase. It will be created. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Automatically skip/reject too-large dumps?
Hi, Is there some way I can tell amanda not to even try a dump which exceeds the tape capacity? If not, can I tell amanda to just give up on any disk which has a tape write fail (because the dump is too big)? Thanks!! David _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com
Couple of Log File Questions
A couple of questions from my log file: planner:RDEV_PREFIX="/dev/r" DUMP="/sbin/dump" planner:RESTORE="/sbin/restore" GNUTAR="/usr/bin/tar" Should I be using gtar instead? (http://www.amanda.org/cgi-bin/fom?_recurse=1&file=7#file_10) How do I change this setting? planner:DEFAULT_CONFIG="DailySet1" My amanda.conf has labelstr "^daily[0-9][0-9]$*" - where is this DailySet1 coming from? planner:DEFAULT_TAPE_DEVICE="/dev/null" HAVE_MMAP HAVE_SYSVSHM My amanda.conf has tapedev "/dev/nrsa0" ... what gives? got result for host client.agic.ne.jp disk /usr: 0 -> -1K, -1 -> -1K, -1 -> -1K Is this bad? And the failure that I've been getting: getting estimates took 0.183 secs FAILED QUEUE: 0: client.agic.ne.jp /usr DONE QUEUE: empty ANALYZING ESTIMATES... planner: FAILED client.agic.ne.jp /usr 0 [disk /usr offline on client.agic.ne.jp?] Any suggestions? Shawn
amcheck output
HI, I am running amcheck on my backup called Daily and I am getting the following output: Amanda Tape Server Host Check - ERROR: tapelist dir /usr/local/share/amanda/Daily: not writable Holding disk /amanda: 404144 KB disk space available, that's plenty (expecting a new tape) NOTE: skipping tape-writable test NOTE: info dir /usr/local/share/amanda/Daily/curinfo: does not exist NOTE: it will be created on the next run NOTE: index dir /usr/local/share/amanda/Daily/index: does not exist Server check took 9.687 seconds Amanda Backup Client Hosts Check ERROR: stud.hailix.com: [can not read/write /usr/local/var/amanda/gnutar-lists/.: No such file or directory] Client check: 1 host checked in 0.028 seconds, 1 problem found I am using the root-tar dump type. I just installed the gnu tar and reconfigured amanda. I put no where in the amanda.conf file any such directory /usr/local/var/amanda/gnutar-lists. Amanda and associated progarms are ing /usr/local/etc/amanda. Any thoughts? TIA Trevor
Re: Over large level 1 dumps
On Tuesday 23 April 2002 06:33 am, Niall O Broin wrote: >I'm just starting using Amanda (hence the level of questions :-) > ) and I currently am backing up 4 filesystems on 2 hosts though > I want to increase this as soon as I'm happy with what's going > on. I'm currently puzzled about the size of level 1 backups. > Look at these two extracts from mail reports: > > >Makalu TIZ AMANDA MAIL REPORT FOR April 16, 2002 > >DUMP SUMMARY: > DUMPER STATS > TAPER STATS HOSTNAME DISKL ORIG-KB OUT-KB COMP% > MMM:SS KB/s MMM:SS KB/s -- > - moca 26593602659360 -- 13:063385.2 30:251457.5 Unforch, my email agent, kmail, insists on screwing with the format when I'd druther it didn't. The above error is because in server-src/reporter.c, the format is apparently way old, and not up to the sizes shown by modern multigigabyte systems. The 26593602659360 above s/b broken into 2659360 2659360 so that the original KB and out-KB stats are seperated by a space. Up until the most recent 2.4.3b3 build, I've been editing repo > > >Kindest regards, > > > >Niall O Broin rter.c to fix that before I build each new version. Unforch, reporter.c seems to have been rather heavily modified, and an admittedly very cursory glance at the new code hasn't shown me where to fix it if indeed it still needs fixed. That will have to wait till I see the report from tonights backup as I built that version after last nights backup had already run. There are a couple of other places in the reports columnnar format that also needed the 'space' value in the older code changed to a one from a zero in order to insert that missing space thats used in case the numbers get big. Apparently that part of the code has been re-written, and will hopefully no longer need to be massaged by each builder, but that thumping sound you hear is me knocking on wood of course :-) moca > /boot 04384 4384 --0:0014986.3 0:13 > 339.3 pumori / 0 40461764046176 -- Same here, it should be 4046176 4046176 and... > 17:52 3773.5 54:45 1231.5 pumori /boot 03552 > 3552 --0:014089.4 0:05 713.0 > > >Makalu TIZ AMANDA MAIL REPORT FOR April 23, 2002 > >DUMP SUMMARY: > DUMPER STATS > TAPER STATS HOSTNAME DISKL ORIG-KB OUT-KB COMP% > MMM:SS KB/s MMM:SS KB/s -- > - moca / > 1 2671232 2671232 --8:43 5109.6 N/A N/A moca > /boot 04384 4384 --0:0010109.8 N/A > N/A pumori / 1 4047968 4047968 -- > 15:51 4256.4 N/A N/A pumori /boot 03552 > 3552 --0:016 062.2 N/A N/A > >(Note that there were intervening dumps, but 23 had both / > filesystems at level 1 and I went back to 16 to get both at > level 0. Why on earth are the backups at level 1 bigger than > those at level 0 ? Note that these are both Linux boxes so a > substantial chunk of / is the OS installation and associated > files and there simply hasn't been that much changed on those > boxes. > >I'm using GNU tar version 1.3.18 and with the recent discussion, > I intend to update that today to 1.3.25 from the FSF > development box. > >A second question, while I have your attention. Observe how the > some of the figures in the report run together - is the layout > of this controllable via a template ? The output is 73 > characters so there could be a couple more spaces inserted and > still stay < 80 characters which I imagine is desired. Since you are reading it with the 'mail' command, the 80 column requirement is entirely between you and the current screen size setting and font in use when running X. I've got screen width for nearly 200 chars here. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 98.8+% setiathome rank, not too shabby for a hillbilly
amcheck
When i run amcheck on the tape server (Red Hat 7.1) I get the following message: Amanda Tape Server Host Check - Holding disk /bfd: 33171048 KB disk space available, that's plenty amcheck-server: slot 2: date 20020418 label DailySet102 (first labelstr match) NOTE: skipping tape-writable test Tape DailySet102 label ok Server check took 13.552 seconds Amanda Backup Client Hosts Check ERROR: bzncs03: [could not access sda1 (sda1): No such file or directory] Client check: 2 hosts checked in 0.046 seconds, 1 problem found (brought to you by Amanda 2.4.2p2) this is run as user amanda, who is in groups backup and disk the permisssions on sda1 (mounted on /): brw-rw1 root disk 8, 1 Mar 23 2001 /dev/sda1 the permisssions are the same on sda5, which reports no errors: brw-rw1 root disk 8, 5 Mar 23 2001 /dev/sda5 in /tmp/amanda the selfcheck.X.debug: selfcheck: debug 1 pid 3477 ruid 999 euid 999 start time Tue Apr 23 15:02:18 2002 /usr/local/libexec/selfcheck: version 2.4.2p2 selfcheck: checking disk sda5 selfcheck: device /usr selfcheck: OK selfcheck: checking disk sda1 selfcheck: device sda1 selfcheck: could not access sda1 (sda1): No such file or directory selfcheck: pid 3477 finish time Tue Apr 23 15:02:18 2002 I do not get any errors from clients with sda1 mounted an /. I am seeing no errors in /var/log/messages Any ideas why I am getting this error? -- Michael Hall, [EMAIL PROTECTED] Systems Administrator Zoot Enterprises Inc. www.zootweb.com 1115 N. 7th Avenue, Bozeman, MT 59715 406-586-5050 ext: 270 FAX: 406-586-8005
Re: Problem with amrecover + chg-scsi
"Patrick J. LoPresti" <[EMAIL PROTECTED]> writes: > The problem here is pretty obvious: amidxtaped is using the tapedev of > "0" as the tape device, instead of the true device specified in the > changerfile as chg-scsi expects. I found a solution: The "-d" option to amrecover lets me override tapedev. This is a little clunky, perhaps, but better than running amrestore by hand. I guess I should try more stuff before bothering the mailing list. My apologies for the noise. - Pat
Problem with amrecover + chg-scsi
I am using Amanda 2.4.2p2 with a 96 slot, 4 drive tape library (Sun StorEdge L3500). My operating system is Red Hat Linux 7.2, although I doubt it matters. In the documentation file TAPE.CHANGERS, I read this section: Now there is another way, to get the chg-scsi a little bit more flexible. If you use only one digit in the `tapedev' parameter, the chg-scsi expects that changerfile points to a real configuration file, not only a counting file. [etc.] This sounded like exactly what I want, so I am using it. That is, in my various amanda.conf files, I have lines like these: tpchanger "chg-scsi" tapedev "1" changerfile "/etc/amanda/chg-scsi.conf" ...and then the real configuration for the tape device appears in some section of /etc/amanda/chg-scsi.conf. (The particular feature I like is limiting Amanda to using only certain slots for a configuration. I would not want Amanda to scan all 96 slots looking for something.) This works great for doing backups. But today I decided to test a restoral using amrecover. This failed at "extract", with the following lines at the tail of the amidxtaped.debug file: Ready to execv amrestore with: path = /usr/sbin/amrestore argv[0] = "amrestore" argv[1] = "-h" argv[2] = "-p" argv[3] = "0" argv[4] = "kingtut" argv[5] = "^/dev/sda1$" argv[6] = "20020415" amrestore: could not open tape 0: No such file or directory amidxtaped: amrestore terminated normally with status: 2 amidxtaped: could not stat 0 could not stat 0 amidxtaped: pid 2220 finish time Tue Apr 23 14:44:58 2002 The problem here is pretty obvious: amidxtaped is using the tapedev of "0" as the tape device, instead of the true device specified in the changerfile as chg-scsi expects. I am curious whether other people have seen this problem, and if anyone can suggest a solution. Thanks! - Pat
Re: What to do when tape is full?
--On Tuesday, April 23, 2002 19:23:50 +0100 Niall O Broin <[EMAIL PROTECTED]> wrote: > On Tue, Apr 23, 2002 at 12:23:19PM -0400, Jon LaBadie wrote: > >> > > Or leave the tape out of the drive and let it go to to the holding disk, >> > > then amflush whenever you have a full tapes worth. >> > >> > Will that work ? When I use amflush I get given a list of days on which >> > amdump ran without a tpe for whatever reason. Then I must choose one of >> > those days and that set of backups is flushed to the tape. To get two or >> > more days onto one tape Amanda would have to support append :-) >> > >> >> You are also given the choice of "ALL". > > For some reason, I thought that if I picked ALL it would do the flush one > day at a time, asking for a different tape each time. If instead it flushes > ALL onto one tape then that does effectively give you a way of maximising > tape usage, if you're that concerned. However, you'd need to be rather > careful that you didn't end up with too much data held. ALL will try to move every dump on the holding disk to the same tape. Amanda only removes files from the holding disk that have been written successfully to tape, so if it hits EOT during an amflush, the failed dump will still be in the holding disk so you can change tapes and run amflush again or wait for more to accumulate. If your holding disk is RAIDed in a way to provide redundancy, it should be fairly safe to leave some data there, since you would have to have both a RAID failure and lose the original file at the same time. Personally I wouldn't do it as a general practice, but it is a nice feature to have if you need it (like waiting for a failed drive to be replaced). Frank -- Frank Smith[EMAIL PROTECTED] Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Re: What to do when tape is full?
On Tue, 23 Apr 2002 at 7:23pm, Niall O Broin wrote > For some reason, I thought that if I picked ALL it would do the flush one > day at a time, asking for a different tape each time. If instead it flushes > ALL onto one tape then that does effectively give you a way of maximising > tape usage, if you're that concerned. However, you'd need to be rather > careful that you didn't end up with too much data held. If you do (end up with too much data), amflush will simply let you know that it hit EOT, tell you what made it to tape, and tell you that you need to run 'amflush' again. > > Let several days worth accumulate then try it and let us know. > > No thanks - you can play with your company's data if you like :-) Indeed. "Maximizing" tape usage this way makes several days worth of backups susceptible to a disk failure. IMO, that's Bad. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Amanda + solaris
Hi, On Tue, Apr 23, 2002 at 03:35:34PM +0200, Ryszard Kluza wrote: > Hello > > I have Sun E250 with Solaris 7 > > Tape library Adic FastStore22 > > And amanda > > How I have to configure amanda and solaris to work together, > > What kind of driver I need to instal on Solaris I'm not sure if solaris have already the sgen driver. If no check the docs directory and there the file TAPE.CHANGERS on what you need for solaris without the sgen driver. In this doc you will find also some notes on how to configure the sgen driver. Hope this helps for the first steps. Thomas -- --- | Thomas Hepper[EMAIL PROTECTED] | | ( If the above address fail try ) | | ( [EMAIL PROTECTED])| ---
Re: What to do when tape is full?
On Tue, Apr 23, 2002 at 12:23:19PM -0400, Jon LaBadie wrote: > > > Or leave the tape out of the drive and let it go to to the holding disk, > > > then amflush whenever you have a full tapes worth. > > > > Will that work ? When I use amflush I get given a list of days on which > > amdump ran without a tpe for whatever reason. Then I must choose one of > > those days and that set of backups is flushed to the tape. To get two or > > more days onto one tape Amanda would have to support append :-) > > > > You are also given the choice of "ALL". For some reason, I thought that if I picked ALL it would do the flush one day at a time, asking for a different tape each time. If instead it flushes ALL onto one tape then that does effectively give you a way of maximising tape usage, if you're that concerned. However, you'd need to be rather careful that you didn't end up with too much data held. > Let several days worth accumulate then try it and let us know. No thanks - you can play with your company's data if you like :-) Regards, Niall O Broin
Re: What to do when tape is full?
* Frank Smith <[EMAIL PROTECTED]> (Tue, Apr 23, 2002 at 09:54:45AM -0500) > As someone who has learned a lot the hard way, I concur with the > 'no append' design decision. There is no way to redo a previous backup, append is evil append and multi tape span (which is used e.g. by Backup Exec for NT) is inherently evil ... The number of dumops that hold 10 minutes in the dump because they need a tape swap (which can only happen the next day when Im back again as we do overnight backups) is big .. the autoverify makes it even worse .. after the dumpo it rewinds , wants the previous tape forwards to do the verify and then wants the next tape back again. Kind regards, -- Gerhard den Hollander Phone :+31-10.280.1515 Global IT Support manager Direct:+31-10.280.1539 Jason Geosystems BV Fax :+31-10.280.1511 (When calling please note: we are in GMT+1) [EMAIL PROTECTED] POBox 1573 visit us at http://www.jasongeo.com 3000 BN Rotterdam JASON...#1 in Reservoir CharacterizationThe Netherlands This e-mail and any attachment is/are intended solely for the named addressee(s) and may contain information that is confidential and privileged. If you are not the intended recipient, we request that you do not disseminate, forward, distribute or copy this e-mail message. If you have received this e-mail message in error, please notify us immediately by telephone and destroy the original message.
RE: Guidelines/suggestions for backing up a large RAID array?
There has been some recent discussion of this on (and off) the list. Each different path in the disklist will create separate index entries. While generating a new backup file every night looks good on the backup side, it can be a nightmare on the restore side, depending on your data. I wouldn't want to have to pull a specific version of a file out of a deep subdirectory using a new disklist every night. As an alternative, you might want to build a static disklist of directories such that each directory is some fraction of a tape size (33%? 50%?) and keep an eye on their respective sizes through amreport. If a directory gets too big, split it. You'll only have the potential for restore headaches every once in a while instead of every night. If that doesn't suit, there was discussion of 'chunking' on the amanda-hackers list a while back. If you want to sharpen your pencil and write some code, the 'chunking' system would break every backup into chunks, and if a chunk of a backup hits EOT, AMANDA can change tapes and keep going, with a maximum waste at the end of tape being equal to chunksize. It was a neat idea that I suspect went to the back burner because the 'use a file as a tape' thing that is being worked on now is a neater idea. > -Original Message- > From: David Trusty [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 23, 2002 2:20 PM > To: [EMAIL PROTECTED] > Subject: Guidelines/suggestions for backing up a large RAID array? > > > Hi, > > I am working with a very large RAID array which needs backing-up. > > The array has 3 partitions, each containing approximately > 150GB of files. > > I have a tape changer with 20 tapes, each holding 50GB of data. > > Since amanda currently will not back up a disk larger than a > tape, I believe I need to specify smaller peices of the partitions > in my disklist. What I am thinking about doing is writing a script > which scans the partitions down to a certain depth and generates > a disklist of peieces small enough to backup onto a single tape, > using the GNUTAR method. > > Has anyone had a similar problem, and had any other solutions? > > Also, what is the effect on amanda of changing the disklist > (perhaps every night)? The changes (when they occur) will all > be different subpaths of the same partitions. Will this get > amanda confused, or make it back up a lot of extra files, or > is the gtar indexing able to handle this situation? > > Thanks in advance!! > > David > > > > > _ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx >
Re: Guidelines/suggestions for backing up a large RAID array?
Hi David, I am no expert on this, however I think you may run into problems with that approach. Amanda expects consistency with the disk list and if you changed it each night, I think you'd have trouble with restores and Amanda would have trouble keeping track of the level of backup needed. I think a more workable approach would be to determine or identify directories that contain less than 50GB of data and make entries in your disk list accordingly. In fact, you could have several entries in your disklist for that partition, on a subdirectory by subdirectory basis... I hope this helps. Jeff On Tue, 2002-04-23 at 14:20, David Trusty wrote: > Hi, > > I am working with a very large RAID array which needs backing-up. > > The array has 3 partitions, each containing approximately > 150GB of files. > > I have a tape changer with 20 tapes, each holding 50GB of data. > > Since amanda currently will not back up a disk larger than a > tape, I believe I need to specify smaller peices of the partitions > in my disklist. What I am thinking about doing is writing a script > which scans the partitions down to a certain depth and generates > a disklist of peieces small enough to backup onto a single tape, > using the GNUTAR method. > > Has anyone had a similar problem, and had any other solutions? > > Also, what is the effect on amanda of changing the disklist > (perhaps every night)? The changes (when they occur) will all > be different subpaths of the same partitions. Will this get > amanda confused, or make it back up a lot of extra files, or > is the gtar indexing able to handle this situation? > > Thanks in advance!! > > David > > > > > _ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx -- ++ | Jeffery Smith - Systems Administrator - [EMAIL PROTECTED] | | Sky Computers, Inc. (www.skycomputers.com) | ++
Re: Guidelines/suggestions for backing up a large RAID array?
On Tue, 23 Apr 2002, David Trusty wrote: > Since amanda currently will not back up a disk larger than a > tape, I believe I need to specify smaller peices of the partitions > in my disklist. What I am thinking about doing is writing a script > which scans the partitions down to a certain depth and generates > a disklist of peieces small enough to backup onto a single tape, > using the GNUTAR method. If memory serves, John has already written this script and made it publicly available. Try searching the archives for "wrapper script" or "gnutar wrapper" or suchlike. -Mitch
Guidelines/suggestions for backing up a large RAID array?
Hi, I am working with a very large RAID array which needs backing-up. The array has 3 partitions, each containing approximately 150GB of files. I have a tape changer with 20 tapes, each holding 50GB of data. Since amanda currently will not back up a disk larger than a tape, I believe I need to specify smaller peices of the partitions in my disklist. What I am thinking about doing is writing a script which scans the partitions down to a certain depth and generates a disklist of peieces small enough to backup onto a single tape, using the GNUTAR method. Has anyone had a similar problem, and had any other solutions? Also, what is the effect on amanda of changing the disklist (perhaps every night)? The changes (when they occur) will all be different subpaths of the same partitions. Will this get amanda confused, or make it back up a lot of extra files, or is the gtar indexing able to handle this situation? Thanks in advance!! David _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
RE: Please help -- planner askfor: lev out of range -1..10: 10
This is just for the archives, so someone in the future can find the fix. No need to respond. > From: Daniel Lorenzini [mailto:[EMAIL PROTECTED]] > > Check to see if any of your dumps is at level 9. If so, > force a level 0. This is a planner bug. That turned out to be the problem. I looked through my the daily email reports from amanda, and found that in the DUMP SUMMARY that one disk had been at level 9 for many days: HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- - beowulf -a/mm5/2002 9 42346884234688 --4:4714754.8 14:564724.8 After issuing the following command, su amanda -c "amadmin Daily force beowulf /data/mm5/2002" the next night amanda ran successfully. I still have to work out the problems associated with having too many disks to dump, but at least amanda is running again. Thanks to all those who responded and helped me wrangle with amanda! Bart -- Bart Brashers MFG Inc. Air Quality Meteorologist 19203 36th Ave W Suite 101 [EMAIL PROTECTED]Lynnwood WA 98036-5707 http://www.mfgenv.com 425.921.4000 Fax: 425.921.4040
Re: Estimates - 7 hour 50mins
On 23 Apr 2002, at 12:20, Jon LaBadie wrote: > On Tue, Apr 23, 2002 at 04:47:33PM +0100, David Flood wrote: > > > To David, see if one (or more) systems are causing the total system > > > to be slow to completion. > > > > But the tapeserver concerned is only backing up itself so there are > > not any slow hosts slowing it down. > > > > The tapeserver is a Sun E450 which is quite a chunky fileserver > > with 1.6GB ram. > > > > Any particular disklist entry causeing the slow estimate phase? How would I check this. > > Any chance of switching to ufsdump? These directories are all under /export/home/* but unfortunatly /export is an entire 80GB disk all in one slice(I did not set this up this way). So tar is the only option. > > -- > Jon H. LaBadie [EMAIL PROTECTED] > JG Computing > 4455 Province Line Road(609) 252-0159 > Princeton, NJ 08540-4322 (609) 683-7220 (fax) - David Flood Systems Administrator [EMAIL PROTECTED] Tel: +44 (0)1224 262721 The Robert Gordon University School of Computing St. Andrews Street Aberdeen -
Re: What to do when tape is full?
--On Tuesday, April 23, 2002 17:44:27 +0100 Niall O Broin <[EMAIL PROTECTED]> wrote: > On Tue, Apr 23, 2002 at 09:54:45AM -0500, Frank Smith wrote: > >> Or leave the tape out of the drive and let it go to to the holding disk, >> then amflush whenever you have a full tapes worth. > > Will that work ? When I use amflush I get given a list of days on which > amdump ran without a tpe for whatever reason. Then I must choose one of > those days and that set of backups is flushed to the tape. To get two or > more days onto one tape Amanda would have to support append :-) One of the date options to the list should be 'ALL'. At least that's what I remember of it ( I haven't needed to run amflush in awhile). Frank -- Frank Smith[EMAIL PROTECTED] Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Re: What to do when tape is full?
On Tue, 23 Apr 2002 at 5:44pm, Niall O Broin wrote > On Tue, Apr 23, 2002 at 09:54:45AM -0500, Frank Smith wrote: > > > Or leave the tape out of the drive and let it go to to the holding disk, > > then amflush whenever you have a full tapes worth. > > Will that work ? When I use amflush I get given a list of days on which > amdump ran without a tpe for whatever reason. Then I must choose one of > those days and that set of backups is flushed to the tape. To get two or > more days onto one tape Amanda would have to support append :-) I believe the default is ALL. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: What to do when tape is full?
On Tue, Apr 23, 2002 at 09:54:45AM -0500, Frank Smith wrote: > Or leave the tape out of the drive and let it go to to the holding disk, > then amflush whenever you have a full tapes worth. Will that work ? When I use amflush I get given a list of days on which amdump ran without a tpe for whatever reason. Then I must choose one of those days and that set of backups is flushed to the tape. To get two or more days onto one tape Amanda would have to support append :-) Regards, Niall O Broin
Re: What to do when tape is full?
--On Tuesday, April 23, 2002 15:26:33 +0200 Toralf Lund <[EMAIL PROTECTED]> wrote: > On 23/04 2002 14:52 Joshua Baker-LePain wrote: > Yes, maybe a good decision. (Although the purchase of new tapes and the management >of all of them do add up to a non-negligible cost.) While the cost of sufficient tapes is certainly 'non-negligible', and can actually be much greater than the cost of the library you put them, company management has to weigh the cost of tapes versus the cost of losing data. Sooner or later you will need to restore something. How much is it worth to be able to do that? There is much data that can be (somewhat) easily recreated, and other data that is irreplaceable or would take so long to recreate that you would be out of business before it could be recreated. If you don't have enough tapes to be comfortable in the ability to restore your data (and just because you have one copy doesn't mean you will be able to restore it), then get more tapes. If your management doesn't see the need, write up what you need and why, and be sure to save the response if they disagree, since your head is on the line if critical data can't be restored. Frank -- Frank Smith[EMAIL PROTECTED] Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Re: what's this??
On Tue, Apr 23, 2002 at 08:49:44AM -0400, Axel Haenssen wrote: > Hi Guys, > can someone tell me what this (except from my daily report) means? > > NOTES: > planner: Full dump of node8:/scratch promoted from 10 days ahead. > planner: Full dump of node6:/scratch promoted from 10 days ahead. > planner: Full dump of node14:/scratch promoted from 10 days ahead. > planner: Full dump of node15:/scratch promoted from 10 days ahead. > planner: Full dump of node9:/scratch promoted from 10 days ahead. > planner: Full dump of node11:/scratch promoted from 10 days ahead. > planner: Full dump of node7:/scratch promoted from 10 days ahead. > planner: Full dump of node10:/scratch promoted from 10 days ahead. > planner: Full dump of node12:/scratch promoted from 10 days ahead. > planner: Full dump of node17:/scratch promoted from 10 days ahead. > planner: Full dump of node13:/scratch promoted from 10 days ahead. > planner: Full dump of node5:/scratch promoted from 10 days ahead. > taper: tape DMP007 kb 144672 fm 16 [OK] Amanda trys to balance the amount of data dumped nightly. To do this she sometimes will do some level 0 (Full) dumps earlier than absolutely necessary. It is normal. I suspect you have a new amanda installation and did many first dumps all on the same day. Now amanda is in the process of moving them around to balance the size of the dumps. This will go on for several dump cycles then be pretty consistant. Besides, "extra" level 0's don't hurt, do they? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Estimates - 7 hour 50mins
On Tue, Apr 23, 2002 at 09:29:57AM -0400, Uncle George wrote: > I presume u are using tar?! > From My experience, 17gigs of a (few) large files does not take a long > time. > On the other hand, backing up a large amount of files in a (single) > directory takes a long time. The orig tar that came with this (linux) > sys readily reached 80% cpu usage. The later tar fixed that, so now it > still takes a long time ( but mainly it just waits for all the > disk/directory activity ?! ) > > So whats the culprit? Since there are 2 phases ( size estimate, and then > data transfer ) i suspect that each part takes about 4 hours.To find > out, you can do a "time tar cf - .. " just like what the sendsize > program would do on your system. just to See how long that takes. > > Then how fast is your tape drive? a 5.0mb/sec tape drive would take 56 > min just to back up 17gig. This presumes that the tape is screaming ( i > ment streaming ) . > > a "df -i" might help in determing how many files might be out on the > system. > > David Flood wrote: > > > > We kick off our backup at 10pm at the moment we are only > > backing up 4 seperate directorys i.e. 4 seperate disklist entries. > > These are estimated by amanda to be 17.4GB. The estimates are > > taking just short of 8 hours to complete which is unacceptable. > > This is after making every dump a full dump in an attempt to cut > > down time with doing estimates for level 1 & 2. To force it to do full > > dumps I have did the following in amanda.conf: Another datapoint, also Solaris, but Solaris is not the culprit :) If I understand the scheme, the planner can't finalize its actual dumps until all estimates are in. Thus when the dumping begins is dependent on the speed of the slowest system's estimates. In my case, the Solaris estimates (5 drives, about 90G capacity) takes about 30 minutes. But I also have a W2000 system and the estimates for its 1 drive (4 partititions) of 30G takes 3+ hours. When I added the M$ system I had to move the dumps from 3AM to 2AM to prevent them from still running when I awoke. To David, see if one (or more) systems are causing the total system to be slow to completion. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: What to do when tape is full?
--On Tuesday, April 23, 2002 08:52:51 -0400 Joshua Baker-LePain <[EMAIL PROTECTED]> wrote: > On Tue, 23 Apr 2002 at 1:30pm, Toralf Lund wrote > >> Wouldn't append support be easy to implement? Seems to me that most of the >> code must be there already (since Amanda writes several dumps to one tape >> in its normal mode of operation.) >> > Lack of append support is a design decision, AIUI. The thought is that > it's better to not use some of a tape than to overwrite backups because, > for some reason, the tape rewound itself when you weren't looking. Safety > and redundancy are paramount in backups, not tape usage. YMMV, but that's > the design decision made with amanda (which I happen to agree with). > > If you want to fill tapes to the max, then add the disk usages up by hand > and 'amadmin force' enough filesystems each night to fill the tape. Or leave the tape out of the drive and let it go to to the holding disk, then amflush whenever you have a full tapes worth. As someone who has learned a lot the hard way, I concur with the 'no append' design decision. There is no way to redo a previous backup, and the one time you accidently overwrite a tape will be the time you most need a file that only existed on that tape. Power glitches, I/O errors, SCSI resets, other users, and various other things can easily cause a drive to rewind with your noticing, and they would all be fatal to your data. Frank -- Frank Smith[EMAIL PROTECTED] Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
RE: tape out of space??
>What about the SCSI bus? Any sort of messages at approximately the time >of the error? No errors at all actually...I see the session opening and closing for amanda...and that's it. >What sort of drive? It's a Seagate 12/24 DAT...nothing fancy...I'm pushing it to it's limits right now backing up 11GB...trying to get the $$ for a DLT drive. rap
Re: What to do when tape is full?
On Tue, 23 Apr 2002 at 9:09am, Darin Dugan wrote > At 08:26 AM 4/23/2002, Toralf Lund wrote: > [...] > >I'd really prefer an "auto flush" mode to append support (I can't see any > >need for both). That should be easy to write as well, and I can't see any > >problems associated with it, in fact, I think it would increase the safety > >quite a bit. > > From amanda(8): > > autoflush bool >Default: off. Whether an amdump run will flush the dump > already on holding disk to tape. > Cool -- thanks for pointing that out. Note, however, that it doesn't appear in the 2.4.2p2 docs -- only in 2.4.3b (which is still in beta mode). -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: What to do when tape is full?
At 08:26 AM 4/23/2002, Toralf Lund wrote: [...] >I'd really prefer an "auto flush" mode to append support (I can't see any >need for both). That should be easy to write as well, and I can't see any >problems associated with it, in fact, I think it would increase the safety >quite a bit. From amanda(8): autoflush bool Default: off. Whether an amdump run will flush the dump already on holding disk to tape. [...] >- Toralf -- Darin Dugan [EMAIL PROTECTED]
RE: tape out of space??
On Tue, 23 Apr 2002 at 8:57am, Rebecca Pakish wrote > >Look in /var/log/messages (or the output of 'dmesg') -- there's probably > >an entry from the tape driver letting you know what the error was. E.g., > >when this happens with my Eliant 820, I get: > > Nothing in messages that's telling me anything about my tape drive... What about the SCSI bus? Any sort of messages at approximately the time of the error? > >On my drive, this just means that the drive needs to be cleaned. > > I was going to give it a good cleaning because it happens with my sun DAT > drive sometimes (dumps failing when the drive is dirty); but never with this > Seagate (until now??). We'll see what happens. Thanks! What sort of drive? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
RE: tape out of space??
>Look in /var/log/messages (or the output of 'dmesg') -- there's probably >an entry from the tape driver letting you know what the error was. E.g., >when this happens with my Eliant 820, I get: Nothing in messages that's telling me anything about my tape drive... >On my drive, this just means that the drive needs to be cleaned. I was going to give it a good cleaning because it happens with my sun DAT drive sometimes (dumps failing when the drive is dirty); but never with this Seagate (until now??). We'll see what happens. Thanks! rap
Re: tape out of space??
On Tue, 23 Apr 2002 at 8:32am, Rebecca Pakish wrote > Hi all > > I have been using amanda 2.4.2p2 on my 7.2 RH server for quite some time now > backing up both linux and solaris clients. > Today something strange happened... > a tape that has been in rotation and working properly all of sudden ran out > of space? *snip* > As you can see my tape size was cut in half all of a sudden. I haven't made > any changes to the configuration or drive... > Maybe it's just a media error...but I wanted to throw it out here just in > case. Look in /var/log/messages (or the output of 'dmesg') -- there's probably an entry from the tape driver letting you know what the error was. E.g., when this happens with my Eliant 820, I get: Apr 11 03:12:57 chaos kernel: st0: Error with sense data: Info fld=0x2ba, Deferred st09:00: sense key Medium Error Apr 11 03:12:57 chaos kernel: Additional sense indicates Excessive write errors Apr 11 03:12:57 chaos kernel: st0: Error with sense data: Current st09:00: sense key Medium Error Apr 11 03:12:57 chaos kernel: Additional sense indicates Excessive write errors Apr 11 03:12:57 chaos kernel: st0: Error on write filemark. On my drive, this just means that the drive needs to be cleaned. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
tape out of space??
Hi all
I have been using amanda 2.4.2p2 on my 7.2 RH server for quite some time now
backing up both linux and solaris clients.
Today something strange happened...
a tape that has been in rotation and working properly all of sudden ran out
of space?
The last time I used this tape the stats showed:
These dumps were to tape dailytape03.
The next tape Amanda expects to use is: dailytape04.
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:02
Run Time (hrs:min) 3:04
Dump Time (hrs:min)0:39 0:39 0:00
Output Size (meg) 11082.411082.40.0
Original Size (meg) 11082.411082.40.0
Avg Compressed Size (%) -- -- --
Filesystems Dumped 14 14 0
Avg Dump Rate (k/s) 4852.5 4852.5--
Tape Time (hrs:min)3:02 3:02 0:00
Tape Size (meg) 11082.911082.90.0
Tape Used (%) 95.7 95.70.0
Filesystems Taped14 14 0
Avg Tp Write Rate (k/s) 1037.5 1037.5--
This time the stats showed:
These dumps were to tape dailytape03.
*** A TAPE ERROR OCCURRED: [[writing file: No space left on device]].
Some dumps may have been left in the holding disk.
Run amflush to flush them to tape.
The next tape Amanda expects to use is: dailytape04.
FAILURE AND STRANGE DUMP SUMMARY:
in-db3.unt /etc lev 1 FAILED [no estimate]
in-db3.unt /export/home lev 0 FAILED [out of tape]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:02
Run Time (hrs:min) 3:12
Dump Time (hrs:min)0:41 0:41 0:00
Output Size (meg) 11574.111565.78.4
Original Size (meg) 11574.111565.78.4
Avg Compressed Size (%) -- -- --(level:#disks ...)
Filesystems Dumped 13 8 5 (1:5)
Avg Dump Rate (k/s) 4827.4 4831.4 2264.7
Tape Time (hrs:min)1:55 1:54 0:00
Tape Size (meg) 6808.3 6799.78.6
Tape Used (%) 58.8 58.70.1 (level:#disks ...)
Filesystems Taped12 7 5 (1:5)
Avg Tp Write Rate (k/s) 1013.5 1013.7 882.1
As you can see my tape size was cut in half all of a sudden. I haven't made
any changes to the configuration or drive...
Maybe it's just a media error...but I wanted to throw it out here just in
case.
Any insight is much appreciated...
Thanks and have a great day. :)
Rebecca A. Pakish
Systems Administrator
Unterberg & Associates, P.C.
(219) 736-5579 ext. 184
Amanda + solaris
Hello I have Sun E250 with Solaris 7 Tape library Adic FastStore22 And amanda How I have to configure amanda and solaris to work together, What kind of driver I need to instal on Solaris greetings
Re: Estimates - 7 hour 50mins
I presume u are using tar?! From My experience, 17gigs of a (few) large files does not take a long time. On the other hand, backing up a large amount of files in a (single) directory takes a long time. The orig tar that came with this (linux) sys readily reached 80% cpu usage. The later tar fixed that, so now it still takes a long time ( but mainly it just waits for all the disk/directory activity ?! ) So whats the culprit? Since there are 2 phases ( size estimate, and then data transfer ) i suspect that each part takes about 4 hours.To find out, you can do a "time tar cf - .. " just like what the sendsize program would do on your system. just to See how long that takes. Then how fast is your tape drive? a 5.0mb/sec tape drive would take 56 min just to back up 17gig. This presumes that the tape is screaming ( i ment streaming ) . a "df -i" might help in determing how many files might be out on the system. David Flood wrote: > > We kick off our backup at 10pm at the moment we are only > backing up 4 seperate directorys i.e. 4 seperate disklist entries. > These are estimated by amanda to be 17.4GB. The estimates are > taking just short of 8 hours to complete which is unacceptable. > This is after making every dump a full dump in an attempt to cut > down time with doing estimates for level 1 & 2. To force it to do full > dumps I have did the following in amanda.conf: > > dumpcycle 0 > strategey noinc > skip-incr yes > > I'm running: > amanda 2.4.3b3 > Solaris 7 > Using tar > I'm restore onto a 35/70 DLT with software compression. > > The 4 directorys mentioned above are all on the tapeserver and > those are the only thing the tapeserver is backing up. > > Does anyone have any ideas, because the estimates are taking so > long the backups are still running when the users come in - in the > morning. This means the backups I'm getting if I get them are 'dirty' > not to mention it slows the system down as backups and users are > trying to access the same data. > > Thanks in advance > > David Flood > Systems Administrator
Re: Estimates - 7 hour 50mins
On Tue, 23 Apr 2002 at 2:25pm, David Flood wrote > I searched http://groups.yahoo.com/group/amanda-users/ for calcsize and > found only 7 results. Most of these were from people listing the contents of the > libexec directory. There was one from John R Jackson where he told someone > if they wanted to use calcsize to let hims know and he would find the posting > about turning it on but there was no reply to that. > As I can't find these postings does anyone know anything about calcsize i.e. > where to get it, how I configure/use it? I found one posting dealing with how to use it -- it contains a modified sendsize.c that it seems like you plop into place and recompile:\ http://marc.theaimsgroup.com/?l=amanda-users&m=9253924842&w=2 The other suggestion I ran across was to use ufsdump rather than tar. Is there a reason you need to use tar? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Estimates - 7 hour 50mins
I searched http://groups.yahoo.com/group/amanda-users/ for calcsize and found only 7 results. Most of these were from people listing the contents of the libexec directory. There was one from John R Jackson where he told someone if they wanted to use calcsize to let hims know and he would find the posting about turning it on but there was no reply to that. As I can't find these postings does anyone know anything about calcsize i.e. where to get it, how I configure/use it? On 23 Apr 2002, at 8:55, Joshua Baker-LePain wrote: > On Tue, 23 Apr 2002 at 1:19pm, David Flood wrote > > > I'm running: > > amanda 2.4.3b3 > > Solaris 7 > > Using tar > > I'm restore onto a 35/70 DLT with software compression. > > Why is it always the Solaris machines that have speed issues? (That was > rhetorical, btw). > > > Does anyone have any ideas, because the estimates are taking so > > long the backups are still running when the users come in - in the > > morning. This means the backups I'm getting if I get them are 'dirty' > > not to mention it slows the system down as backups and users are > > trying to access the same data. > > Search the archives for references to calcsize, an alternative estimator > with the disadvantage of not supporting excludes but the advantage of much > better speed. > > -- > Joshua Baker-LePain > Department of Biomedical Engineering > Duke University > David Flood Systems Administrator
Re: What to do when tape is full?
On 23/04 2002 14:52 Joshua Baker-LePain wrote: > On Tue, 23 Apr 2002 at 1:30pm, Toralf Lund wrote > > > Wouldn't append support be easy to implement? Seems to me that most of > the > > code must be there already (since Amanda writes several dumps to one > tape > > in its normal mode of operation.) > > > Lack of append support is a design decision, AIUI. The thought is that > it's better to not use some of a tape than to overwrite backups because, > for some reason, the tape rewound itself when you weren't looking. > Safety > and redundancy are paramount in backups, not tape usage. YMMV, but > that's > the design decision made with amanda (which I happen to agree with). Yes, maybe a good decision. (Although the purchase of new tapes and the management of all of them do add up to a non-negligible cost.) I'd really prefer an "auto flush" mode to append support (I can't see any need for both). That should be easy to write as well, and I can't see any problems associated with it, in fact, I think it would increase the safety quite a bit. > > If you want to fill tapes to the max, then add the disk usages up by hand > > and 'amadmin force' enough filesystems each night to fill the tape. I've also thought about reducing runspercycle a bit, and risk not getting everything included - but of course run additional amdumps when necessary, or even have extra ones started automatically, but I'm not quite sure how it would work out in practise. - Toralf
Re: Estimates - 7 hour 50mins
On Tue, 23 Apr 2002 at 1:19pm, David Flood wrote > I'm running: > amanda 2.4.3b3 > Solaris 7 > Using tar > I'm restore onto a 35/70 DLT with software compression. Why is it always the Solaris machines that have speed issues? (That was rhetorical, btw). > Does anyone have any ideas, because the estimates are taking so > long the backups are still running when the users come in - in the > morning. This means the backups I'm getting if I get them are 'dirty' > not to mention it slows the system down as backups and users are > trying to access the same data. Search the archives for references to calcsize, an alternative estimator with the disadvantage of not supporting excludes but the advantage of much better speed. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: what's this??
On 23 Apr 2002 at 8:49am, Axel Haenssen wrote > Hi Guys, > can someone tell me what this (except from my daily report) means? > > NOTES: > planner: Full dump of node8:/scratch promoted from 10 days ahead. > planner: Full dump of node6:/scratch promoted from 10 days ahead. > planner: Full dump of node14:/scratch promoted from 10 days ahead. > planner: Full dump of node15:/scratch promoted from 10 days ahead. > planner: Full dump of node9:/scratch promoted from 10 days ahead. > planner: Full dump of node11:/scratch promoted from 10 days ahead. > planner: Full dump of node7:/scratch promoted from 10 days ahead. > planner: Full dump of node10:/scratch promoted from 10 days ahead. > planner: Full dump of node12:/scratch promoted from 10 days ahead. > planner: Full dump of node17:/scratch promoted from 10 days ahead. > planner: Full dump of node13:/scratch promoted from 10 days ahead. > planner: Full dump of node5:/scratch promoted from 10 days ahead. > taper: tape DMP007 kb 144672 fm 16 [OK] It means exactly what it says. Those filesystems weren't due for level 0s for another 10 days. But, amanda saw that there was room on the tape, and so moved them from level 1s to level 0s. And it's just letting you know what it did. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
what's this??
Hi Guys, can someone tell me what this (except from my daily report) means? NOTES: planner: Full dump of node8:/scratch promoted from 10 days ahead. planner: Full dump of node6:/scratch promoted from 10 days ahead. planner: Full dump of node14:/scratch promoted from 10 days ahead. planner: Full dump of node15:/scratch promoted from 10 days ahead. planner: Full dump of node9:/scratch promoted from 10 days ahead. planner: Full dump of node11:/scratch promoted from 10 days ahead. planner: Full dump of node7:/scratch promoted from 10 days ahead. planner: Full dump of node10:/scratch promoted from 10 days ahead. planner: Full dump of node12:/scratch promoted from 10 days ahead. planner: Full dump of node17:/scratch promoted from 10 days ahead. planner: Full dump of node13:/scratch promoted from 10 days ahead. planner: Full dump of node5:/scratch promoted from 10 days ahead. taper: tape DMP007 kb 144672 fm 16 [OK] Thanks a lot. Axel signature.asc Description: This is a digitally signed message part
Re: What to do when tape is full?
On Tue, 23 Apr 2002 at 1:30pm, Toralf Lund wrote > Wouldn't append support be easy to implement? Seems to me that most of the > code must be there already (since Amanda writes several dumps to one tape > in its normal mode of operation.) > Lack of append support is a design decision, AIUI. The thought is that it's better to not use some of a tape than to overwrite backups because, for some reason, the tape rewound itself when you weren't looking. Safety and redundancy are paramount in backups, not tape usage. YMMV, but that's the design decision made with amanda (which I happen to agree with). If you want to fill tapes to the max, then add the disk usages up by hand and 'amadmin force' enough filesystems each night to fill the tape. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Over large level 1 dumps
On Tue, 23 Apr 2002 at 11:33am, Niall O Broin wrote > (Note that there were intervening dumps, but 23 had both / filesystems at > level 1 and I went back to 16 to get both at level 0. Why on earth are the > backups at level 1 bigger than those at level 0 ? Note that these are both > Linux boxes so a substantial chunk of / is the OS installation and > associated files and there simply hasn't been that much changed on those > boxes. Do you have 'record yes' set in your dumptype? Can the amanda user write to /etc/amandates? > A second question, while I have your attention. Observe how the some of the > figures in the report run together - is the layout of this controllable via > a template ? The output is 73 characters so there could be a couple more > spaces inserted and still stay < 80 characters which I imagine is desired. > Look for 'columnspec' in your amanda.conf. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Tar patch
On Tue, 23 Apr 2002 at 12:44am, Vijay Kumar wrote > How do i apply the Tar patfch in the patches directory? > I am using tar 1.13.19 . Do i still need the patch? You don't need the patch for tar 1.13.19. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Estimates - 7 hour 50mins
We kick off our backup at 10pm at the moment we are only backing up 4 seperate directorys i.e. 4 seperate disklist entries. These are estimated by amanda to be 17.4GB. The estimates are taking just short of 8 hours to complete which is unacceptable. This is after making every dump a full dump in an attempt to cut down time with doing estimates for level 1 & 2. To force it to do full dumps I have did the following in amanda.conf: dumpcycle 0 strategey noinc skip-incr yes I'm running: amanda 2.4.3b3 Solaris 7 Using tar I'm restore onto a 35/70 DLT with software compression. The 4 directorys mentioned above are all on the tapeserver and those are the only thing the tapeserver is backing up. Does anyone have any ideas, because the estimates are taking so long the backups are still running when the users come in - in the morning. This means the backups I'm getting if I get them are 'dirty' not to mention it slows the system down as backups and users are trying to access the same data. Thanks in advance David Flood Systems Administrator
Re: What to do when tape is full?
> On Mon, Apr 22, 2002 at 11:39:55AM +0200, Toralf Lund wrote: > > On 19/04 2002 16:18 Dave Sherohman wrote: > > > You can do this manually by not changing tapes (or leaving the tape > > > drive empty) tonight, which will cause all of tonight's dumps to stay > > > on the holding disk (provided it's big enough), then put the new tape > > > in and run amflush tomorrow morning to collect all of the untaped > dumps. > > > Yes, of course. Does this also mean that it's a good idea to use the > > amount equivalent to one tape of the holding disk space? > > IMO, holding disk space is a matter of 'the more, the merrier'. > You definitely want enough to handle at least one runs' worth of level > 1 dumps, in case someone forgets to switch tapes or the taping never > starts for some other reason. I like to go with at least twice that > (disk is cheap, these days...) so that I can consolidate partial dumps > if something goes wrong mid-run. I was thinking that allowing more than one tape's worth of data to be stored on disk would be bad as there might still be something left after flushing an overflowed dump + run without tape, which would leave me in exactly the same state as before I started. > > > Nope. Last night's untaped dumps will sit on the holding disk > forever > > > unless you either delete them or run amflush > > Too bad. > > Yeah, it would be nice if you could set amanda up to automatically do > an amflush onto the same tape after completing a normal run if the tape > isn't full yet. Exactly. Or to do amflush first when starting the next run, then do new dumps to fill up the tape. > > > I'm assuming there is no way to continue writing to the tape were > > something was amflushed, either, but please let me know if I'm wrong. > > You are correct. Amanda will not append to tapes under any > circumstances. > It always starts writing from the beginning of the tape. Wouldn't append support be easy to implement? Seems to me that most of the code must be there already (since Amanda writes several dumps to one tape in its normal mode of operation.) - Toralf
Spectra 10000
Hi all Has anybody already implemented following backup solution: Amanda with Spectra Logic 1 AIT-1 or AIT-2 ? Does it work ? I didn't find an exact information at the amanda.org page. If someone can tell me his/her experience I would be thankful. Greetings Heiko -- --- Dipl. Inf. Heiko Schellhorn University of BremenRoom: NWI-W3140 Inst. of Environmental Physics Phone: +49(0)421 218 4080 P.O. Box 33 04 40 Fax: +49(0)421 218 4555 D-28334 Bremen Mail: mailto:[EMAIL PROTECTED] Germany www: http://www.iup.physik.uni-bremen.de http://www.sciamachy.de http://www.geoscia.de
amanda + solaris 7
Hello I have Sun E250 with Solaris 7 Tape library Adic FastStore22 And amanda How I have to configure amanda and solaris to work together, What kind of driver I need to instal on Solaris greetings
Over large level 1 dumps
I'm just starting using Amanda (hence the level of questions :-) ) and I currently am backing up 4 filesystems on 2 hosts though I want to increase this as soon as I'm happy with what's going on. I'm currently puzzled about the size of level 1 backups. Look at these two extracts from mail reports: Makalu TIZ AMANDA MAIL REPORT FOR April 16, 2002 DUMP SUMMARY: DUMPER STATSTAPER STATS HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- - moca / 0 26593602659360 -- 13:063385.2 30:251457.5 moca /boot 04384 4384 --0:0014986.3 0:13 339.3 pumori / 0 40461764046176 -- 17:523773.5 54:451231.5 pumori /boot 03552 3552 --0:014089.4 0:05 713.0 Makalu TIZ AMANDA MAIL REPORT FOR April 23, 2002 DUMP SUMMARY: DUMPER STATSTAPER STATS HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- - moca / 1 26712322671232 --8:435109.6 N/A N/A moca /boot 04384 4384 --0:0010109.8 N/A N/A pumori / 1 40479684047968 -- 15:514256.4 N/A N/A pumori /boot 03552 3552 --0:016062.2 N/A N/A (Note that there were intervening dumps, but 23 had both / filesystems at level 1 and I went back to 16 to get both at level 0. Why on earth are the backups at level 1 bigger than those at level 0 ? Note that these are both Linux boxes so a substantial chunk of / is the OS installation and associated files and there simply hasn't been that much changed on those boxes. I'm using GNU tar version 1.3.18 and with the recent discussion, I intend to update that today to 1.3.25 from the FSF development box. A second question, while I have your attention. Observe how the some of the figures in the report run together - is the layout of this controllable via a template ? The output is 73 characters so there could be a couple more spaces inserted and still stay < 80 characters which I imagine is desired. Kindest regards, Niall O Broin
Re: amlabel & ftape
Stefan Kiczerjak <[EMAIL PROTECTED]> writes: > hello everboby, > > before i am going to buy an expensive dlt-streamer i'd like to do some > testing with an old iomega 250 floppy-qic. > I have configured all as discripted in the man-pages but unfortunately > amlabel closes with an error. > here the amlabel output: > > amanda@tester:~> amlabel test tgl01 > rewinding, reading label, not an amanda tape > rewinding, writing label tgl01 > amlabel: writing label: Invalid argument > > has anybody any suggestion? Stefan, did you try this from "man amanda"? rawtapedev "string" Default: /dev/null. The path name of the raw tape device. This is only used if Amanda is compiled for Linux machines with floppy tapes and is needed for QIC volume table operations. IIRC you need /dev/nrawqft0 as device. I've a abandoned but working installation at home. I can send the configuration. Johannes Nieß
amanda + solaris 7
Hello I have Sun E250 with Solaris 7 Tape library Adic FastStore22 And amanda How I have to configure amanda and solaris to work together, What kind of driver I need to instal on Solaris greetings
Re: help on define tapetype in amanda.conf
> What should be my definintion in amanda.conf if I have this device: > > sa0: Removable Sequential Access SCSI-2 device > > I've found a long list from the link below but I don't know which one to > select: > http://www.amanda.org/fom-serve/cache/72.html The second one from top looks exactly right to me. -- Toomas Aas | [EMAIL PROTECTED] | http://www.raad.tartu.ee/~toomas/ * How can you tell when you've run out of invisible ink?
Re: disk offline
> >My amdump email report starts out: > > > >These dumps were to tape daily001. > >The next tape Amanda expects to use is: daily001. > > This in itself, is odd, very odd. Your amanda.conf seems to be > out of whack somehow. Well, that could very well be, I suppose... > >(brought to you by Amanda version 2.4.2p2) > > Was this an rpm installed version? No. I am running FreeBSD ports. I installed Amanda in January... I think it was done using the FreeBSD ports collection. > And whats an 'amcheck /config/' report? %amcheck daily Amanda Tape Server Host Check - NOTE: skipping tape-writable test Tape daily001 label ok NOTE: info dir /usr/local/etc/amanda/daily/curinfo: does not exist NOTE: it will be created on the next run Server check took 5.145 seconds Amanda Backup Client Hosts Check Client check: 1 host checked in 0.114 seconds, 0 problems found (brought to you by Amanda 2.4.2p2) > >I'm not really sure where to start looking for answers here. > >Can anyone suggest a starting point? > > Building your own from scratch has always worked here. I have a > short script that I use for the ./configure step so that each > succeeding version remains compatible with the previous one by > having the exact same options each time, and I'm currently > running the 2.4.3b3-20020422 snapshot with a seagate changer. I have no changer... A script sounds like a good idea. Thanks, Shawn
unsubscribe
[EMAIL PROTECTED]
Re: disk offline
On Tuesday 23 April 2002 02:38 am, GIC MLs wrote: >I would expect this to be a frequently asked question, but after > looking through Google, I didn't see much specifically on it, > so... > >My amdump email report starts out: > >These dumps were to tape daily001. >The next tape Amanda expects to use is: daily001. This in itself, is odd, very odd. Your amanda.conf seems to be out of whack somehow. [snip] > >(brought to you by Amanda version 2.4.2p2) Was this an rpm installed version? And whats an 'amcheck /config/' report? >I'm not really sure where to start looking for answers here. >Can anyone suggest a starting point? Building your own from scratch has always worked here. I have a short script that I use for the ./configure step so that each succeeding version remains compatible with the previous one by having the exact same options each time, and I'm currently running the 2.4.3b3-20020422 snapshot with a seagate changer. >Thanks, > >Shawn -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 98.8+% setiathome rank, not too shabby for a hillbilly
Re: Tar patch
On Tuesday 23 April 2002 12:44 am, Vijay Kumar wrote: >hi! > > >How do i apply the Tar patfch in the patches directory? >I am using tar 1.13.19 . Do i still need the patch? > >thanks for any replies, > >Vijay No, that, or 1.13.25, the latest 'alpha' version, appear to be good according to reports coming in here. I've been using 1.13.19 for much of a year here. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 98.8+% setiathome rank, not too shabby for a hillbilly
