I would like to have your opinion about Backup Exec as VM or as physical.
Short to our infrastructure, we have 3 ESXi Server and a Synology System connected per iSCSI and running Disk-based and Dedupe Backups
Media Server is now a VM.
Until today we have Backup Exec 15 backing up all VM , arround 100, most of them over Agent , some over vSphere.
We have only some over vSphere because that is slower in compare with Agent Backups.
To be honest we had few times corrupted Dedupe DB, thats why we start taking a Backup of VMs to Disk-Based Storage.
Now we bought new ESXi Servers and a new DELL SAN Equallogic connected with 10GB and we want to replicate everything between two sites.
The question is what should we do with the Backup Exec Server. Should we re-install Backup Exec as VM or go for the physical?
What are the pros and the cons?
Online I read almost all articles I was able to found but nothing with exactly reason WHY we should have a physical Backup Exec.
I know that have BE Media Server physical give the option to use SAN-Protocol which is faster than HotAdd or NBD. But how much faster?
Is the speed the only plus ? Worth the extra power consumption and hardware?
Having BE Media Server as physical how can we act when a disaster recovery occur and the media server, for example, burned?
Do you think tape backups are not "old-school backups" and we should start considering of them?
Thank you very much for your time
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.
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.
...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.
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
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
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" :)
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.
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.
thank you for your effort about that.
I am able to understant that BEMS as VM is not recommended and against Veritas recommendations, reading all posts online.
Unfortunately, I was not able to found any reason WHY it is not recommend. What is the pros and the cons. Maybe we should just make a table and
start gathering all pros and cons, a table who is going to help more ppls taking the final , critical for their business, deciscion.
Please help me update him.
|Info / Source||Backup Exec Physical||Info / Source|
|Deduplication||X||Performance hardly depends on VM resources||X|
B2Tape can be achieved but have many limitations and troubleshooting a problem may be complex.
B2Tape support almost all Tape Libraries in the market.
Please check HCL
As VM cannot support and use SAN-Protocol
Please refer to:
As Physical server cannot support and use HotAdd-Protocol
Please refer to:
|NBD-Protocol||X||NDB (LAN) - Taking a backup over LAN is fully supported.||X||NDB (LAN) - Taking a backup over LAN is fully supported.|
NDBSSL (LAN) - Taking a backup encrypted (SSL)
over LAN is fully supported.
|X||NDBSSL (LAN) - Taking a backup encrypted (SSL) over LAN is fully supported.|
|BEMS Recovery||X||Having a full backup of Catalogs and Data folder of Backup Exec Server, a new BE Server muss installed and overwrite the Catalogs and Data folder with the backup.||X||Having a full backup of Catalogs and Data folder of Backup Exec Server, a new BE Server muss installed and overwrite the Catalogs and Data folder with the backup.|