Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

optimizing for dedup and upgrading to 2012

Created: 06 Nov 2013 • Updated: 19 Nov 2013 | 25 comments
This issue has been solved. See solution.
In the progress og getting ready for upgrading my 2010 R3 edition to 2012.
I was recommended to move the BEDB database over on a SSD storage to maximise dedup performance.
 
i was planing in following the tech Article: 
 
 
would i be better to move the database before upgrade or after?
is it enough to move the database over on the ssd ?
 
 
/martin
 
 
 
Operating Systems:

Comments 25 CommentsJump to latest comment

pkh's picture

I was recommended to move the BEDB database over on a SSD storage to maximise dedup performance.

Whose advice is this?

Emort's picture

Our Hardware/software/service supplier . they are Symantec Certificeret partner...

pkh's picture

You should check with Symantec Tech support. I have not heard of this and the recommendation does not make sense

Emort's picture

thanks i have created a Case with Tech support.

teiva-boy's picture

All enterprise backup products can leverage SSD for the dedupe database and see performance improvements. The symantec BackupExec team doesnt recommend or advocate for hardware configs. You wont get a good answer ive found for the last 10+years supporting it.

As examples, Commvault recommends it, avamar has it in their 7TB nodes, all DataDomain 4000 series and higher systems have it, and more. I think ive read some Netbackup postings that said it helped.

I would recommend a mirrored pair though, even if only 64Gb drives...

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

The recommendation to the user is not for using SSD for the dedup folder, but for the BEDB.

teiva-boy's picture

Maybe it could solve the dismal synthetic backup performance?  No one seems to know why that feature sucks so bad.  But otherwise, it'll do nothing IMO.

The dedupe database is where SSD would shine.  Not BEDB and not the Dedupe folder.

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

Which is why, earlier I asked the user to verify this with Symantec Tech Support.

I doubt anybody can afford to put the entire dedup folder on SSD.  It would make more sense to put something like the indices on SSD.

Emort's picture
Okay... Symantec Tech Support called me to day. And i must say, i can not understand why they put their name to that outsourced support function. They had NO clue what the issue was about, and did not understand the writen or spoken question. 
 
I ended up with no clarification and not solution . well the tech. support offered me to upgrade my solution to the new 2012 edition . and urged me to take a backup of the catalog and data folder, before upgrading.! 
 
frustrated -  ended up asking him to close the case and i disconnected the call..... 
 
i will try to create a case one more time.
 
How can i clarify my question more?
 
/Martin
pkh's picture

The reason why I asked you to check with Symantec Tech Support is that I have not heard that moving the BEDB database over on a SSD storage would maximise dedup performance.  It is not in the dedup best practices.  See below

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

Since you are not going to pursue this with Tech Support, I would suggest that you ignore this recommendation and save yourself some money.  Just go with the best practices in the document above.

SOLUTION
teiva-boy's picture

Historically, the PM and TPM for theBE teams dont test hardware or test performance. Have you seen the tuning guide for BE? Its terrible.

You will not get an answer from them ever in regards to hardware. Buy a cheap consumer ssd drive and test yourself, that is the only way. If its jot better return it.

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."

Emort's picture

Thanks all, ill start off by ignoring the SSD's and BEDB option.

teiva-boy's picture

A mirrored 64GB SSD drive will still be largely beneficial for the dedupe database. Whether it'll benefit the BEDB, is another story. They are two different DB's, with two very different access patterns.

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."

Emort's picture

okay. can i determine the dedupe database location ?
and are there any demands or rule of thumb for space consumption

pkh's picture

In addition to the location of the dedup database, do tell us

1) how to move the dedup database to the SSD

2) how to benchmark the dedup performance, with and without SSD

3) what SSD do you recommend

Vishal Shinde's picture

Hello Emort,

I may like to have my inputs with you kind permission,

In order to improve a dedupe performance, it will be always good to host your Dedupe folder and Dedupe database.(which is not BEDB, it a flat file postgres SQL database, which stores the finger printing and meta data information.) on SSD drive.

Note:Symantec recommends to have dedupe folder and the dedupe database at the same location.

Regards,

S

Vishal Shinde

Sr.Learning Consultant

Symantec Education Services

pkh's picture

it will be always good to host your Dedupe folder and Dedupe database on SSD drive.

In the near term, this statement is a motherhood statement.  Since the dedup folder and dedup database must be in the same location and the dedup folder is in the TB range, the cost of such a SSD drive would be prohibitive.  Furthermore, I am not mistaken, commonly available SSD drives has not reached 1TB.

CraigV's picture

...can you provide a link to a document or TN to support this please?

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

Vishal Shinde's picture

Good point. Pkh!

However the discussion is more towards performance so I have left to decide the cost part with the user.

And talking about the capacity, I am sure you must have heard something called as “spanning or extending drives”, which enables the user to bring together multiple smaller capacity drives and make a larger one.

The impact and risks involved of doing so is negligible as compared with the gain on performance,

Thanks again, for the valuable input.

 Regards,

S

Vishal Shinde

Sr.Learning Consultant

Symantec Education Services

pkh's picture

The question is whether BE support such spanning architecture and then there is the cost vs. performance problem.

teiva-boy's picture

Since I haven't found an easy way to move the dedupe database... This is an alternative. Install BE2010 R0 first, putting the dedupe database in your preferred location. Then upgrade to R3 or to 2012, and the location seems to stick. Since R2, you could not use a different path.

Some SAN arrays allow for SSD and SATA to be mixed in a LUN. So if you have those from the likes of EMC' FAST, or Compellent's fluid architecture, or 3par, you don't have to dedicate SSD for this purpose. And there are software solutions too using PCIe cards with flash and they can tier to disk for less accessed data.

Basically, there are a lot of ways to get good performance in this. You can't just take Symantec's HCl as gospel. If we all did that, we'd all be in trouble.

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."

SOLUTION
pkh's picture

What is the purpose of splitting the dedup database and dedup folder?

you don't have to dedicate SSD for this purpose

So the dedup database is stored on disk?  Does this mean that your earlier recommendation to use a SSD for the dedup database is not feasible?

Vishal Shinde's picture

Hello ,

It is certainly supported for the deduplication destination, as BE Application is unaware of the inline architecture, and for an OS it appears as a local drive on the server.

As Teiva-boy suggested, there are infinite probabilities to work around the performanace beneath the operating system, which best suits the environment and the pocket too.

Backup Exec is good, as long as it has the dedupe hosted on a local drive and there are no data drops.

Regards,

S

Vishal Shinde

Sr.Learning Consultant

Symantec Education Services

pkh's picture

I have done some research and is unable to find out how to construct a 5TB SSD drive using commonly available 0.5TB 2.5" SSD drives.  Can you give some details on how to do so, including the hardware used?

Teiva-boy's recommendations are for avoiding the use a a dedicated SSD for the dedup folder and database, so they do not apply to your earlier recommendation to use a SSD for the dedup folder and database.

Also, how much performance gain can I get from using SSD  for the dedup folder and database?  How do I do a benchmark of the dedup performance, with and without using SSD?

Vishal Shinde's picture

Hello All,

In an effort to define the specific scope of this discussion and confine to it, I have put together the objective as posted by the Martin.

“Optimizing the De-dupe performance with Backup Exec 2012 with the usages of SSD disks.”

Please review the following summary and ensure that we have an understanding of what constitutes the need of the customer. (Martin.).

1. hosting the BEDB database on SSD drive, logically may have overall performance gain, as the database I/O are fast, but may not be specific with the Dedupe.

2. Hosting the dedupe database,(flat file postgress SQL) on a separate volume was possible with the earlier version of Backup Exec, however it is no longer an option and is recommended to host both ( Dedupe database and the Dedupe destination folder) on a same volume.

3. Backup Exec or the integrated Pure Disk (Dedupe) are Applications, that works above the file system, so technically, it do not care, what is the disk architecture used below the file system, however we do have a best practices to avoid any issue due to I/O drops.

The following is the excerpt from the HCL for Backup Exec 2012, about the De-dupe destination:

"Only Local disks may be used for de-duplication storage. Removable interfaces like USB and FireWire are also not supported due to the perceived temporary connection method and issues

That can arise from a device that is unsafely removed or appears on a different path. For Devices with a supported interface the absence of a check here does not signify that the device will not be supported, merely that de-duplication tests have not been run in combination with this device.

The Backup Exec Deduplication Option is recommended for use on a dedicated / non-removable volume as the location to store the deduplication disk storage. For this reason, there are no dedup checkboxes in the Disk Cartridge device section."

4. I greatly regard the research done by PKH, and he is right , that we cannot easily have SSD raid for more than 4 TB due to I/O bottle neck issues, however the data Size of the Dedupe to be greater than 5 TB, is merely a speculation, nowhere has Martin mentioned about his data size it in the discussion.

So probably he may look at the hybrid option of mixing the SSD and HDD as suggested by Teiva-boy.

Best Regards,

S

Vishal Shinde

Sr.Learning Consultant

Symantec Education Services

SOLUTION