Jan 262018

When NetWorker and Data Domain are working together, some operations can be done as a virtual synthetic full. It sounds like a tautology – virtual synthetic. In this basics post, I want to explain the difference between a synthetic full and a virtual synthetic full, so you can understand why this is actually a very important function in a modernised data protection environment.

The difference between the two operations is actually quite simple, and best explained through comparative diagrams. Let’s look at the process of creating a synthetic full, from the perspective of working with AFTDs (still less challenging than synthetic fulls from tape), and working with Data Domain Boost devices.

Synthethic Full vs Virtual Synthetic Full

On the left, we have the process of creating a synthetic full when backups are stored on a regular AFTD device. I’ve simplified the operation, since it does happen in memory rather than requiring staging, etc. Effectively, the NetWorker server (or storage ndoe) will read the various backups that need to be reconstituted into a new, synthetic full, up into memory, and as chunks of the new backup are constructed, they’re written back down onto the AFTD device as a new saveset.

When a Data Domain is involved though, the server gets a little lazier – instead, it just simply has the Data Domain virtually construct a synthetic full – remember, at the back end on the Data Domain, it’s all deduplicated segments of data along with metadata maps that define what a complete ‘file’ is that was sent to the system. (In the case of NetWorker, by ‘file’ I’m referring to a saveset.) So the Data Domain assembles details of a new full without any data being sent over the network.

The difference is simple, but profound. In a traditional synthetic full, the NetWorker server (or storage node) is doing all the grunt work. It’s reading all the data up into itself, combining it appropriately and writing it back down. If you’ve got a 1TB full backup and 6 incremental backups, it’s having do read all that data – 1TB or more, up from disk storage, process it, and write another ~1TB backup back down to disk. With a virtual synthetic full, the Data Domain is doing all the heavy lifting. It’s being told what it needs to do, but it’s doing the reading and processing, and doing it more efficiently than a traditional data read.

So, there’s actually a big difference between synthetic full and virtual synthetic full, and virtual synthetic full is anything but a tautology.

Virtual synthetic fulls: A match made in heaven

 NetWorker  Comments Off on Virtual synthetic fulls: A match made in heaven
Oct 302013

One of the great new features in NetWorker 8.1 is virtual synthetic fulls.

You may think the term ‘virtual synthetic’ sounds a bit meta, but it’s quite accurate when it refers to synthetic fulls being virtually constructed on Data Domain devices.

You see, while synthetic fulls were introduced in NetWorker 8.0, they had a catch when running on Data Domain Boost devices – the data would still be rehydrated. That is, NetWorker would read through the full and all incremental backups referenced and rehydrate the data to construct a new full backup, saving that full on the Data Domain (with inline deduplication obviously happening again).

There’s nothing incorrect about that process – it is, after all, exactly what happens on standard AFTD devices. But it’s not the most efficient way of going about it.

That’s where NetWorker 8.1 and virtual synthetic fulls come into play. In this scenario, NetWorker instructs the Data Domain to create a new full backup via Boost. For the Data Domain, this consists of giving NetWorker back the appropriate reference data for the saveset after (mostly) jiggling pointers and updating its own back-end file data.

The net result is speed. Virtual synthetic fulls are fast on Data Domain because there’s very little data being rehydrated – deduplicated data is just being adjusted. You can see how fast this is because NetWorker reports the operation as if it were happening as realtime data:

virtual synthetic fullThat’s 1860236 KB/s being reported … 1816 MB/s throughput, and that’s just what I managed to capture – it was a smaller saveset, and it was pumping along. But the client itself in question was connected over 802.11n. There’s no way it could be running at that speed over the ether – the speed was coming from the operation being performed on the Data Domain itself – and that Data Domain had a bunch of other activities happening at the same time.

Synthetic fulls are useful under NetWorker 8.0, but in 8.1 and combined with Data Domain, they can be a complete game changer to your backup windows.


%d bloggers like this: