On Tue, Sep 05, 2006 at 10:09:10AM -0600, Charles Curley wrote:
| On Tue, Sep 05, 2006 at 04:09:05AM -0500, Phil Howard wrote:
| > On Sat, Sep 02, 2006 at 05:42:01PM -0600, Charles Curley wrote:
| >
| > | In addition, it would make bare metal recovery more difficult. If you
| > | back up to a file system any Linux live CD (finnix, knoppix...) can
| > | read, recovery is easy: the tools you need are already on the live
| > | CD. The tools include a suitable file system driver for the
| > | partition. Back up to a bare partition, and you would need special
| > | tricks or possibly special software to read it.
| >
| > If tar can read from raw tape, it can read from raw disk. I've already
| > done that several times for various things. Bare metal recovery will
| > need at a minimum the tar or dump utility depending on format used.
|
| If you write to raw disk (e.g. tar -cf /dev/sdc.. ), how do you get
| more than one tarball onto the partition? As far as I know, there is
| nothing analogous to the no rewind tape device for disk drives. Amanda
| is quite capable of generating multiple tarballs per backup. So you
| will need multiple partitions, each large enough to hold the largest
| possible tarball.
If what you refer to is concatenating tarballs, e.g. as on tape with no
"tape mark" between them, then they would be written into the same disk
partition. But if you refer to having each tarball, if on tape as being
separate tape files, e.g. writing a tape mark between, then in disk that
would be in a new partition.
Think of it in terms of how a tape-emulation-on-disk driver in the OS
would do it. It would give the process the device semantics of a tape.
So the process can do the ioctl() to write a tape mark when it ends a
tape file and wants to write the next one. When the TEOD driver gets
a request to write a tape mark, it would actually update the partition
table of the partition it was just writing to reflect exactly how much
was written. Then it would add a 2nd partition, which for MSDOS style
partitions can be done by adding an "extended" entry in the previous
table pointing to the next sector after the 1st partition, and write a
new table there with a new partition entry (and a new dummy "extended"
entry sitting idle until a 3rd partition is needed after the 2nd tape
mark gets written). When the process then proceeds to write the next
block of data, that data is written into the 2nd partition. The TEOD
driver would remember the state of the emulated tape. For example a
rewind operation would change the state to "file 1, offset 0". An
operation to forward space 1 file would change the state to increment
the file number by 1 and reset the offset to 0.
If this were done as an OS driver, emulating a tape drive, Amanda would
not really know any difference (unless it does stuff like time how long
a rewind takes and go nuts because it took only a couple milliseconds).
And you could still do a "bare metal" recovery as long as the partitions
on disk were compatible (which is why, if I write such a driver in Linux
I would use the MSDOS partition table format). You'd even have TWO ways
to do it. If the OS driver is there during recovery, just access the
emulated tape device node as a tape device and proceed normally. If the
OS driver is NOT there (because it was a module that has been lost and
needs to be recovered), then let tar read from disk partitions in the
order: 1,5,6,7,8,9,10... and so on, for each "tape file".
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
|
