On Mon, Sep 20, 2010 at 6:56 PM, Jon LaBadie wrote:
> Looks better to my eye. Any one else?
With Jean-Louis' review, committed in r3428. Thanks!
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
On Mon, Sep 20, 2010 at 04:22:34PM -0500, Dustin J. Mitchell wrote:
> On Thu, Sep 16, 2010 at 4:52 PM, Dustin J. Mitchell wrote:
> > Are you working on this? ??Perhaps someone else on the list can jump in?
>
> Hmm, well, I just took care of this:
>
> http://github.com/djmitche/amanda/commit/z1
On Thu, Sep 16, 2010 at 4:52 PM, Dustin J. Mitchell wrote:
> Are you working on this? Perhaps someone else on the list can jump in?
Hmm, well, I just took care of this:
http://github.com/djmitche/amanda/commit/z11908.patch
Total Full Incr. Level:#
On Thu, Sep 9, 2010 at 11:05 PM, Dustin J. Mitchell wrote:
> I don't mean to put you on the spot - like I said, I can take care of
> this if you'd prefer.
Are you working on this? Perhaps someone else on the list can jump in?
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
On Thu, Sep 9, 2010 at 10:26 PM, Jon LaBadie wrote:
> First, what I call a DLE is refered to as Filesystem some places and
> disk others.
>
> Second I don't like the repeating extra column headings printed 3
> times after the Incr. column. The headings should be moved to the
> top and the unneces
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).
Ok, here is an easy one for you; or some
1. Where can I find detailed documentation on what each of the values
provided in the statistics means and if/how they should add up?
2. When Amanda does its estimates for individual file systems being backed up
with dump , how does it do it?
Does it do the same procedure for L0 dumps as for
On Thu, 16 Jun 2005, Erik P. Olsen wrote:
Below the statistics from my last backup. I assume the times are all
elapsed times, but why is amanda so wrong in estimating the times? Or is
it a bug?
STATISTICS:
Total Full Daily
Erik P. Olsen schrieb:
Hi,
Below the statistics from my last backup. I assume the times are all
elapsed times, but why is amanda so wrong in estimating the times? Or is
it a bug?
STATISTICS:
Total Full Daily
Hi,
Below the statistics from my last backup. I assume the times are all
elapsed times, but why is amanda so wrong in estimating the times? Or is
it a bug?
STATISTICS:
Total Full Daily
Estimate Time
|The 1.13-25 version is on alpha.gnu.org now for about a year, but
|the tarballs of either will compile just fine on your machines as
|long as the developer stuff is on them.
|
|FWIW, 1.13-19 is also reported to work well with amanda. I was
|automaticly recommending the latest just because its th
On Thursday 05 September 2002 00:52, Chris Herrmann wrote:
>Thanks Gene! Hopefully you've answered my question without me
> needed to ask it :o)
>
>I'm assuming I need to upgrade tar on the client machine, not the
> amanda server...?
Where ever its actually being used, which I'd assume would be b
ROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Gene Heskett
|Sent: Thursday, 5 September 2002 12:26
|To: Chris Herrmann; 'greg'; [EMAIL PROTECTED]
|Subject: Re: statistics
|
|
|On Wednesday 04 September 2002 18:53, Chris Herrmann wrote:
|>yes - that's right. the slow part is
On Wednesday 04 September 2002 18:53, Chris Herrmann wrote:
>yes - that's right. the slow part is your computer compressing the
> data. The "offline" message is a "yet to be crafted" question for
> this list - amanda isn't backing up the reiserfs partition on one
> of the machines. The drive is a
You guys are right. It is that the holding disk is not big enough so amanda
is not using it.
All the network data is rsyncd to this machine and then backed up locally.
This is to have
a running mirror and a tape backup. But I do believe the problem is the
holding disk which I am
working on fixin
since the tape may have to repeatedly stop and
reposition itself as the data trickles in.
Frank
--On Thursday, September 05, 2002 15:29:39 -0700 greg <[EMAIL PROTECTED]> wrote:
> Does this look right?
>
>
> STATISTICS:
> Total
On Thu, Sep 05, 2002 at 03:29:39PM -0700, greg wrote:
> Does this look right?
>
> STATISTICS:
> Total Full Daily
>
> Estimate Time (hrs:min)0:06
> Run Time (hrs:min)11:48
These dumps were to tape Loyalty003.
The next tape Amanda expects to use is: Loyalty004.
FAILURE AND STRANGE DUMP SUMMARY:
diablo /dev/hde1 lev 0 FAILED [disk /dev/hde1 offline on diablo?]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min) 0:04
Run Time (hrs:min) 6
On Thu, 5 Sep 2002 at 3:29pm, greg wrote
> Run Time (hrs:min)11:48
> Dump Time (hrs:min) 11:42 11:42 0:01
> Output Size (meg) 24171.424171.40.0
> Original Size (meg) 54320.454318.32.1
> Avg Compressed Size (%)44.5 44.51.
Does this look right?
STATISTICS:
Total Full
Daily
Estimate Time
(hrs:min) 0:06Run Time
(hrs:min) 11:48Dump Time
(hrs:min)
11:42 11:42
0:01Output Size (meg
>... I looked at amgetconf to
>find the configuration directory but could not find the right entry in
>amanda.conf.
This will do it:
amadmin xx version \
| grep CONFIG_DIR= \
| sed -e 's/.*CONFIG_DIR="//' -e 's/".*//'
I took a note to see if amgetconf could be taught to return some of
"John R. Jackson" <[EMAIL PROTECTED]> writes:
[...]
> >Please feel free to modify the script. May it save you from worn out
> >tapes at restore time.
>
> A couple of thoughts. Once you know the config directory from above,
> you might just cd there to avoid the duplicated names throughout the
Hi,
This little script can be used to keep track of number of tape
usages. I use it with recent GNU tools on a Linux machine.
Multiple skript calls per configuration and day do no harm thanks to
"uniq" and file time comparison. The calling user needs write access
to the config dir in /etc/amanda
23 matches
Mail list logo
