From 43496387c4936e1bfa0de048d6e1e2c63cef5b06 Mon Sep 17 00:00:00 2001 From: Thomas Glatthor Date: Thu, 13 Sep 2007 09:47:58 +0000 Subject: [PATCH] added and deleted some files that are no longer in the manual/ or new --- docs/manual-de/copy.tex | 36 --- docs/manual-de/dataencryption.tex | 195 +++++++++++++ docs/manual-de/migration.tex | 445 ++++++++++++++++++++++++++++++ docs/manual-de/supported.tex | 216 --------------- 4 files changed, 640 insertions(+), 252 deletions(-) delete mode 100644 docs/manual-de/copy.tex create mode 100644 docs/manual-de/dataencryption.tex create mode 100644 docs/manual-de/migration.tex delete mode 100644 docs/manual-de/supported.tex diff --git a/docs/manual-de/copy.tex b/docs/manual-de/copy.tex deleted file mode 100644 index b2ffc9ec..00000000 --- a/docs/manual-de/copy.tex +++ /dev/null @@ -1,36 +0,0 @@ -\vspace*{6cm} -\begin{center} - \copyright\ Copyright 2000-2005 --\pubyear\ \company -\end{center} - -\begin{center} - All Rights Reserved -\end{center} - -This publication, or parts thereof, may not be reproduced in any form, by any -method, for any purpose. - -\company\ makes no warranty, either express or implied, including but not -limited to any implied warranties of merchantability and fitness for a -particular purpose, regarding these materials and makes such materials -available solely on an "as-is" basis. - -In no event shall \company\ be liable to anyone for special, collateral, -incidental, or consequential damages in connection with or arising out of -purchase or use of these materials. The sole and exclusive liability to -\company\ regardless of the form of action, shall not exceed the purchase -price of the materials described herein. - -For condition of use and permission to use these materials for publication in -other than the English language, contact \company - -\company\ reserves the right to revise and improve its products as it sees -fit. This publication describes the state of this product as of the time of -its publication, and may not reflect the product at all times in the future. - -This manual was prepared and published in \pubmonth of \pubyear, and is based -on Release \levelno of \prog. - -MS-DOS and Windows are a registered trademarks of Microsoft. -\clearpage -\tableofcontents diff --git a/docs/manual-de/dataencryption.tex b/docs/manual-de/dataencryption.tex new file mode 100644 index 00000000..34b050fe --- /dev/null +++ b/docs/manual-de/dataencryption.tex @@ -0,0 +1,195 @@ + +\chapter{Data Encryption} +\label{DataEncryption} +\index[general]{Data Encryption} +\index[general]{Encryption!Data} +\index[general]{Data Encryption} + +Bacula permits file data encryption and signing within the File Daemon (or +Client) prior to sending data to the Storage Daemon. Upon restoration, +file signatures are validated and any mismatches are reported. At no time +does the Director or the Storage Daemon have access to unencrypted file +contents. + + +It is very important to specify what this implementation does NOT +do: +\begin{itemize} +\item There is one important restore problem to be aware of, namely, it's + possible for the director to restore new keys or a Bacula configuration + file to the client, and thus force later backups to be made with a + compromised key and/or with no encryption at all. You can avoid this by + not not changing the location of the keys in your Bacula File daemon + configuration file, and not changing your File daemon keys. If you do + change either one, you must ensure that no restore is done that restores + the old configuration or the old keys. In general, the worst effect of + this will be that you can no longer connect the File daemon. + +\item The implementation does not encrypt file metadata such as file path + names, permissions, and ownership. Extended attributes are also currently + not encrypted. However, Mac OS X resource forks are encrypted. +\end{itemize} + +Encryption and signing are implemented using RSA private keys coupled with +self-signed x509 public certificates. This is also sometimes known as PKI +or Public Key Infrastructure. + +Each File Daemon should be given its own unique private/public key pair. +In addition to this key pair, any number of "Master Keys" may be specified +-- these are key pairs that may be used to decrypt any backups should the +File Daemon key be lost. Only the Master Key's public certificate should +be made available to the File Daemon. Under no circumstances should the +Master Private Key be shared or stored on the Client machine. + +The Master Keys should be backed up to a secure location, such as a CD +placed in a in a fire-proof safe or bank safety deposit box. The Master +Keys should never be kept on the same machine as the Storage Daemon or +Director if you are worried about an unauthorized party compromising either +machine and accessing your encrypted backups. + +While less critical than the Master Keys, File Daemon Keys are also a prime +candidate for off-site backups; burn the key pair to a CD and send the CD +home with the owner of the machine. + +NOTE!!! If you lose your encryption keys, backups will be unrecoverable. +{\bf ALWAYS} store a copy of your master keys in a secure, off-site location. + +The basic algorithm used for each backup session (Job) is: +\begin{enumerate} +\item The File daemon generates a session key. +\item The FD encrypts that session key via PKE for all recipients (the file +daemon, any master keys). +\item The FD uses that session key to perform symmetric encryption on the data. +\end{enumerate} + + +\section{Building Bacula with Encryption Support} +\index[general]{Building Bacula with Encryption Support} + +The configuration option for enabling OpenSSL encryption support has not changed +since Bacula 1.38. To build Bacula with encryption support, you will need +the OpenSSL libraries and headers installed. When configuring Bacula, use: + +\begin{verbatim} + ./configure --with-openssl ... +\end{verbatim} + +\section{Encryption Technical Details} +\index[general]{Encryption Technical Details} + +The implementation uses 128bit AES-CBC, with RSA encrypted symmetric +session keys. The RSA key is user supplied. +If you are running OpenSSL 0.9.8 or later, the signed file hash uses +SHA-256 -- otherwise, SHA-1 is used. + +End-user configuration settings for the algorithms are not currently +exposed -- only the algorithms listed above are used. However, the +data written to Volume supports arbitrary symmetric, asymmetric, and +digest algorithms for future extensibility, and the back-end +implementation currently supports: + +\begin{verbatim} +Symmetric Encryption: + - 128, 192, and 256-bit AES-CBC + - Blowfish-CBC + +Asymmetric Encryption (used to encrypt symmetric session keys): + - RSA + +Digest Algorithms: + - MD5 + - SHA1 + - SHA256 + - SHA512 +\end{verbatim} + +The various algorithms are exposed via an entirely re-usable, +OpenSSL-agnostic API (ie, it is possible to drop in a new encryption +backend). The Volume format is DER-encoded ASN.1, modeled after the +Cryptographic Message Syntax from RFC 3852. Unfortunately, using CMS +directly was not possible, as at the time of coding a free software +streaming DER decoder/encoder was not available. + + +\section{Decrypting with a Master Key} +\index[general]{Decrypting with a Master Key} + +It is preferable to retain a secure, non-encrypted copy of the +client's own encryption keypair. However, should you lose the +client's keypair, recovery with the master keypair is possible. + +You must: +\begin{itemize} +\item Concatenate the master private and public key into a single + keypair file, ie: + cat master.key master.cert >master.keypair + +\item 2) Set the PKI Keypair statement in your bacula configuration file: + +\begin{verbatim} + PKI Keypair = master.keypair +\end{verbatim} + +\item Start the restore. The master keypair will be used to decrypt + the file data. + +\end{itemize} + + +\section{Generating Private/Public Encryption Keys} +\index[general]{Generating Private/Public Encryption Keypairs} + +Generate a Master Key Pair with: + +\footnotesize +\begin{verbatim} + openssl genrsa -out master.key 2048 + openssl req -new -key master.key -x509 -out master.cert +\end{verbatim} +\normalsize + +Generate a File Daemon Key Pair for each FD: + +\footnotesize +\begin{verbatim} + openssl genrsa -out fd-example.key 2048 + openssl req -new -key fd-example.key -x509 -out fd-example.cert + cat fd-example.key fd-example.cert >fd-example.pem +\end{verbatim} +\normalsize + +Note, there seems to be a lot of confusion around the file extensions given +to these keys. For example, a .pem file can contain all the following: +private keys (RSA and DSA), public keys (RSA and DSA) and (x509) certificates. +It is the default format for OpenSSL. It stores data Base64 encoded DER format, +surrounded by ASCII headers, so is suitable for text mode transfers between +systems. A .pem file may contain any number of keys either public or +private. We use it in cases where there is both a public and a private +key. + +Typically, above we have used the .cert extension to refer to X509 +certificate encoding that contains only a single public key. + + +\section{Example Data Encryption Configuration} +\index[general]{Example!File Daemon Configuration File} +\index[general]{Example!Data Encryption Configuration File} +\index[general]{Example Data Encryption Configuration} + +{\bf bacula-fd.conf} +\footnotesize +\begin{verbatim} +FileDaemon { + Name = example-fd + FDport = 9102 # where we listen for the director + WorkingDirectory = /var/bacula/working + Pid Directory = /var/run + Maximum Concurrent Jobs = 20 + + PKI Signatures = Yes # Enable Data Signing + PKI Encryption = Yes # Enable Data Encryption + PKI Keypair = "/etc/bacula/fd-example.pem" # Public and Private Keys + PKI Master Key = "/etc/bacula/master.cert" # ONLY the Public Key +} +\end{verbatim} +\normalsize diff --git a/docs/manual-de/migration.tex b/docs/manual-de/migration.tex new file mode 100644 index 00000000..b0d49df2 --- /dev/null +++ b/docs/manual-de/migration.tex @@ -0,0 +1,445 @@ + +\chapter{Migration} +\label{MigrationChapter} +\index[general]{Migration} + +The term Migration, as used in the context of Bacula, means moving data from +one Volume to another. In particular it refers to a Job (similar to a backup +job) that reads data that was previously backed up to a Volume and writes +it to another Volume. As part of this process, the File catalog records +associated with the first backup job are purged. In other words, Migration +moves Bacula Job data from one Volume to another by reading the Job data +from the Volume it is stored on, writing it to a different Volume in a +different Pool, and then purging the database records for the first Job. + +The section process for which Job or Jobs are migrated +can be based on quite a number of different criteria such as: +\begin{itemize} +\item a single previous Job +\item a Volume +\item a Client +\item a regular expression matching a Job, Volume, or Client name +\item the time a Job has been on a Volume +\item high and low water marks (usage or occupation) of a Pool +\item Volume size +\end{itemize} + +The details of these selection criteria will be defined below. + +To run a Migration job, you must first define a Job resource very similar +to a Backup Job but with {\bf Type = Migrate} instead of {\bf Type = +Backup}. One of the key points to remember is that the Pool that is +specified for the migration job is the only pool from which jobs will +be migrated, with one exception noted below. In addition, the Pool to +which the selected Job or Jobs will be migrated is defined by the {\bf +Next Pool = ...} in the Pool resource specified for the Migration Job. + +Bacula permits pools to contain Volumes with different Media Types. +However, when doing migration, this is a very undesirable condition. For +migration to work properly, you should use pools containing only Volumes of +the same Media Type for all migration jobs. + +The migration job normally is either manually started or starts +from a Schedule much like a backup job. It searches +for a previous backup Job or Jobs that match the parameters you have +specified in the migration Job resource, primarily a {\bf Selection Type} +(detailed a bit later). Then for +each previous backup JobId found, the Migration Job will run a new Job which +copies the old Job data from the previous Volume to a new Volume in +the Migration Pool. It is possible that no prior Jobs are found for +migration, in which case, the Migration job will simply terminate having +done nothing, but normally at a minimum, three jobs are involved during a +migration: + +\begin{itemize} +\item The currently running Migration control Job. This is only + a control job for starting the migration child jobs. +\item The previous Backup Job (already run). The File records + for this Job are purged if the Migration job successfully + terminates. The original data remains on the Volume until + it is recycled and rewritten. +\item A new Migration Backup Job that moves the data from the + previous Backup job to the new Volume. If you subsequently + do a restore, the data will be read from this Job. +\end{itemize} + +If the Migration control job finds a number of JobIds to migrate (e.g. +it is asked to migrate one or more Volumes), it will start one new +migration backup job for each JobId found on the specified Volumes. +Please note that Migration doesn't scale too well since Migrations are +done on a Job by Job basis. This if you select a very large volume or +a number of volumes for migration, you may have a large number of +Jobs that start. Because each job must read the same Volume, they will +run consecutively (not simultaneously). + +\section{Migration Job Resource Directives} + +The following directives can appear in a Director's Job resource, and they +are used to define a Migration job. + +\begin{description} +\item [Pool = \lt{}Pool-name\gt{}] The Pool specified in the Migration + control Job is not a new directive for the Job resource, but it is + particularly important because it determines what Pool will be examined for + finding JobIds to migrate. The exception to this is when {\bf Selection + Type = SQLQuery}, in which case no Pool is used, unless you + specifically include it in the SQL query. Note, the Pool resource + referenced must contain a {\bf Next Pool = ...} directive to define + the Pool to which the data will be migrated. + +\item [Type = Migrate] + {\bf Migrate} is a new type that defines the job that is run as being a + Migration Job. A Migration Job is a sort of control job and does not have + any Files associated with it, and in that sense they are more or less like + an Admin job. Migration jobs simply check to see if there is anything to + Migrate then possibly start and control new Backup jobs to migrate the data + from the specified Pool to another Pool. + +\item [Selection Type = \lt{}Selection-type-keyword\gt{}] + The \lt{}Selection-type-keyword\gt{} determines how the migration job + will go about selecting what JobIds to migrate. In most cases, it is + used in conjunction with a {\bf Selection Pattern} to give you fine + control over exactly what JobIds are selected. The possible values + for \lt{}Selection-type-keyword\gt{} are: + \begin{description} + \item [SmallestVolume] This selection keyword selects the volume with the + fewest bytes from the Pool to be migrated. The Pool to be migrated + is the Pool defined in the Migration Job resource. The migration + control job will then start and run one migration backup job for + each of the Jobs found on this Volume. The Selection Pattern, if + specified, is not used. + + \item [OldestVolume] This selection keyword selects the volume with the + oldest last write time in the Pool to be migrated. The Pool to be + migrated is the Pool defined in the Migration Job resource. The + migration control job will then start and run one migration backup + job for each of the Jobs found on this Volume. The Selection + Pattern, if specified, is not used. + + \item [Client] The Client selection type, first selects all the Clients + that have been backed up in the Pool specified by the Migration + Job resource, then it applies the {\bf Selection Pattern} (defined + below) as a regular expression to the list of Client names, giving + a filtered Client name list. All jobs that were backed up for those + filtered (regexed) Clients will be migrated. + The migration control job will then start and run one migration + backup job for each of the JobIds found for those filtered Clients. + + \item [Volume] The Volume selection type, first selects all the Volumes + that have been backed up in the Pool specified by the Migration + Job resource, then it applies the {\bf Selection Pattern} (defined + below) as a regular expression to the list of Volume names, giving + a filtered Volume list. All JobIds that were backed up for those + filtered (regexed) Volumes will be migrated. + The migration control job will then start and run one migration + backup job for each of the JobIds found on those filtered Volumes. + + \item [Job] The Job selection type, first selects all the Jobs (as + defined on the {\bf Name} directive in a Job resource) + that have been backed up in the Pool specified by the Migration + Job resource, then it applies the {\bf Selection Pattern} (defined + below) as a regular expression to the list of Job names, giving + a filtered Job name list. All JobIds that were run for those + filtered (regexed) Job names will be migrated. Note, for a given + Job named, they can be many jobs (JobIds) that ran. + The migration control job will then start and run one migration + backup job for each of the Jobs found. + + \item [SQLQuery] The SQLQuery selection type, used the {\bf Selection + Pattern} as an SQL query to obtain the JobIds to be migrated. + The Selection Pattern must be a valid SELECT SQL statement for your + SQL engine, and it must return the JobId as the first field + of the SELECT. + + \item [PoolOccupancy] This selection type will cause the Migration job + to compute the total size of the specified pool for all Media Types + combined. If it exceeds the {\bf Migration High Bytes} defined in + the Pool, the Migration job will migrate all JobIds beginning with + the oldest Volume in the pool (determined by Last Write time) until + the Pool bytes drop below the {\bf Migration Low Bytes} defined in the + Pool. This calculation should be consider rather approximative because + it is made once by the Migration job before migration is begun, and + thus does not take into account additional data written into the Pool + during the migration. In addition, the calculation of the total Pool + byte size is based on the Volume bytes saved in the Volume (Media) +database + entries. The bytes calculate for Migration is based on the value stored + in the Job records of the Jobs to be migrated. These do not include the + Storage daemon overhead as is in the total Pool size. As a consequence, + normally, the migration will migrate more bytes than strictly necessary. + + \item [PoolTime] The PoolTime selection type will cause the Migration job to + look at the time each JobId has been in the Pool since the job ended. + All Jobs in the Pool longer than the time specified on {\bf Migration Time} + directive in the Pool resource will be migrated. + \end{description} + +\item [Selection Pattern = \lt{}Quoted-string\gt{}] + The Selection Patterns permitted for each Selection-type-keyword are + described above. + + For the OldestVolume and SmallestVolume, this + Selection pattern is not used (ignored). + + For the Client, Volume, and Job + keywords, this pattern must be a valid regular expression that will filter + the appropriate item names found in the Pool. + + For the SQLQuery keyword, this pattern must be a valid SELECT SQL statement + that returns JobIds. + +\end{description} + +\section{Migration Pool Resource Directives} + +The following directives can appear in a Director's Pool resource, and they +are used to define a Migration job. + +\begin{description} +\item [Migration Time = \lt{}time-specification\gt{}] + If a PoolTime migration is done, the time specified here in seconds (time + modifiers are permitted -- e.g. hours, ...) will be used. If the + previous Backup Job or Jobs selected have been in the Pool longer than + the specified PoolTime, then they will be migrated. + +\item [Migration High Bytes = \lt{}byte-specification\gt{}] + This directive specifies the number of bytes in the Pool which will + trigger a migration if a {\bf PoolOccupancy} migration selection + type has been specified. The fact that the Pool + usage goes above this level does not automatically trigger a migration + job. However, if a migration job runs and has the PoolOccupancy selection + type set, the Migration High Bytes will be applied. Bacula does not + currently restrict a pool to have only a single Media Type, so you + must keep in mind that if you mix Media Types in a Pool, the results + may not be what you want, as the Pool count of all bytes will be + for all Media Types combined. + +\item [Migration Low Bytes = \lt{}byte-specification\gt{}] + This directive specifies the number of bytes in the Pool which will + stop a migration if a {\bf PoolOccupancy} migration selection + type has been specified and triggered by more than Migration High + Bytes being in the pool. In other words, once a migration job + is started with {\bf PoolOccupancy} migration selection and it + determines that there are more than Migration High Bytes, the + migration job will continue to run jobs until the number of + bytes in the Pool drop to or below Migration Low Bytes. + +\item [Next Pool = \lt{}pool-specification\gt{}] + The Next Pool directive specifies the pool to which Jobs will be + migrated. This directive is required to define the Pool into which + the data will be migrated. Without this directive, the migration job + will terminate in error. + +\item [Storage = \lt{}storage-specification\gt{}] + The Storage directive specifies what Storage resource will be used + for all Jobs that use this Pool. It takes precedence over any other + Storage specifications that may have been given such as in the + Schedule Run directive, or in the Job resource. We highly recommend + that you define the Storage resource to be used in the Pool rather + than elsewhere (job, schedule run, ...). +\end{description} + +\section{Important Migration Considerations} +\index[general]{Important Migration Considerations} +\begin{itemize} +\item Each Pool into which you migrate Jobs or Volumes {\bf must} + contain Volumes of only one Media Type. + +\item Migration takes place on a JobId by JobId basis. That is + each JobId is migrated in its entirety and independently + of other JobIds. Once the Job is migrated, it will be + on the new medium in the new Pool, but for the most part, + aside from having a new JobId, it will appear with all the + same characteristics of the original job (start, end time, ...). + The column RealEndTime in the catalog Job table will contain the + time and date that the Migration terminated, and by comparing + it with the EndTime column you can tell whether or not the + job was migrated. The original job is purged of its File + records, and its Type field is changed from "B" to "M" to + indicate that the job was migrated. + +\item Jobs on Volumes will be Migration only if the Volume is + marked, Full, Used, or Error. Volumes that are still + marked Append will not be considered for migration. This + prevents Bacula from attempting to read the Volume at + the same time it is writing it. It also reduces other deadlock + situations, as well as avoids the problem that you migrate a + Volume and later find new files appended to that Volume. + +\item As noted above, for the Migration High Bytes, the calculation + of the bytes to migrate is somewhat approximate. + +\item If you keep Volumes of different Media Types in the same Pool, + it is not clear how well migration will work. We recommend only + one Media Type per pool. + +\item It is possible to get into a resource deadlock where Bacula does + not find enough drives to simultaneously read and write all the + Volumes needed to do Migrations. For the moment, you must take + care as all the resource deadlock algorithms are not yet implemented. + +\item Migration is done only when you run a Migration job. If you set a + Migration High Bytes and that number of bytes is exceeded in the Pool + no migration job will automatically start. You must schedule the + migration jobs, and they must run for any migration to take place. + +\item If you migrate a number of Volumes, a very large number of Migration + jobs may start. + +\item Figuring out what jobs will actually be migrated can be a bit complicated + due to the flexibility provided by the regex patterns and the number of + different options. Turning on a debug level of 100 or more will provide + a limited amount of debug information about the migration selection + process. + +\item Bacula currently does only minimal Storage conflict resolution, so you + must take care to ensure that you don't try to read and write to the + same device or Bacula may block waiting to reserve a drive that it + will never find. In general, ensure that all your migration + pools contain only one Media Type, and that you always + migrate to pools with different Media Types. + +\item The {\bf Next Pool = ...} directive must be defined in the Pool + referenced in the Migration Job to define the Pool into which the + data will be migrated. + +\item Pay particular attention to the fact that data is migrated on a Job + by Job basis, and for any particular Volume, only one Job can read + that Volume at a time (no simultaneous read), so migration jobs that + all reference the same Volume will run sequentially. This can be a + potential bottle neck and does not scale very well to large numbers + of jobs. + +\item Only migration of Selection Types of Job and Volume have + been carefully tested. All the other migration methods (time, + occupancy, smallest, oldest, ...) need additional testing. + +\item Migration is only implemented for a single Storage daemon. You + cannot read on one Storage daemon and write on another. +\end{itemize} + + +\section{Example Migration Jobs} +\index[general]{Example Migration Jobs} + +When you specify a Migration Job, you must specify all the standard +directives as for a Job. However, certain such as the Level, Client, and +FileSet, though they must be defined, are ignored by the Migration job +because the values from the original job used instead. + +As an example, suppose you have the following Job that +you run every night. To note: there is no Storage directive in the +Job resource; there is a Storage directive in each of the Pool +resources; the Pool to be migrated (File) contains a Next Pool +directive that defines the output Pool (where the data is written +by the migration job). + +\footnotesize +\begin{verbatim} +# Define the backup Job +Job { + Name = "NightlySave" + Type = Backup + Level = Incremental # default + Client=rufus-fd + FileSet="Full Set" + Schedule = "WeeklyCycle" + Messages = Standard + Pool = Default +} + +# Default pool definition +Pool { + Name = Default + Pool Type = Backup + AutoPrune = yes + Recycle = yes + Next Pool = Tape + Storage = File + LabelFormat = "File" +} + +# Tape pool definition +Pool { + Name = Tape + Pool Type = Backup + AutoPrune = yes + Recycle = yes + Storage = DLTDrive +} + +# Definition of File storage device +Storage { + Name = File + Address = rufus + Password = "ccV3lVTsQRsdIUGyab0N4sMDavui2hOBkmpBU0aQKOr9" + Device = "File" # same as Device in Storage daemon + Media Type = File # same as MediaType in Storage daemon +} + +# Definition of DLT tape storage device +Storage { + Name = DLTDrive + Address = rufus + Password = "ccV3lVTsQRsdIUGyab0N4sMDavui2hOBkmpBU0aQKOr9" + Device = "HP DLT 80" # same as Device in Storage daemon + Media Type = DLT8000 # same as MediaType in Storage daemon +} + +\end{verbatim} +\normalsize + +Where we have included only the essential information -- i.e. the +Director, FileSet, Catalog, Client, Schedule, and Messages resources are +omitted. + +As you can see, by running the NightlySave Job, the data will be backed up +to File storage using the Default pool to specify the Storage as File. + +Now, if we add the following Job resource to this conf file. + +\footnotesize +\begin{verbatim} +Job { + Name = "migrate-volume" + Type = Migrate + Level = Full + Client = rufus-fd + FileSet = "Full Set" + Messages = Standard + Pool = Default + Maximum Concurrent Jobs = 4 + Selection Type = Volume + Selection Pattern = "File" +} +\end{verbatim} +\normalsize + +and then run the job named {\bf migrate-volume}, all volumes in the Pool +named Default (as specified in the migrate-volume Job that match the +regular expression pattern {\bf File} will be migrated to tape storage +DLTDrive because the {\bf Next Pool} in the Default Pool specifies that +Migrations should go to the pool named {\bf Tape}, which uses +Storage {\bf DLTDrive}. + +If instead, we use a Job resource as follows: + +\footnotesize +\begin{verbatim} +Job { + Name = "migrate" + Type = Migrate + Level = Full + Client = rufus-fd + FileSet="Full Set" + Messages = Standard + Pool = Default + Maximum Concurrent Jobs = 4 + Selection Type = Job + Selection Pattern = ".*Save" +} +\end{verbatim} +\normalsize + +All jobs ending with the name Save will be migrated from the File Default to +the Tape Pool, or from File storage to Tape storage. diff --git a/docs/manual-de/supported.tex b/docs/manual-de/supported.tex deleted file mode 100644 index 5550283f..00000000 --- a/docs/manual-de/supported.tex +++ /dev/null @@ -1,216 +0,0 @@ -%% -%% - -\section*{Supported Systems and Hardware} -\label{_ChapterStart} -\index[general]{Supported Systems and Hardware } -\index[general]{Hardware!Supported Systems and } -\addcontentsline{toc}{section}{Supported Systems and Hardware} - -\label{SysReqs} - -\subsection*{System Requirements} -\index[general]{System Requirements } -\index[general]{Requirements!System } -\addcontentsline{toc}{subsection}{System Requirements} - -\begin{itemize} -\item {\bf Bacula} has been compiled and run on Linux RedHat, FreeBSD, and -Solaris systems. -\item It requires GNU C++ version 2.95 or higher to compile. You can try with -other compilers and older versions, but you are on your own. We have -successfully compiled and used Bacula on RH8.0/RH9/RHEL 3.0/FC3 with GCC 3.4. -Note, in general GNU C++ is a separate package (e.g. RPM) from GNU C, so you -need them both loaded. On RedHat systems, the C++ compiler is part of the -{\bf gcc-c++} rpm package. -\item There are certain third party packages that Bacula needs. Except for -MySQL and PostgreSQL, they can all be found in the {\bf depkgs} and {\bf -depkgs1} releases. -\item If you want to build the Win32 binaries, you will need a Microsoft -Visual C++ compiler (or Visual Studio). Although all components build -(console has some warnings), only the File daemon has been tested. -\item {\bf Bacula} requires a good implementation of pthreads to work. This -is not the case on some of the BSD systems. -\item The source code has been written with portability in mind and is mostly -POSIX compatible. Thus porting to any POSIX compatible operating system -should be relatively easy. -\item The GNOME Console program is developed and tested under GNOME 2.x. It -also runs under GNOME 1.4 but this version is deprecated and thus no longer -maintained. -\item The wxWidgets Console program is developed and tested with the latest -stable ANSI (not Unicode) version of -\elink{wxWidgets}{http://www.wxwidgets.org/} (2.6.0). It works fine with the -Windows and GTK+-2.x version of wxWidgets, and should also works on other -platforms supported by wxWidgets. -\item The Tray Monitor program is developed for GTK+-2.x. It needs Gnome less -or equal to 2.2, KDE greater or equal to 3.1 or any window manager supporting -the -\elink{ FreeDesktop system tray -standard}{http://www.freedesktop.org/Standards/systemtray-spec}. -\item If you want to enable command line editing and history, you will need -to have /usr/include/termcap.h and either the termcap or the ncurses library -loaded (libtermcap-devel or ncurses-devel). -\item If you want to use DVD as backup medium, you will need to download and -install the -\elink{dvd+rw-tools}{http://fy.chalmers.se/~appro/linux/DVD+RW/}. -\end{itemize} - -\subsection*{Supported Operating Systems} -\label{SupportedOSes} -\index[general]{Systems!Supported Operating } -\index[general]{Supported Operating Systems } -\addcontentsline{toc}{subsection}{Supported Operating Systems} - -\begin{itemize} -\item Linux systems (built and tested on RedHat Fedora Core 3). -\item If you have a recent Red Hat Linux system running the 2.4.x kernel and -you have the directory {\bf /lib/tls} installed on your system (normally by -default), bacula will {\bf NOT} run. This is the new pthreads library and it -is defective. You must remove this directory prior to running Bacula, or you -can simply change the name to {\bf /lib/tls-broken}) then you must reboot -your machine (one of the few times Linux must be rebooted). If you are not -able to remove/rename /lib/tls, an alternative is to set the environment -variable ``LD\_ASSUME\_KERNEL=2.4.19'' prior to executing Bacula. For this -option, you do not need to reboot, and all programs other than Bacula will -continue to use /lib/tls. - -The feedback that we have for 2.6 kernels is that the same problem may -exist. However, we have not been able to reproduce the above mentioned -problem (bizarre hangs) on 2.6 kernels. If you do experience problems, we -recommend using the environment variable override -(LD\_ASSUME\_KERNEL=2.4.19) rather than removing /lib/tls, because TLS -is designed to work with 2.6 kernels. - -\item Most flavors of Linux (Gentoo, SuSE, Mandrake, Debian, ...). -\item Solaris various versions. -\item FreeBSD (tape driver supported in 1.30 -- please see some {\bf -important} considerations in the -\ilink{ Tape Modes on FreeBSD}{tapetesting.tex#FreeBSDTapes} section of the -Tape Testing chapter of this manual.) -\item Windows (Win98/Me, WinNT/2K/XP) Client (File daemon) binaries. -\item MacOS X/Darwin (see -\elink{ http://fink.sourceforge.net/}{http://fink.sourceforge.net/} for -obtaining the packages) -\item OpenBSD Client (File daemon). -\item Irix Client (File daemon). -\item Tru64 -\item Bacula is said to work on other systems (AIX, BSDI, HPUX, ...) but we -do not have first hand knowledge of these systems. -\item See the Porting chapter of the Bacula Developer's Guide for information -on porting to other systems. -\end{itemize} - -\subsection*{Supported Tape Drives} -\label{SupportedDrives} -\index[general]{Drives!Supported Tape } -\index[general]{Supported Tape Drives } -\addcontentsline{toc}{subsection}{Supported Tape Drives} - -Even if your drive is on the list below, please check the -\ilink{Tape Testing Chapter}{tapetesting.tex#btape} of this manual for -procedures that you can use to verify if your tape drive will work with -Bacula. If your drive is in fixed block mode, it may appear to work with -Bacula until you attempt to do a restore and Bacula wants to position the -tape. You can be sure only by following the procedures suggested above and -testing. - -It is very difficult to supply a list of supported tape drives, or drives that -are known to work with Bacula because of limited feedback (so if you use -Bacula on a different drive, please let us know). Based on user feedback, the -following drives are known to work with Bacula. A dash in a column means -unknown: - -\addcontentsline{lot}{table}{Supported Tape Drives} -\begin{longtable}{|p{1.2in}|l|l|p{1.3in}|l|} - \hline -\multicolumn{1}{|c| }{\bf OS } & \multicolumn{1}{c| }{\bf Man. } & -\multicolumn{1}{c| }{\bf Media } & \multicolumn{1}{c| }{\bf Model } & -\multicolumn{1}{c| }{\bf Capacity } \\ - \hline -{- } & {ADIC } & {DLT } & {Adic Scalar 100 DLT } & {100GB } \\ - \hline -{- } & {ADIC } & {DLT } & {Adic Fastor 22 DLT } & {- } \\ - \hline -{- } & {- } & {DDS } & {Compaq DDS 2,3,4 } & {- } \\ - \hline -{- } & {Exabyte } & {- } & {Exabyte drives less than 10 years old } & {- } -\\ - \hline -{- } & {Exabyte } & {- } & {Exabyte VXA drives } & {- } \\ - \hline -{- } & {HP } & {Travan 4 } & {Colorado T4000S } & {- } \\ - \hline -{- } & {HP } & {DLT } & {HP DLT drives } & {- } \\ - \hline -{- } & {HP } & {LTO } & {HP LTO Ultrium drives } & {- } \\ - \hline -{FreeBSD 4.10 RELEASE } & {HP } & {DAT } & {HP StorageWorks DAT72i } & {- } -\\ - \hline -{- } & {Overland } & {LTO } & {LoaderXpress LTO } & {- } \\ - \hline -{- } & {Overland } & {- } & {Neo2000 } & {- } \\ - \hline -{- } & {OnStream } & {- } & {OnStream drives (see below) } & {- } \\ - \hline -{- } & {Quantum } & {DLT } & {DLT-8000 } & {40/80GB } \\ - \hline -{Linux } & {Seagate } & {DDS-4 } & {Scorpio 40 } & {20/40GB } \\ - \hline -{FreeBSD 4.9 STABLE } & {Seagate } & {DDS-4 } & {STA2401LW } & {20/40GB } \\ - \hline -{FreeBSD 5.2.1 pthreads patched RELEASE } & {Seagate } & {AIT-1 } & {STA1701W -} & {35/70GB } \\ - \hline -{Linux } & {Sony } & {DDS-2,3,4 } & {- } & {4-40GB } \\ - \hline -{Linux } & {Tandberg } & {- } & {Tandbert MLR3 } & {- } \\ - \hline -{FreeBSD } & {Tandberg } & {- } & {Tandberg SLR6 } & {- } \\ - \hline -{Solaris } & {Tandberg } & {- } & {Tandberg SLR75 } & {- } -\\ \hline - -\end{longtable} - -There is a list of -\ilink{supported autochangers}{autochangers.tex#Models} models in the -\ilink{autochangers chapter}{autochangers.tex#_ChapterStart} of this document, -where you will find other tape drives that work with Bacula. - -\subsection*{Unsupported Tape Drives} -\label{UnSupportedDrives} -\index[general]{Unsupported Tape Drives } -\index[general]{Drives!Unsupported Tape } -\addcontentsline{toc}{subsection}{Unsupported Tape Drives} - -Previously OnStream IDE-SCSI tape drives did not work with Bacula. As of -Bacula version 1.33 and the osst kernel driver version 0.9.14 or later, they -now work. Please see the testing chapter as you must set a fixed block size. - -QIC tapes are known to have a number of particularities (fixed block size, and -one EOF rather than two to terminate the tape). As a consequence, you will -need to take a lot of care in configuring them to make them work correctly -with Bacula. - -\subsection*{FreeBSD Users Be Aware!!!} -\index[general]{FreeBSD Users Be Aware } -\index[general]{Aware!FreeBSD Users Be } -\addcontentsline{toc}{subsection}{FreeBSD Users Be Aware!!!} - -Unless you have patched the pthreads library on most FreeBSD systems, you will -lose data when Bacula spans tapes. This is because the unpatched pthreads -library fails to return a warning status to Bacula that the end of the tape is -near. Please see the -\ilink{Tape Testing Chapter}{tapetesting.tex#FreeBSDTapes} of this manual for -{\bf important} information on how to configure your tape drive for -compatibility with Bacula. - -\subsection*{Supported Autochangers} -\index[general]{Autochangers!Supported } -\index[general]{Supported Autochangers } -\addcontentsline{toc}{subsection}{Supported Autochangers} - -For information on supported autochangers, please see the -\ilink{Autochangers Known to Work with Bacula}{autochangers.tex#Models} -section of the Autochangers chapter of this manual. -- 2.39.5