Video Screencast Help

OST vs CIFS for BackupExec 2012

Created: 18 Feb 2013 • Updated: 18 Feb 2013 | 20 comments


I am running BackupExec 2012 and recently bought 2 x Dell DR4000 as my backup media appliance.  I am planning on having one DR4000 locally and one at a remote location for replication.  While setting up the DR4000, I've learned that the DR4000 can not replicate to each other if OST containers are used.  However, it will replicate to each other if I use CIFS containers.

The delima comes in when setting up the jobs for backup.  

1.  Using OST, I can setup the backups to target the local DR4000#1 then "Duplicate" to the remote DR4000#2 and Tapes Library at the same times.  The Duplicaiton is being controlled by the Symantec BackupExect server.

2.  Using CIFS, I can usetup the backups to target the local DR4000#1 then "Replicate" the conntainer to the remote DR4000#2 and to Tapes Library.  The Replicaiton is being done by the DR4000's and run indedpendently from the Symantec BackupExect server.

*** Sorry, no picture for this one but it's a just a straight backup job to the DR4000#1 then Duplication to Tapes Library.

Which one would be the prefer method?  Let the BackupExec server do the Duplication? Or let the DR4000's do the Replication?  Is there Pro's and Con's to teach methods?


Comments 20 CommentsJump to latest comment

Gurvinder Rait's picture

if you replicate , then on the other media server when you want to do the restore you will have to perform a catalog operation.

Whereas if you perform the duplicate using backup exec you would have all catalogs intact and not have to perform them again. 

Plus using OST you get deduplication which helps to have more backups and occupies less amount of space which isnt the case with CIFS

sgrddy's picture

Thanks for the suggestion.  It's very helpful.

teiva-boy's picture

The DR4000 does dedupe whether you use OST or CIFS.  Your statement above is incorrect.

That said, it's a recovery question.  With OST, recoveries could be more streamlined and adminitration as well.  With CIFS, you'll still as mentioned have to do an inventory and catalog operation prior to doing a restore in a DR scenario.  But since it's a disk based backup you are restoring from, it should be a moot point, adn still extremely quick to perform.

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

sgrddy's picture

I wrote that the DR4000 does not replicate OST containers.  I didnt' mention about they are not able to dudupe.  I hope that clears things up a bit.


pkh's picture

Replicating is equivalent to copying your backup set.  This is not recommended.  See this document

Reasons why copying backup to disk data files is NOT recommended.

You should always duplicate your backup sets.

Tier4adv-Support's picture

I work for Symantec Backup Exec Support.

To the original posters question about replication, You can schedule backup exec to duplicate the job from one device to the other device. Which gives you information in backup exec to know when it happened and if it was successful. Incase of a failure, no matter which method used, You have to inventory and catalog the device before performing restores. Some admins, will just swap the names or IP addresses. So if you backup to Primary and duplicate to secondary. If primary fails, they will just change the info on Secondary to mimic Primary and Inventory / catalog it. Than can perform resore or backup to. If both are added in backup Exec, just inventory and catalog it, than you can perform restores or target jobs to it.

 I find it easier to let the devices do it. if you have 2 matching devices with the ability to replicate between them. I let the appliance do it. The benefit from it, normally is it wors at block level. So if you Backup To primary and it gets deduplicated, than the replication happens, to secondary VIA the appliance, it normally does the block data and its intelligent about it.

When Backup Exec performs a duplicate job, the data has to be given back from the appliance to backup exec which than tranfers it to the other appliance, which Backup Exec dosn't really know they are identical devices.  When the appliances do it in the background there is normally better connection / application on the device doing that.

On OST vs CIFS using most appliances. (new to me that an OST device can't be replicated or deduplicated. The point of OST is that its a standard that can be deduplicated and replicated) I will research this more and reply back later.

There are many advantages to using OST. Most OST devices like Data-Domain and Netapp and exagrid. Have great support for OST. If you purchase one of these device you will always want to use OST. this requires the Licensing of a deduplication license in Backup Exec. but you get so many benefits.

There are direct API calls with OST, that allow multiple read / write threads. It allows direct access and client side dedulication. Allows servers that are backed up direct access to the OST device instead of through Backup Exec. All of this has increased performance and reliability.

Using CIFS with a B2D has limited connetivity, no direct access, but works just like a B2D folder. Some application GRT or Exchange GRT. Will have resoure or failures when writing to B2D. This is from the limited read / write access to the device through Backup Exec. Some appliances work better than others.

DataDomain is one where if you use OST and the DDBoost plugin they have for their OST appliances where direct access and multiple read / write threads allow application and exchange GRT to work with our resource errors, you also notice MAJOR throughput increases. As much as 20 times the bandwidth.

As a Deduplication and OST tech I would always recommend anyone who has an OST device to purchase the deduplication license and use OST to boost performance. if you have a small environment and simple setup. Just backing up files and time is not a concern, simple B2D on Cifs will work and should have no issues.

If you have a large environment with Vmware / Hyper V, Doing AVVI or Hyper V backups with Application GRT, or even exchange backups with GRT. Getting throughput or backup time issues, You can trial dedupe, configure OST and create an LSU on your OST device. Download the plugin from your provider and configure an OST / LSU storage share and test the backups to that. See if the errors or performance increases. If it does, than you can decide which is better for you. if you encounter the same issues or errors, it is possible your seeing a different issue.

sgrddy's picture

Thank you for this reply, it's very helpful to understand that it's more efficient to let the appliances to do the replication and that either way, I would have to re-catalogs to restore for the secondary appliance.  Letting the appliances do the replication also free up the backup server to do other backup jobs.

The problem with the Dell DR4000 is that somehow, it won't replicate the containers that is OST therefore render the replication between appliances useless.  There is no paper that I can find that even mention support for replication using OST.  This is very dissapointing that it won't support 

Basically, there is no perfect way of implementing this setup, there are pros and cons to both.  OST = can't replicate, CIFS = slower and no intellegence.

Please let me know if you find out anything about using replication on OST containers on the Dell DR4000.


Colin Weaver's picture

Do not replicate CIFS backup targets that are used for disk storage unless you really understand what you are doing - please see for an explanation of some scenarios that might be broken if Duplicate jobs within Backup Exec are NOT used.

CraigV's picture

...shouldn't you have the Symantec employee badge next to your name? I thought you guys all had to log on with your internal mail address...?

Alternative ways to access Backup Exec Technical Support:

teiva-boy's picture

Keep in mind when talking about all the benefits of OST, we're usually talking about the more established players like DataDomain, Quantum and Exagrid.  They have been doing this for a few years now and have worked out the bugs and have the latest features.

Dell on the other hand is very late to the game, and you essentially have a 2.0 release of their product with a 1.0 release of OST.  May they'll catch up someday, but it's very possible you are just limited by the immuture implementation of OST by Dell.

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

sgrddy's picture

On page 6 and 7 of the pdf below mentioned replication (duplication) for OST.  Apparently, the OST replication is being done under BackupExec as Duplication.  That is my understanding.  If that is the case then I would just setup the Duplication job within BackupExec and be done with it.

daames's picture

I've updated my DR4000 today wth the last firmware ( I'have uptaded the OST plugin.

Backup Exec 2012 doesn't work now.... Device detection in loop.... all devices in red...

daames's picture

Problem solved : All your DR4000 appliances must be in the same firmware version with the corresponding plugin.

zadood's picture

I want to clarify something why does the OP state that replication is not supported between OST containers? Is there any documentation that points to this?

dkapell_hcc's picture

zadood - DataDomain documentations states:

"In DD OS  release 5.1and above, MTree replication is not supported for Boost storage units. Only managed file replication is supported for Boost storage units."

ct_br's picture

sgrddy, the DR4000 does support optimized duplication (deduplicated replication) when used with OST. If you are still having issues, contact me offline and I will be happy to help.

sgrddy's picture

Hello ct_br,

Sorry to dig up the old thread but I was searching for something and ran accross my own.  Are you able to use the Replication feature in the DR4000's to replicate OST containers?



dkapell_hcc's picture

OST containers must be replicated by software (ie backup exec duplicate jobs)

sgrddy's picture

That is exactly what I thought.  Because there is no way to setup Replication using the DR4000's build-in replication feature.