Last week I’ve been implementing two new Data Domain systems for a new customer who’d like to use these systems as backup targets for their existing Veeam 8 environment. Backup would be replicated to the secondary system to guarantee recoverability even if the first system or data center experiences a catastrophic failure. In this case replication will be handled by the Data Domain system itself. You’d like your backup software to be aware of the replicas on the secondary location. This in turn means Veeam should be able to read from the replica, which turned out to be a bit of a configuration challenge. Bring out the CLI!
DDboost “Chicken-Egg” problem
Veeam will access the Data Domain using DDBoost: DDBoost brings a multitude of advantages to the table over a regular NFS export or SMB share, namely in performance and backup server resource utilization. However it turned out to be somewhat of a challenge to enable DDBoost access on the replica. For the record, we’re running DD-OS 5.5.2.2.
After the basic set-up of the system we created a DDBoost user and a DDBoost Storage Unit on the primary Data Domain. If you create a DDBoost Storage Unit, the Data Domain will create a new MTree in the background, which is basically a path on the Data Domain. So far so good: we were able to connect Veeam to this DDBoost Storage Unit and start backing up data.
Next up: replication. You can replicate MTrees as a whole on a Data Domain. Simply select the source MTree and select the destination Data Domain and MTree. There’s a warning here: the destination MTree should either not exist (and DD-OS will create it for you) or it should be empty. Our destination MTree didn’t exist so the Data Domain created it without fault. Replication started automatically and we were happy.
Last step: enabling DDBoost on this MTree (i.e. mark the MTree as a DDBoost Storage Unit). There’s no GUI button on the MTree itself to enable DDBoost. You also can’t add the MTree to the Storage Units in the DDBoost configuration screen. Trying to trick the DD-OS by creating a new Storage Unit with the same name as the replica MTree will yield a “MTree already exists” error. Rightly so, but damn!
Okay.. so we tried it the other way around. We removed the replication and the replica MTree, so we’re back at the start with just an active MTree on the primary system. We created a new DDBoost Storage Unit on the secondary system. We did NOT use it or connect in to Veeam just yet; instead we now tried setting up the replication. Create new replication pair, select source and destination system and MTree, click next: ERROR – MTree already exists. Wait, weren’t we allowed to replicate to an empty MTree? Apparently enabling DDBoost on an MTree removes the “empty” flag…
The solution
It turns out you will need the CLI to enable DDBoost on a replica MTree. The correct approach is:
- Create the source MTree on the primary system.
- Configure the replication pair, which will create the destination MTree on the secondary system.
- Grab your CLI and run the following command on the secondary Data Domain:
ddboost storage-unit modify <MTree-Name> user <ddboost-username>
The MTree is the name after /data/col1/, so in the above screenshot there’s two MTrees: backup (which is default and cannot be removed) and veeam.
That’s it…
Viewing the MTree properties you can now see that the status is RO/RD (Read Only/Replication Destination). You can also see that it is a DD Boost Storage Unit under the Protocols section. Finally you can see the replication status in the bottom of the screen.
My thoughts…
It would be nice to have a button in the MTree overview to enable DDBoost access to a replica MTree without having to resort to CLI access. That said, if you know the command it’ll take you next to no time to enable DDboost.
One more thing to note: there’s a file system setting on the DD to present read-only replicas as writable to your DDBoost application. Depending on your backup software in use, this might be necessary before you can access the DDBoost storage unit. It does not affect the replication pair and you will still not be able to write to the replica without failing it over.
