Scenario 4. Setup Dedup2 on a New Host and Redirect All Backup Jobs There

Goal of the scenario: Keeping the dedup1 engine for restore purposes, and setting up a new dedup2 engine for new backups in a different Storage Daemon host.

Note

In this scenario, there are two Storage Daemons running.

In this scenario, you will need to setup the new dedup2 engine in the new Storage Daemon host as described in Scenario 1.

The new Dedup2 engine is to 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 this 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
}

Then, you should redirect all your backup jobs (this can be done gradually if you have a huge number of Jobs and/or Pools that need to be modified) to the new Dedup2 engine storage.

The dedup1 engine can be decommissioned when the data retention has expired, meaning the retention period for all the jobs previously stored in the dedup1 engine expired, and you will not need to restore any data stored in this dedup1 engine.

If you want to use this scenario to keep the dedup1 engine for restore purposes only, consider to have the dedup1 engine Storage Daemon shut down, and you may start it only when restore jobs are needed.