Bacula Copy and Migration Jobs are great for moving data from old storage hardware backup to new, running disk-to-disk-to-tapes (disk to tape to tape) backups, or deploying a second off-site storage.
Copying and migration occur at the Job granularity level, so the size of the source or target tape or media is not important. Jobs to be copied from a Source Pool (and Storage) Bacula must be selected from some defined criteria and stored in a Destination Pool (and Storage).
The difference between copy and migration jobs is that Bacula discards the saved Jobs from the source Pool in the case of migration.
When the original backup of a copied Job is recycled or deleted for some reason, Bacula will automatically select the copy to do a restore of a client at that particular moment, if requested.
Copy and migration jobs do not require connection to Bacula Clients. This usually means that it can be run during the day, without risk of impact on other services.
The Jobs selection scope for the copy can be:
- one or more configured Backup Jobs;
- one or more Volumes, by name;
- A customer’s jobs, by name;
- Jobs that match a regular expression;
- if a work exists on a given volume;
- volumes with the sum of occupancy in a pool lower or higher than a given value;
- size of the volume.
In a summary, to run a copy or migration job, you must define a special Job resource in bacula-dir.conf with the Type directive equal to Copy or Migrate; the specification of a source Pool; and at least, but not least, one of the SelectionType (and often SelectionPattern) that defines the selection criteria capable of finding Jobs to be copied.
In Pool (still in bacula-dir.conf), you must specify the Storage directive in the source Pool (the same one on which your volumes are already written, which will also be the source of the copy), as well as the NextPool directive. you must enter the name of another copy Pool of the copy. Finally, in the Destination Pool resource, you must also specify a Storage directive for a different storage device, which will be the destination device.
Now we will see more information on each of these required guidelines. Below is also a complete setup example:
a) Job resource
Pool =
Determines where the job selection algorithm for copying will be applied. It’s the Source Pool.
Type = Migrate
The selected Jobs are moved from the Source Pool to the Destination Pool (the original jobs are discarded). Or…
Type = Copy
Jobs are copied to the target Pool. They will receive retention times and recycle the behavior of the new Pool, as well.
Selection Type =
Determines how JobIds for copying or migration will be selected. These are the possible values:
- SmallestVolume – selects all jobs from the lowest source pool volume.
- OldestVolume – selects all Jobs from the oldest volume.
- Client – if used, also requires another Policy (SelectionPattern) that should be a Regular Expression that matches the clients’ names for copying / migrating only their Jobs.
- Volume – If used, this policy also requires SelectionPattern, in this case a Regular Expression that will correspond to the volume names whose Jobs will be copied.
- Job – In this case the SelectionPattern must match the names of Jobs.
- SQLQuery – A SQL query to find JobIds directly from the Bacula database to be copied.
- PoolOccupancy – Bacula will add the size of all volumes in the source Pool. If it is smaller than the ancillary directives (required in the Pool resource) MigrationLowBytes or greater than MigrationHighBytes, it migrates the jobs until the Pool occupancy returns to the defined limits.
- PoolUncopiedJobs – This is quite popular for off-site backups. It will copy all jobs that do not have a copy to the destination Pool.
Selection Pattern =
This policy is not required for SelectionType, OldestVolume, or SmallestVolume, but indispensable for Client, Volume, and Job. The SelectionPattern value must be a RegExp that will find its policy names. Example:
Selection Type = SQLQuery Selection Pattern = "select '<Jobid>';" # Selects a single Job to copy
b) Origin Pool Resource
Migration Time =
A period of time that, when it is finished, backup Jobs can be migrated if a Migration Job runs.
Migration High Bytes =
Maximum Pool occupancy size.
Migration Low Bytes =
Minimum Pool Occupancy Size.
Next Pool =
Specifies what the copy destination pool is (required). However, you can also override this NextPool specification in the Schedule resource, allowing you to run Copy or Migration Jobs for different destination Pools according to time.
Storage =
In this case, the name of the Source Storage must be specified. The same thing is probably already being used to record the backups of this Pool. Either way, this is the best place to associate Pool with your Storages, regardless of whether you’re setting up a copy job.
c) Destination Pool Resource
Storage =
The name of the destination Storage must be specified, where the Copy or Migration Jobs will be stored.
A Copy Job Example
a) Pool Resources (bacula-dir.conf)
# Origin Pool Pool { Name = Monthly-Disk Pool Type = backup Storage = File1 # origin storage Next Pool = Copy # destination pool ... } # Destination Pool Pool { Name = Copy Pool Type = backup Storage = File2 # destination storage ... }
b) Job Resource (bacula-dir.conf)
Job {
Name = "CopyJobs"
JobDefs = DefaultJob
Type = Copy # ou Migrate
Pool = Monthly-Disk # origin Pool
Selection Type = PoolUncopiedJobs
Schedule = CopySchedule # recommended
}
Apply as a configuration and run (run command) the Job created as test. In this example, a first time can take a long time, since you just need to select all jobs copied from the Source Pool (SelectionPattern = PoolUncopiedJobs). So plan your first job so the first workload can be great. You should also create a different Schedule for this copy jobs, as in the example.
Disponível em: 
Português (Portuguese (Brazil))
English
Español (Spanish)
