+Kern;;;2005/07/26;;;14:30
+BACULA COMMUNITY NEWS RELEASE
+Backup Data Encryption Development Project
+26 July 2005
+
+WHAT
+After initial discussions between Bacula project manager Kern
+Sibbald, freelance open source developer Landon Fuller, and Craig
+Thompson, President of WingNET Internet Services, an agreement
+has been reached to begin work on the inclusion of data
+encryption as an integral part of Bacula.
+
+WHY
+The purpose of this project is to provide backup clients with the
+ability to securely encrypt their data for storage on Bacula
+storage servers without having to worry about the possibility of
+the data being accessed either by hackers or third parties. Data
+that is encrypted on Volumes on the remote server can give your
+customer (or CEO) an additional peace of mind that makes the
+difference between a sale or no sale.
+
+WHO
+WingNET recently expressed an interest in seeing this
+functionality developed. The concept had also been requested by
+numerous individuals and companies in the recent past on the
+various Bacula mailing lists. Kern suggested asking Landon to
+work on the project in order to speed up the process.
+
+HOW
+Landon Fuller has agreed to begin working on the project. As
+compensation for his time, his goal is to raise approximately
+$3,000 for donation to the Electronic Freedom Foundation.
+WingNET has offered to provide an initial donation of $500 for
+the project. However, YOUR support is needed to make the project
+a success. The data encryption project needs individuals and
+companies who would be willing to donate any amount of money
+toward the completion of the project.
+
+WHERE
+You may contribute by going to the EFF site donation page at:
+
+https://secure.eff.org/site/SPageServer?pagename=DON_splash&JServSessionIdr006=h0do7dkvl1.app2a
+
+and clicking on the "Gift Memberships >>" button. You will be
+asked to provide "Tribute Information" and to select an eCard
+recipient. Please use "The Bacula Project" as the honored
+individual name, and please choose to send an eCard, including
+the amount, to Kern Sibbald <kern at sibbald dot com>. It is not
+necessary to specify a snail-mail notification address.
+
+By correctly sending an eCard, including the donation amount, we can
+track the total amount donated for this project.
+
+Can your company contribute $250 or $500? How about $100? And
+if your budget is really tight, why not forego a couple of fast
+food meals and contribute $20?
+
+This is a community project, and this can be your way of helping make
+Bacula an even better product for the good of the whole community.
+
+If you have any questions related to this project, please contact
+Kern Sibbald <kern at sibbald dot com>.
+
+
Kern;;;2005/04/26;;;12:00
The Bacula Version 1.36.3 tar file is released to Source Forge.
</tr>
<tr>
+ <td class="content">
+
+ <ul>
+ <li><a href="bacula-web/index.html">Bacula-web Guide</a>
+ <br>(Guide for the Bacula-web GUI application)</li>
+ </ul>
+ </td>
+
<td class="content">
<ul>
<br>(Guide for Bacula developers)</li>
</ul>
</td>
- <td class="content">
-
- </td>
</tr>
</table>
<p>
Default setting for Hardware End of Medium is {\bf Yes}. This function is
used before appending to a tape to ensure that no previously written data is
- lost. We recommend if you have a non standard or unusual tape drive that you
+ lost. We recommend if you have a non-standard or unusual tape drive that you
use the {\bf btape} program to test your drive to see whether or not it
supports this function. All modern (after 1998) tape drives support this
feature.
- If you set Hardware End of Medium = no, you should also set {\bf Fast Forward
- Space File = no}. If you do not, Bacula will most likely be unable to
- correctly find the end of data on the tape.
-
\item [Fast Forward Space File = {\it Yes|No}]
\index[sd]{Fast Forward Space File }
If {\bf No}, the archive device is not required to support keeping track of
but they do not keep track of the file number or more seriously, they do not
report end of meduim.
- Default setting for Fast Forward Space File is {\bf Yes}. If you disable
- Hardware End of Medium, most likely you should also disable Fast Forward
- Space file. The {\bf test} command in the program {\bf btape} will test this
- feature and advise you if it should be turned off.
+ Default setting for Fast Forward Space File is {\bf Yes}.
\item [Use MTIOCGET = {\it Yes|No}]
\index[sd]{Fast Forward Space File }
is {\bf Yes}. If you must set this to No, Bacula will do the proper file
position determination, but it is very unfortunate because it means that
tape movement is very inefficient.
- Fortunately, this operation system deficiency seems to be the case only on
- a few *BSD systems. Operating systems known to work correctly are Solaris, Linux
- and FreeBSD.
+ Fortunately, this operation system deficiency seems to be the case only
+ on a few *BSD systems. Operating systems known to work correctly are
+ Solaris, Linux and FreeBSD.
\item [BSF at EOM = {\it Yes|No}]
\index[sd]{BSF at EOM }
sequentially recover each of the blocks it has written by using the same
number of sequential reads as it had written.
+\subsection*{Details of Tape Modes}
+\index[general]{Modes!Details}
+\index[general]{Details of Tape Modes }
+\addcontentsline{toc}{subsection}{Details of Tape Modes}
+Rudolf Cejkar has provided the following information concerning
+certain tape modes and MTEOM.
+
+\begin{description}
+\item[Tape level]
+ It is always possible to position filemarks or blocks, whereas
+ positioning to the end-of-data is only optional feature, however it is
+ implemented very often. SCSI specification also talks about optional
+ sequential filemarks, setmarks and sequential setmarks, but these are not
+ implemented so often. Modern tape drives keep track of file positions in
+ built-in chip (AIT, LTO) or at the beginning of the tape (SDLT), so there
+ is not any speed difference, if end-of-data or filemarks is used (I have
+ heard, that LTO-1 from all 3 manufacturers do not use its chip for file
+ locations, but a tape as in SDLT case, and I'm not sure about LTO-2 and
+ LTO-3 case). However there is a big difference, that end-of-data ignores
+ file position, whereas filemarks returns the real number of skipped
+ files, so OS can track current file number just in filemarks case.
+
+\item[OS level]
+ Solaris does use just SCSI SPACE Filemarks, it does not support SCSI
+ SPACE End-of-data. When MTEOM is called, Solaris does use SCSI SPACE
+ Filemarks with count = 1048576 for fast mode, and combination of SCSI
+ SPACE Filemarks with count = 1 with SCSI SPACE Blocks with count = 1 for
+ slow mode, so EOD mark on the tape on some older tape drives is not
+ skipped. File number is always tracked for MTEOM.
+
+ Linux does support both SCSI SPACE Filemarks and End-of-data: When MTEOM
+ is called in MT_ST_FAST_MTEOM mode, SCSI SPACE Filemarks with count =
+ 8388607 is used. In the other case, SCSI SPACE End-of-data is used.
+ There is no real slow mode like in Solaris - I just expect, that for
+ older tape drives Filemarks may be slower than End-of-data, but not so
+ much as in Solaris slow mode. File number is tracked for MTEOM just
+ without MT_ST_FAST_MTEOM - when MT_ST_FAST_MTEOM is used, it is not.
+
+ FreeBSD does support both SCSI SPACE Filemarks and End-of-data, but when
+ MTEOD (MTEOM) is called, SCSI SPACE End-of-data is always used. FreeBSD
+ never use SCSI SPACE Filemarks for MTEOD. File number is never tracked
+ for MTOED.
+
+\item[Bacula level]
+ When {\bf Hardware End of Medium = Yes} is used, MTEOM is called, but it
+ does not mean, that hardware End-of-data must be used. When Hardware End
+ of Medium = No, if Fast Forward Space File = Yes, MTFSF with count =
+ 32767 is used, else Block Read with count = 1 with Forward Space File
+ with count = 1 is used, which is really very slow.
+
+\item [Hardware End of Medium = Yes|No]
+ The name of this option is misleading and is the source of confusion,
+ because it is not the hardware EOM, what is really switched here.
+
+ If I use Yes, OS must not use SCSI SPACE End-of-data, because Bacula
+ expects, that there is tracked file number, which is not supported by
+ SCSI specification. Instead, the OS have to use SCSI SPACE Filemarks.
+
+ If I use No, an action depends on Fast Forward Space File.
+
+ Considering {\bf Hardware End of Medium = no}
+ and {\bf Fast Forward Space File = no}
+ When I set the two to no, file positioning was very slow
+ on my LTO-3:
+\begin{verbatim}
+ HEOM = no, FFSF = no: ~ 10 - 100 minutes
+\end{verbatime}
+
+while even with {\bf Hardware End of Medium = no} but
+{\bf Fast Forward Space File = yes}, the time is 10 to
+100 times faster.
+\begin{verbatim}
+ HEOM = no, FFSF = yes: ~ 1 minute
+\end{verbatim}
+
+\end{description}
+
\subsection*{Autochanger Errors}
\index[general]{Errors!Autochanger }
\index[general]{Autochanger Errors }
projects / bacula / docs / commitdiff