synthetic back up on hardware dedup box why ?

[stormlight]

Can someone tell me any benefits in using synthetic full backups on a hardware de-dup box like data domain or exagrid.

The only benefit I see is that when choosing synthetic full when its time to do another full backup you are saving bandwidth and possibly proc and io on the target dedup box by not having to transfer over another full vbk file over the wire to your target storage. (as well as read io on your san that the vm is sitting on)

i don’t see a benefit of saving space by keeping 1 vbk and only updating the vbk with the vib's since datadomain or exagrid will already see that most of the data in all future full vbk backups that you are putting on storage is mostly a duplicate of the last one that is on there and dedup it anyway and not waste space..

And as far as replication it’s still going to only replicate the changes that are not duplicate to the wan side and not the entire vbk since that datadomain or exagrid is going to do its job by de-dupping

Anything im overlooking?

[Gostev]

Yes, you are overlooking one of the most important factors, and that is how much time your production VMs will run off snapshot during backup. Obviously, with real fulls this time will be 10x longer. This time, however, directly affects snapshot size (and datastore disk space it takes). Which, in turn, defines snapshot commit times (during which VM performance will suffer).

You are correct on additional factors above, but I would say synthetic full is not just about saving bandwidth and proc, but quite often about simply making full backup possible. Let me clarify. When customers need to backup very large amount of VMs, or backup over slow connection to a remote office, they often report that full backups of those VMs take well over 2 days. In other words, they simply cannot afford doing periodic active fulls, even during a weekend. That's when synthetic full is a saviour.

Thanks!

[stormlight]

I forgot to include snapshot time. I was thinkin about me not everyone else. My largest vm is only around 300gb and takes 2 or so hours for a full which is fine for us (plus we plan space for large snapshots)

However to your last point about customers fulls taking 2 days ect.

If the initial full is seeded to the wan location and the vib's are replicating and the dedup box is doing it's job when you send another non synthetic full to the dedup box it's still going to only replicate the changes from the last nights Vib correct? So over the wan wire its the size of another incremental because the dedup box is doing it's job even though in Veeam it's a full non synthetic job

However if your saying that the dedup box can only dedup vbks to vbks and vib's to vib's I can see a weeks worth of data to take a little while to replicate since you are deduping a vbk a week apart and having to send 6 days of changed data.

Which statement above is the correct way to explain?

[Gostev]

"Non-synthetic" full backup (we call it "active" full) is absolutely normal, real full backup as you would expect from legacy backup application. Its creation does not use any incremental data, instead we gets all the data from the source directly, and sends every over to target across WAN. At this point, it does not matter what the backup target is, whether it is dedupe box or raw disk storage, it does not change anything. Dedupe only kicks in once the data actually reaches the box.

Dedupe box can dedupe any data at all. File extensions do not matter.

[stormlight]

I see where I am miss communicating. I was refering to two de-dup boxes.

One on local site one at target site.

I see your point if I was backing up to a target dedup box at another site. However My questions we based onbacking up to a local dedup box and then only only replicating changes to target de deduP box. I am sorry.

So technically I believe I could do a full active backup everyday and only put the changed data since the last full active over the wire.

[Gostev]

I cannot confidently comment on this one, because I do not know how storage level replication is designed in the dedupe solution you have chosen. But I would certainly assume that it only replicates new or changed blocks, no matter which files have changed, and re-assembles the files on the other end with this information.