Updates

[bacula/docs] / docs / manuals / en / concepts / migration.tex

diff --git a/docs/manuals/en/concepts/migration.tex b/docs/manuals/en/concepts/migration.tex
index ee2e7a50e78c660a4e470f674a94019ecf1fd885..25d139a25c7122811d4ccc7ca78efb2040611d44 100644 (file)
--- a/docs/manuals/en/concepts/migration.tex
+++ b/docs/manuals/en/concepts/migration.tex
@@ -46,9 +46,9 @@ 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.
+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
+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
@@ -92,28 +92,38 @@ 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.
+   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}, and although a Pool directive must still be
+   specified, no Pool is used, unless you specifically include it in the
+   SQL query.  Note, in any case, the Pool resource defined by the Pool 
+   directove 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
+   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.
+   from the specified Pool to another Pool.  Note, any original JobId that
+   is migrated will be marked as having been migrated, and the original
+   JobId can nolonger be used for restores; all restores will be done from
+   the new migrated Job.
+
 
 \item [Type = Copy]
    {\bf Copy} is a new type that defines the job that is run as being a
    Copy Job.  A Copy 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.  Copy jobs simply check to see if there is anything to
+   an Admin job.  Copy jobs simply check to see if there is anything to
    Copy then possibly start and control new Backup jobs to copy the data
-   from the specified Pool to another Pool.
+   from the specified Pool to another Pool.  Note that when a copy is
+   made, the original JobIds are left unchanged. The new copies can not
+   be used for restoration unless you specifically choose them by JobId.
+   If you subsequently delete a JobId that has a copy, the copy will be
+   automatically upgraded to a Backup rather than a Copy, and it will
+   subsequently be used for restoration.
  
 \item [Selection Type = \lt{}Selection-type-keyword\gt{}]  
   The \lt{}Selection-type-keyword\gt{} determines how the migration job