Best Practice for Data Domain and Falconstor FDS

[floss]

Hi

Congratulations on the creating the best Vmware backup product per se.

I am just thinking through the best practice for Veeam 5, and Disk based de-duplication products namely DD and Falconstor and I have seen that you advise to use forward incremental's, but in my opinion I would beg to differ if this is the correct option ? may be i am wrong. OK Why? This is how I would generally set up Veeam and a deduplication appliance based on V4... and i find it is efficient and works well

Veeam would be set up in in a SAN mode to backup to local disk with a weeks retention
A mapped drive on the backup server would be a CIFS\SMB share on the De-Dupe device (local)
The De-Dupe device would have a ideally have replication partner in a remote location
All jobs would have post-job script that would basically pick up the VBK file from the local drive and create a date stamped folder on the de-dupe mapped drive which it would then place the VBK file in.
The de-dupe device will simply compare all VBK files and de-duplicate, if i need to restore i have a collection of "full vbk files" I simply import
This also deals with the performance issues around DD and Veeam as the copy process is a post backup event.

The problem I see is that, I have to create a date stamped folder on the de-dupe SMB share, If I simply direct all Veeam backup jobs to this area, all subsequent full backups will overwrite the existing file as they will in essence have the same name ie DC.vbk. Is there any functionality to date stamp full vbk backups ? ie dc-21-10-10.vbk

If i use the forward incremental method as suggested it will not really work with the above method as really need VBKs file to fully utilise the De-dupe functionality and I don't really want increments in what is essentially a backup store for long term data. Is anyone else doing this differently any ideas are much appreciated ???

Many thanks

[tsightler]

I don't understand this. Why would you want to run a full backup every day, no matter if you have a de-dupe appliance or not? Why put all that load on you production storage? Why do you need the "full VBK file" to fully utilise the de-dupe functionality? Most de-dupe appliances that I've seen work at the block level across all files. If you have a VBK file from Monday, and a VBK file from Tuesday, they're still going to have the same number of blocks different as a VBK from Monday and an incremental file from Tuesday. I don't have a dedupe appliance, but we run WAN acceleration devices that perform "in-line dedupe" and we find that the incrementals are still deduped at around 90%.

I don't mean to imply that there's anything wrong with your idea if that's what you want to do, but the disadvantage is that you have to run a full backup on your production storage every night instead of just copying the changed blocks. Perhaps your environment is much smaller than mine, but in our environment a full backup takes over 24 hours, while incrementals take only 3-4 hours each night. Our VBK files total around 4TB so just copying the VBK file to the dedupe appliance would take hours. I certainly don't want to have to move all of that data around every night. Nightly incrementals are just a few hundred GB, so that's much more manageable.

The goal for my backups has always been to minimize the impact backups have on primary storage (we are a 24x7 shop) so incrementals with CBT are the way to do that.

[Gostev]

Is there any functionality to date stamp full vbk backups ? ie dc-21-10-10.vbk

Yep, this is exactly how incremental mode in v5 works. Try backing up and you will see.