Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

Optimal stripe size and block size for dedup folder

Created: 06 Sep 2013 | 5 comments
Ralf Gerresheim's picture

Hi,

what is the optimal size for stripe size on RAID controller and for blocksize of the volume if the volume is used as dedup store?

I heard that dedup writes is 32 kByte Blocks and that  the stripe size on the raid controller should be No. of disks x block size. What, if a could not set that value, for example when I have 11 disks and could not se a stripe size of 352 kByte? (I can set 256bor 512). Or should I use then 32 kByte?

 

Thanks in advance.

 

Operating Systems:

Comments 5 CommentsJump to latest comment

Jaydeep S's picture

Not sure if there is any recommendation about this as such. But the Best practices mentions to "Disable RAID caching on the disk where the deduplication storage folder is located."

http://www.symantec.com/docs/HOWTO21767

teiva-boy's picture

Disabling RAID caching is Symantec's answer to, data corrupting in that rare .000001% situation.  As long as your RAID card has a battery backed cache (most do), please leave it enabled, if you want any type of decent performance.  I really hate Symantec's stance on that.

That said, the segment size that BackupExec uses for dedupe is defaulted I think to 64KB, per client.  You can change that value again per-client based on the application type that is being backed up.  Typical values are 32KB, 64KB, and 128KB.  Exchange will use one value, while SQL will use another, and file backups will depend on the data make up.

You must edit the PD.CONF file on each client to set this.  

Now, when it comes to your RAID card, you really just have to benchmark what makes the most sense. There is a mix of stripe size, as well as NTFS formatting size.  Usually I've just left the default on the stripe. However, I always ensure my disks are partition aligned, and formatted to the largest NTFS sector size I can use.  This usually gives the best performance.  You have to use diskpart to do this and the CLI to do this.

 

There is an online portal, save yourself the long hold times. Create ticket online, then call in with ticket # in hand :-) http://mysupport.symantec.com "We backup data to restore, we don't backup data just to back it up."

pkh's picture

As long as your RAID card has a battery backed cache (most do), please leave it enabled

Caches do fail at the wrong time.  Once, while my RAID 5 array was doing a re-build after a disk failure, a second disk failed.  The battery-backed cache also failed and the entire array is gone.  I had to recover the disk from my backup.  If the disk was holding the dedup folder, it would have been a greater disaster.  I think Symantec's recommendation to disable the write cache is a prudent one given the importance of the dedup folder.

teiva-boy's picture

Two Drives failed in a RAID5 array and you think your battery failed too. Nothing will save you there. Either you're grossly mistaken or you had larger problems not apparent to you.

Most cards today from Dell, HP, LSI, all do battery testing internally, daily, weekly, or monthly. Symantec's advice is a decade old.

There is an online portal, save yourself the long hold times. Create ticket online, then call in with ticket # in hand :-) http://mysupport.symantec.com "We backup data to restore, we don't backup data just to back it up."

pkh's picture

My RAID array is from HP.  They sent me 2 replacement caches and they both failed their own diagnostics.  This happened only a few years ago and the drive array is about 1 year old at that time.

I would rather be prudent than to trust the hardware vendors.