On 2006-06-13 12:55, Toralf Lund wrote:
Paul Bijnens wrote:
On 2006-06-13 12:10, Toralf Lund wrote:
Yes indeed. The whole DLE. A singe DLE still needs to be written
in one run, possibly using many tapes.
Oh no... Like I said, that's a big disappointment. I'm tempted to
say that it is not correct to claim that Amanda now suppots tape
spanning, if it can't span dumps across tapes written in separate runs.
Shouldn't it be able to delete the corresponding data from the
holding disk file as tape-chunks are successfully written - so that
only the remaining chunks would be flushed on the next run? Seems
like this should be easy enough to implement, especially if you
interact with holding disk chunks in a constructive manner. Is there
any reason why nobody has looked into this, except for lack of time?
... or maybe what's on the holding disk does not really matter and/or
is a separate issue. I suppose the taper already knows how to find a
certain tape-chunk within the holding disk data, so it's more a
matter of being able to tell it to start writing from a certain chunk
(different from 0) during flush. The flush operation would obviously
have to find the correct index somewhere in the database. Does it do
a lookup at all today, or just blindly tape whatever is on the
holding disk?
Taping one DLE is several "runs" opens a can of worms: you have to
add a notion of "partial" succeeded. Restoring then needs some tapes
and some holdingdisk files. What if the holdingdisk crashes or
accidently rm the files before all of it is written to tape? etc.
This would be a bit of an issue, of course. I'm wondering if the would
the situation be that much different from the one we have today, though.
Holding disk crash or file removal is always going to be a serious
problem, of course. But if you have a partial tape dump of the data, you
will at least be able to recover some of it... Maybe it would be wise to
keep all data on the disk until all tape-chunks are fully written,
though, and also use the "partial" status only for flush purposes, i.e.
consider "partial" writes as "unsuccessful" when doing restore etc.
What happens in the current version if amdump is interrupted while
writing the 2nd tape, by the way?
As Stefan used to say: AAPW(*).
Well, yes. I was partly also asking if a P would be W in this case,
though, or if someone for some good reason had decided that tape split
across runs should not be supported.
I think any AP would very W. :-)
It could also help the current minor problem that taping starts only
when the DLE is completely dumped to holdingdisk.
The current implementation also assumes the tape chunks follow
sequentially on the tape. This is not strictly necessary either.
Allowing tape-chunks to be interspersed with chunks from other DLE's
together with multi-run taping... Wow, that would make Amanda really
one of the best free backup programs!
Only a small step further and you can use the gnutar option
--record-number (show record number within archive of a particular
file) making it possible to restore from only a few tape-chunks,
instead of feeding the complete 300 Gbyte image to tar, to extract
only one file, which happens to be at the end of the image by
murphy's law anyway. :-)
--
Paul Bijnens, xplanation Technology Services Tel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM Fax +32 16 397.512
http://www.xplanation.com/ email: Paul.Bijnens AT xplanation DOT com
***********************************************************************
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***********************************************************************
|
