Talk:Application API: Difference between revisions
1145151427 (talk | contribs) No edit summary |
(Media Formats) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
== Media Formats == | |||
The following was on the main page, but seems to be to be a small, easy design decision at some point down the road (phase 3 or 4). It's here for posterity, anyway. | |||
At present, there are two tape formats: Traditional and Spanned. In the future, more formats might be added. The Application API will not change this. Indeed, the on-tape format will not change at all; you could still restore a '''gnutar''' dump under the Application API using some earlier version of Amanda. The only thing that changes is the terminology: | |||
=== Traditional === | |||
When dumping, we continue to write a 32k Amanda header followed by the complete set of collections provided by the client. As before, these are written as 32K tape blocks. On restore, we can use the BSR command to seek the tape drive to the appropriate tape block, and then read the desired collections. Thus the index need only store the byte offset of each collection. | |||
To recover without Amanda, you can still use <tt>dd</tt> to read the tape contents into the tool directly. | |||
=== Spanned === | |||
When using the Spanned tape format with the Application API, we again take the complete set of collections provided by the client, treating it as a single BLOB, and dividing it into chunks. We continue to write a 32k Amanda header at the beginning of each chunk, followed by a number of 32k tape blocks. On restore, we again can use the BSR command to find the appropriate tape block and read the desired collections. Under this scenario, we must again note where each collection is stored. This could be done by storing the byte-offset of each collection, along with chunk information for the job as a whole, or else by storing the chunk and byte offset for each piece of each collection. | |||
=== Future === | |||
There are several limitations in the existing tape formats that may be addressed in the future. A new tape format might also take better advantage of Application API features. But such a change is not directly connected to or required by this API. | |||
Latest revision as of 20:07, 12 December 2008
Media Formats
The following was on the main page, but seems to be to be a small, easy design decision at some point down the road (phase 3 or 4). It's here for posterity, anyway.
At present, there are two tape formats: Traditional and Spanned. In the future, more formats might be added. The Application API will not change this. Indeed, the on-tape format will not change at all; you could still restore a gnutar dump under the Application API using some earlier version of Amanda. The only thing that changes is the terminology:
Traditional
When dumping, we continue to write a 32k Amanda header followed by the complete set of collections provided by the client. As before, these are written as 32K tape blocks. On restore, we can use the BSR command to seek the tape drive to the appropriate tape block, and then read the desired collections. Thus the index need only store the byte offset of each collection.
To recover without Amanda, you can still use dd to read the tape contents into the tool directly.
Spanned
When using the Spanned tape format with the Application API, we again take the complete set of collections provided by the client, treating it as a single BLOB, and dividing it into chunks. We continue to write a 32k Amanda header at the beginning of each chunk, followed by a number of 32k tape blocks. On restore, we again can use the BSR command to find the appropriate tape block and read the desired collections. Under this scenario, we must again note where each collection is stored. This could be done by storing the byte-offset of each collection, along with chunk information for the job as a whole, or else by storing the chunk and byte offset for each piece of each collection.
Future
There are several limitations in the existing tape formats that may be addressed in the future. A new tape format might also take better advantage of Application API features. But such a change is not directly connected to or required by this API.