Paul,
we are running amanda v.2.4.5, on FC3. These are
forced full dumps (dumplevel 0). I do not use negative chuncksize, but I do use
negative "usedisk" (when you set how much of a disk must stay un-occupied by
disk images). Do you think it may be somehow related?
Also, I double-checked
[EMAIL PROTECTED] wrote:
...
taper: wrote label `weekly3' date `20050901'
dumper: kill index command
driver: result time 39992.417 from dumper0: FAILED 00-00029 ["data write: Connection
reset by peer"]
driver: result time 39992.417 from taper: TRY-AGAIN 00-00029 [writing file: No
space left on
Actually it was set to 0, since I it suppose to be archival dump(no
incremental)
Jon LaBadie <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 01, 2005 at 02:40:14PM -0400, [EMAIL PROTECTED] wrote:
> >
> >
> > Also, I'm positive, that we had enough space for holding disk to hold
> > this particuar
On Thu, Sep 01, 2005 at 02:40:14PM -0400, [EMAIL PROTECTED] wrote:
>
>
> Also, I'm positive, that we had enough space for holding disk to hold
> this particuar FS. Why did it start "directly to tape" (log's the very
> first line)?
Have you adjusted the holding disk "reserve" parameter?
By defau
Hello, guys,
I've been asking about the "retry behavior" and how to delay the dumps about
couple days ago. Dump delaying conf. command worked (somewhat - as far as dump
delaying goes ;) ), but it does not seem to solve the problem - we still have 2
FS failing, because of "No space left", and on
wrote:
Here is the problem. For the full dumps we use 4 tapes (40G) on a run.
"Short" filesystems are copied over without any problems, problems start
with big filesystems.
Surprizingly, we found out that only 3 tapes were used, but 2 "big" FS
failed to go on tape, because there were "no spac
On Tue, Aug 30, 2005 at 05:19:29PM -0400, [EMAIL PROTECTED] wrote:
>
> NOTES:
> taper: tape weekly1 kb 35900256 fm 14 writing file: No space left on device
> taper: retrying zeus: /hmssql.0 on new tape: [writing file: No space left
> on device]
> taper: tape weekly2 kb 35878464 fm 3 writing
On Tue, Aug 30, 2005 at 05:19:29PM -0400, [EMAIL PROTECTED] wrote:
> Hello all,
>
> We have recently decided to add archival (full) dumps configuration (weekly).
> And it is not running as smoothly as we hoped.
>
> Here is the problem. For the full dumps we use 4 tapes (40G) on a run.
> "Shor
Hello all,
We have recently decided to add archival (full) dumps configuration (weekly).
And it is not running as smoothly as we hoped.
Here is the problem. For the full dumps we use 4 tapes (40G) on a run. "Short"
filesystems are copied over without any problems, problems start with big
fil
