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 Copy process is essentially identical to the Migration feature
-with the exception that the Job that is copied is left unchanged. This
-essentially creates two identical copies of the same backup. The Copy Job runs
-without using the File daemon by copying the data from the old backup Volume to
-a different Volume in a different Pool.
+The Copy process is essentially identical to the Migration feature with the
+exception that the Job that is copied is left unchanged. This essentially
+creates two identical copies of the same backup. However, the copy is treated
+as a copy rather than a backup job, and hence is not directly available for
+restore. If bacula founds a copy when a job record is purged (deleted) from the
+catalog, it will promote the copy as \textsl{real} backup and will make it
+available for automatic restore.
+
+The Copy and the Migration jobs run without using the File daemon by copying
+the data from the old backup Volume to a different Volume in a different Pool.
The section process for which Job or Jobs are migrated
can be based on quite a number of different criteria such as:
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
Jobs that start. Because each job must read the same Volume, they will
run consecutively (not simultaneously).
-\section{Migration Job Resource Directives}
+\section{Migration and Copy 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.
+ 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
+ Copy then possibly start and control new Backup jobs to copy the data
+ 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
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.
+
+ \item [PoolUncopiedJobs] This selection which copies all jobs from a pool
+ to an other pool which were not copied before is available only for copy Jobs.
+
\end{description}
\item [Selection Pattern = \lt{}Quoted-string\gt{}]
projects / bacula / docs / blobdiff