Backup Exec as VM or physical

Hi Spiros,

 

Your major reason for a physical server is down to support. if you're accessing something like a tape drive/library, Veritas are within their rights to not support your issue.

Read below:

https://www.veritas.com/support/en_US/article.TECH130609

Functionally it lso doesn't work. If your media server is accessing something like a tape drive/library, then the VM cannot be vMotion'd properly. Also, if the tape drive drops out of Windows, you're going to have to restart the ESX host = unnecessary downtime. I've had first-hand experience in this fact when my suggestions about physical servers wasn't followed. Big issues until they bought physical media servers 18 months after implementing a solution I didn't agree with.

For DR purposes, look at SDR for the media server, or at a bare minimum, backup the BE installation directory and the SQL DB. If you don't have the agent, then the directory to which BE is installed will have the bedb.bak which is automatically created every morning at 4AM.

You can recover the BE media server from this.

Thanks!

...also, to replicate data to a DR site you'd need to use the Enterprise Server Option with CASO licensed, and have a media server on the other side.

Chat to your reseller on the licensing around this.

Thanks!

In addition to the previous advice, one of the reason why a virtualised media server is not recommended is that it might not be able to cope with the demands when you use the dedup option.  This could be one reason for your previous bad experience with dedup.

If you are not using dedup, then the demands on a media server is not really that great.  You don't have to use a very powerful machine.

One of the advantages of using a physical media server is the ease of recovery using SDR.  If this machine is dedicated as a media server, then the SDR should be pretty fast.  If you are using a virtualised media server and your data centre is wiped out, how are you going to recovery the media server VM?

Disk media sets are fine.  They are a lot easier to managed than tape during a DR situation.  Just connect them to the intended media server and you should be able to use SDR to access these disk media sets.

You should not replicate your disk backup sets between two sites.  This is equivalent to copying the backup sets.  See the document below

http://www.veritas.com/docs/000015327

The recommended way to get backup sets from one site to another is by optimised dedup.  You need media servers on both ends with the dedup option and CASO (part of ESO) to share the dedup folders between the ends.  You then backup to the local dedup folders and then duplicate the backup sets to the dedup folders on the other site.  Only the new data blocks would be send across the link thus minimising the WAN bandwidth requirements.

Unfortunately the new disks that you are getting are not capable of OST.  If they are Data Domains and have the Boost capabilities, then they can be used in place of the BE dedup folders.  The dedup processing would be offloaded to the DD and it should be faster.  You can then do optimised dedup between the two DD's.  I am talking about DD's because they are Dell's.  Other OST devices will do just as well

If we are not going to use tape drives then we could see the scenario of Media Server as VM with Dedupe a good option ? 

Are we going to have almost the same speed with HotAdd Transport like SAN Transport? When not , what is normally the different between those two as speed, 10% 20% ..? 

Do you think Dedupe is risky because dedupe is so sensitive, exlude from all AntiVirus etc., and we should go only for Disk Base backups? 

I am trying to cover all questions and "dark spots" to avoid problems in the future. 

 

Forgot to mention that SAN Storage is only to storage the VMs and not to store the backups. Backup Storage is a Synology Cluster with RAID6

 

Thanks in advance

and deduplication Disk is the same Storage with RAID10

Synology model RS3413xs+

I don't understand. You seems to be contradicting yourself. First you rule out using dedup because of all the problems in the past then you want to use dedup with a virtualized media server again??? I have already told you that this is not recommended. If you are so set on using dedup with a virtualized media server, why post this discussion in the first place?

Sorry for missunderstanting. 

I would like to keep using Dedupe. Actually we use it and the Media Server is VM. 

I am trying to conviece and explain to my Manager that with the new system we should move away from having BEMS as VM and build a new physical server with 10GB direct connection to SAN being able to use SAN Protokoll and Dedupe. Thats my approach for the new system.

I have to fight now because he dont want to give direct access to BEMS to SAN because SAN is creating also Snapshots and he afraid that during a backup if something conflict with the SAN Snapshots we are going to have the whole SAN corrupted. Second issue is that he dont think that using SAN Protokoll will offer us more speed and better backups. Tried to explain the pros and cons between SAN and HotAdd but he dont see any big pro using SAN and having BEMS as physical. Third an last he dont like Dedupe because two times we had a corrupted DB because of Anti Virus. He believe that Disk backups are faster and easier to troubleshoot them or just restore them from another BE Server. 

His best weapon against physical is a disaster recover of the place where the BEMS is and the ability to restore him. If we have a VM BEMS, then we can start it as VM on the other site.

I try to gather all informations before the final discuss between me and my manager because if I am not able to conviece him for my plan he is going to keep BEMS as VM.

 

One more point is that I take a Backup from a VM 32.4GB over Agent. First to Dedupe, second to Disk.

Dedupe  2.7GB / min 51Min 59.4:1 ratio.

Disk     1.4GB /min 43 Min 

I just start a Backup from that VM over vSphere to dedupe and after I will retry to Disk. 

Dedupe 2.6 GB / Min 58 Min 1,1:1 ratio - 36.4GB until now and still running.. ( VMDK File is 55 GB) - Backup took 14 Min and the rest was the Verify Job.

Dedupe 4,2 GB / Min 52 Min 187,3:1 ratio - Runned after the first job to determinate if it would get faster done.

Disk 4,6 GB / Min 19 Min 

 

In compara NBD vs HotAdd to Dedupe seems the same but to Disk, HotAdd won. 

Should not Dedupe provide a faster backup in compare with 2Disk ?

 

Thank you for your support on the "VM vs Physical Fight" :-)

 

Regards

Spiros

The whole running a BE media server as a VM because of resource limitations is gone with the resources that can be assigned from within VMware itself.

The issue lies with accessing real devices, and Veritas mention supporting iSCSI ONLY in that TN I posted. So if the dedupe volume is on an iSCSI volume, you should be fine. They can confirm this if you contact them.

Antivirus applications are known to cause issues with backups, and it is for this reason that it is recommended that active scanning of BE services, dedupe volumes or B2D folders should be stopped and they should be excluded, so as to prevent corruption.

The initial dedupe backups are always going to be slow with low dedupe ratios, but the more you run them, and the longer you retain the data for, the better the performance. It would then end up being faster than a normal B2D.

A decent middle-ground is to have a physical primary server and then your DR server as a VM as long as you're not accessing a tape drive for instance, and comply with the TN I provided...cluster them and you will have proper fail-over. My 2-cents, and worth checking with the technical guys while running the TN past them.

Thanks!

 

1) Assuming that your data centre is wiped out and you have to go to an empty DR site, ask your boss where is he going to get the vmdk to start up the virtualised media server?

2) There is no such thing as a free lunch.  With dedup, you are saving on disk space, but you pay in terms of processing, i.e. in CPU power, memory and time.

VMware no longer supports SCSI passthrough so that means you can't access tape drives, autoloaders, libraries etc via SAS, SCSI or FC. That's clear on the VMware platform.

Veritas only supports accessing a "real device" through iSCSI. Nothing else.

A VMFS volume would be fine, but the VM may/may not vMotion, depending on how this has been set up.

Go with what your boss wants...nothing makes them happier. bear in mind potential lack of support and point this out to him when you aren't helped, depending on your configuration.

Thanks!