Scenario 5. Setup Dedup2 on the Same Storage Daemon Host and Using the Same SDPort 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 the same Storage Daemon host. The new Dedup2 engine uses the same Storage Daemon port, SDPort 9103.

Note

In this scenario, there is only one Storage Daemon running.

This scenario is similar to Scenario 2.

If you decide to have both dedup engines in the same host and using the same Storage Daemon port, it is required to modify the current dedup1 engine configuration to use the new DedupEngine resource.

Then, you must modify the current dedup1 configuration to use the new configuration format as documented in the New Dedupengine Resource section in the Global Endpoint Deduplication 2 article.

  1. Stop the Storage Daemon

  2. Modify the current dedup1 engine settings by creating a DedupEngine resource with Driver=Legacy, and the same index and containers directories of your current dedup engine:

Dedupengine {
  Name = Dedupengine_legacy
  Dedup Directory = /mnt/bacula/dedup1/containers
  Dedup Index Directory = /mnt/SSD/dedup1/index
  Driver = Legacy
  Maximum Container Size = 2TB
}

  1. Add the Dedupengine = Dedupengine_legacy directive to all the dedup1 devices:

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

Device {
  Name = FileDedup1-dev0
  Drive Index = 0
  ...
  Device Type = Dedup
  DedupEngine = Dedupengine_legacy <--- @aga, should we highlight this?
}

Device {
  Name = FileDedup1-dev1
  Drive Index = 1
  ...
  Device Type = Dedup
  DedupEngine = Dedupengine_legacy <--- @aga, should we highlight this?
}

  1. Remove or comment the index and containers directories from the Storage resource configuration:

# From bacula-sd.conf
Storage {
 Name = Dedup1-sd
 Working Directory = /opt/bacula/working
 Pid Directory = /opt/bacula/working
 Plugin Directory = /opt/bacula/plugins
 # Dedup Directory = /mnt/bacula/dedup1/containers <--- you may remove this line
 # Dedup Index Directory = /mnt/SSD/dedup1/index <--- you may remove this line
 Maximum Container Size = 2TB
}

  1. Add the new dedup2 engine resource and autochanger/devices to the same bacula-sd.conf file:

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
}

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
}

  1. Start the Storage Daemon.

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.