Scenario 1. Dedup Legacy and Dedup2 Running on Different Hosts

Goal of the scenario: Migrating data from your current dedup1 engine to a new Dedup2 engine that use different Storage Daemon hosts.

Note

In this scenario, there are two Storage Daemons running.

It is required to have both dedup engines running at the same time to migrate the data.

The new dedup2 engine will be implemented in a different Storage Daemon host, so only its configuration, using the new DedupEngine resource, is needed. In the bacula-sd.conf file of the new Storage Daemon host, add a DedupEngine resource configured to use Driver = Dedup2:

Dedupengine {
  Name = Dedupengine_name_with_dedup2
  Dedup Directory = /mnt/bacula/dedup2/containers
  Dedup Index Directory = /mnt/SSD/dedup2/index
  Driver = Dedup2
  Maximum Container Size = 2TB
}

And the dedup devices should point to the dedup2 engine, for example:

Autochanger {
  Name = FileDedup2-Chgr1
  Device = FileDedup2-Dev0, FileDedup2-Dev1
  Changer Command = /dev/null
  Changer Device = /dev/null
}

Device {
  Name = FileDedup2-dev0
  Drive Index = 0
  ...
  Device Type = Dedup
  DedupEngine = Dedupengine_name_with_dedup2
}

Device {
  Name = FileDedup2-dev1
  Drive Index = 1
  ...
  Device Type = Dedup
  DedupEngine = Dedupengine_name_with_dedup2
}

After you have the new Dedup2 engine correctly configured and running, you may use Migration Jobs to migrate jobs from the dedup1 storage to the new dedup2 storage. Once all jobs have been migrated, the current dedup1 engine can be decommissioned.

More details about Migration Jobs: Migration and Copy.