Re: Nitpick: routine expected tape errors
On Sun, Sep 12, 2010 at 11:17 PM, Dustin J. Mitchell dus...@zmanda.com wrote:
It includes a rewrite of amdump.sh into amdump.pl. The command-line
argument handling in shell was just too gnarly to figure out, and
shell is generally fraught with more portability problems than it's
worth.
Hooray! This is committed in r3392. You can now run
amdump $config --no-taper
and the taper won't even start, let alone fail with an expected error.
Would you mind writing up a How To article on the wiki about this?
It doesn't need to be long.
In my testing, the resulting report looks like
Hostname: euclid
Org : Conf
Config : Conf
Date: September 13, 2010
There are 90K of dumps left in the holding disk.
Run amflush to flush them to tape.
The next tape Amanda expects to use is: 1 new tape.
STATISTICS:
Total Full Incr.
Estimate Time (hrs:min) 0:00
Run Time (hrs:min) 0:00
Dump Time (hrs:min) 0:00 0:00 0:00
Output Size (meg)0.10.10.0
Original Size (meg) 0.10.10.0
Avg Compressed Size (%)100.0 100.0--
Filesystems Dumped 1 1 0
Avg Dump Rate (k/s) 17.9 17.9--
Tape Time (hrs:min) 0:00 0:00 0:00
Tape Size (meg) 0.00.00.0
Tape Used (%)0.00.00.0
Filesystems Taped 0 0 0
Parts Taped0 0 0
Avg Tp Write Rate (k/s) -- -- --
NOTES:
planner: Adding new disk euclid:/A/p/etc.
DUMP SUMMARY:
DUMPER STATS TAPER STATS
HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
-- - -
euclid /A/p/etc0 90 90 --0:05 17.9
(brought to you by Amanda version 3.2.0alpha)
--
Open Source Storage Engineer
http://www.zmanda.com
Re: Nitpick: routine expected tape errors
On Thu, Sep 9, 2010 at 12:12 PM, Dustin J. Mitchell dus...@zmanda.com wrote: This is a great idea. I'm actually working on this part of the code right now, to make sure that amflush and autoflush will correctly flush dumps that are no longer in the disklist, so I think this will be relatively easy to add. I have a patch for this awaiting review now: http://github.com/djmitche/amanda/commit/z11898 It includes a rewrite of amdump.sh into amdump.pl. The command-line argument handling in shell was just too gnarly to figure out, and shell is generally fraught with more portability problems than it's worth. Dustin -- Open Source Storage Engineer http://www.zmanda.com
Nitpick: routine expected tape errors
On 9/9/10 11:55 AM, Dustin J. Mitchell wrote: I bet most of you have some small nitpick with Amanda that you've never felt warranted an email. Well, now's your chance! I'd like to put some polish on Amanda, and it's hard for me to see the areas that need burnishing, since I work on Amanda all day, every day. - typo in a manpage? - command-line usage oddity? - confusing use of terminology? - something else? Start up a new thread on the mailing list, or email me privately if you'd prefer, to let me know what's bugging you. Bonus points for also supplying a patch, but that's not at all required! Note that I do reserve the right to say, actually, that's complicated (and explain why). Dustin One learns in a relationship not to nitpick. But, then, since we're talking about Amanda the beautiful open source software program and not a beautiful woman one is in a relationship with, I suppose it's alright. So, . . . I have configurations (and I know others do as well) in which I want certain days to go to holding disk only and later get flushed to tape along with the regular backups that go to tape. For example, run a regular backup at the end of every weekday, but run incrementals only on weekends and just keep them on the holding disk. That saves tapes and stretches how many weeks I have covered in the routine rotation. To do that, I use the command line options to redefine the tape library and tape drive so that they don't go to my Sony AIT5 Library. The result is that the Amanda email report on those days starts out with *** A TAPE ERROR OCCURRED: [No writable valid tape found]. I know to expect those, although sometimes I'm caught off guard for one reason or another, and it may take a moment for my brain to kick in and say, it's alright. However, when I'm on vacation, and someone else is watching over things, they are more likely to get confused and worried. If there were a way to directly say, fall back, don't tape, or --disable-taper, then that would avoid the expected error message. -- --- Chris Hoogendyk - O__ Systems Administrator c/ /'_ --- Biology Geology Departments (*) \(*) -- 140 Morrill Science Center ~~ - University of Massachusetts, Amherst hoogen...@bio.umass.edu --- Erdös 4
Re: Nitpick: routine expected tape errors
On Thu, Sep 9, 2010 at 11:56 AM, Chris Hoogendyk
hoogen...@bio.umass.edu wrote:
If there were a way to directly say, fall back, don't tape, or
--disable-taper, then that would avoid the expected error message.
This is a great idea. I'm actually working on this part of the code
right now, to make sure that amflush and autoflush will correctly
flush dumps that are no longer in the disklist, so I think this will
be relatively easy to add.
I have dreams of coming up with some broader way to indicate which
parts of the backup process should run. Once we add amvault to the
process, there are legitimate reasons to want to run any combination
of {dumper, taper, amvault}.
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
