ContributionsMost RecentMost LikesSolutionsRe: Veritas System Recovery 16 - available now! Still no support for Red Hat Enterprise Linux 7 !? Any plan to support it in future release? Upgrade BE3600 appliance to BE2014 with Central Admin Server Hi, we are planning to upgrade from BE2012 to BE2014. We have one VM with Central Admin role and three BE3600 as Member Server Role. Should we first upgrade CAS and then the Member Servers (appliance)? Does the 2014 CAS work w/ 2012 appliance during thetransition period? Whichpatch levelof BE2014 should we go for? SP2 or ....?? Thanks for any advice. SolvedRe: BE2014 for BE3600 Appliance? OK.I understand the technical reason behind this delay availability to the appliance. but it becomes a somewhat "gotcha" in the marketing of the appliance - which definiately brings dismay to the customers who chose appliance over transitional software version. I hope in the future this time-gap will be shorten. And please do announce at least a time table for the release of 3600 R3 at the soonest. thanks. BE2014 for BE3600 Appliance? Anyone from Symantec can give a timeline on the availability of BE2014 upgrade on the BE3600 appliance please? Thanks. (I hope it won't take too long.....) SolvedRe: Support for SQL 2012 AlwaysOn? ZeRoC00L: can't find the button to mark as a solution. but thanks. Support for SQL 2012 AlwaysOn? The latest SCL for Backup Exec 2012 SP3 still lists AlwaysOn Availability Groupas an unsupported feature. Does anyone know if Symantec plan to include this in BE 2012 R2? thanks. Joseph SolvedCASO in a DR environment In our environment we use the Backup Exec 3600 Appliances. But this question should be common in any CASO setup? So we have a pair of BE appliance running in a CASO setup - main office is the Central Admin and DR is the Managed BE Server. So the BE database is hosted in the Central BE appliance. I have tested this scenario: If the Central BE is shutdown, I cannot operate the DR MBE - cannot even launch the BE console!And any back/restore job won't operate on the MBE at DR site. I've done some tests - convert the MBE to a stand-alone BE server etc. But the failback procedures are a bit messy. After the Central BE is back, it failed to re-connect with the MBE because it found the Dedupe Storage on the MBE already exists in the Central BE's database. It ends up we need to send the BE database to Symantec to fix it for us. For the DR environment, especially with Dedupt Storage - e.g. w/ the BE3600, does Symantec provide any standard procedures for failover and failback operations? Joseph Re: Dedupe performance Hi Mus Seth, Thank you for your time to answer my questions in details. So in short, can I say: deduplication will save storage space, but not necessary faster?? Thanks! Joseph Re: Opt-Dedup job fails with error "Final error: 0xe00084ec - A backup storage read/write error has occurred." Hi, thanks for the reply. In this case I'm running Optimized-Dedeup from one appliance's dedup store to another appliance's dedup store. Most jobs are ok but some failed with the above error. And once that one (duplicate) job fails, the remaining jobs that follows will also fail. I need to restart the BE services on both appliances to get it work again. But the same job re-run will finish successfully. So in short, the duplicate job will success at the end but I need to restart the BE services everyday!! I found a couple KB saying this is a known issue. Anyway I just open a case w/ Symantec Support to confirm this. Re: CraigV - the appliance does not enforce the primary backup location must be the dedup store. I've run jobs that directly backup to tape and successful. Opt-Dedup job fails with error "Final error: 0xe00084ec - A backup storage read/write error has occurred." Hi, I'm having exactly the same error, but in Backup Exec 2012 (BE3600 Appliance to be exact). I found the following article related to BE2010R3: http://www.symantec.com/docs/TECH201469. It just stated that it was a known issue. Anyone has experience this? Anyone know if Symantec has resolved this in BE2012? Thanks. Joseph