Moving Veeam to Physical Server - Options?

[ninjaburn81]

All:

Since day one I have been using Veeam on a VM that runs on our production SAN with the other VMs. Backup times have been great; we have an iSCSI SAN, and backup data through Veeam directly to a Data Domain 620 system. However, I am now torn on the best course of action with 7.0 coming out. I plan on using its tape backup functionality immediately to archive older backups (say 6+ months) to tape and simply allow Veeam to recycle the restore points. Thus 6 months of data on the DD, and all older data on tape. Simple and clean, and Veeam controls it all.

However to use tape, we have to move Veeam to a physical server, which causes me some trepidation. So I want feedback and see if other people are set up in anything similar to what I am thinking.

Option 1: One physical server to rule them all. I migrate to a physical box running Veeam 7 and Win2k8R2. Backup still works the same, and when 7 is released I backup/archive to tape as well. My only question is backup times. It will be connected to the same top of the rack switch as the VMware hosts, but I am still nervous on taking a speed hit. Should I also present the SAN LUNs to the backup box, or create a VLAN just for backup? Neither of which I have setup now because I honestly have no need. How are others set up with physical Veeam boxes?

Option 2: One physical/one VM. I keep the VM I have right now running as normal, and then set up a physical Veeam box solely for doing the tape archival. I know from a licensing perspective it doesn't matter since its only the host CPUs being licensed, but I have to wonder how the Veeam servers would communicate, and properly do the archival?

Just curious on everyone's thoughts and experiences. Thanks guys!

[veremin]

From my perspective, the first option is preferable, since every activity would be done through one pane of glass. In other words, such a scenario is supposed to guarantee that you wouldn’t be confused with number of different tasks that have to be done on different VB&R instances, and also that you wouldn’t unintentionally forget something.

With the second option, before being copied offsite, the backup data needs to be moved to the second VB&R server. Then, in order to copy corresponding data to tape appliances you will have to either use “files-to-tape” job or become a little bit creative, putting into use “dummy” backup job.

The disadvantage of “files-to-tape” job is that you will lose required VM tracking mechanism - you won’t know on which tape medias particular VMs reside on, what medias are required in order to restore certain VM, etc.

As to the usage of dummy job, since imported backups cannot be used as a native source for a backup job, you will have to create a “dummy” backup job, map it to the backups that have been imported from the virtual VB&R server, and then use this job as the source for “backup-to-tape” copy job, that, in contrast to “files-to-tape” one, allows you to track VM data on tape.

Thanks.

[foggy]

My only question is backup times. It will be connected to the same top of the rack switch as the VMware hosts, but I am still nervous on taking a speed hit. Should I also present the SAN LUNs to the backup box, or create a VLAN just for backup? Neither of which I have setup now because I honestly have no need. How are others set up with physical Veeam boxes?

No need to worry about speed hit, with an iSCSI SAN you can setup Veeam B&R to use Direct SAN transport mode that could provide even better performance than your current setup. I would also go with the first option.

[ninjaburn81]

I am leaning toward the first option as well, but as I said, nervous about increased backup times. I forgot about the Direct SAN option, and I can easily add another NIC if need be. I do wish there was a way to do tape from a VM, but that is a mess of paravirtualization and pass-through that would be needed to make it work, so I can understand why Veeam is going the easy route for its first time in giving this feature. I have been using Backup Exec to handle the off-site tape and it sucks doing it that way. As v.Eremin noted, you lose the tracking mechanism and you have to manually note what is getting backed up to what tape.

[Vitaliy S.]

Hi Adam, direct SAN access will likely decrease your backup times , especially if you follow all the instructions mentioned in the topic posted by foggy.

[yizhar]

Hi.

I agree with all post above and also recommend the first option:
physical Veeam server + direct san mode.
I would like to add the following tips:

* First of all - don't be nervous. There is no need to in that case.
If you are in doubt about the planned change - check it out (next tips will help you).

* Backup performance -
Those can be enhanced using SAN mode, and also reduce load from esxi hosts.
However if for any reason you prefer to keep using hotadd mode (if SAN mode isn't applicable or if physical host has limited resources), you can still utilize a VM as proxy server and use it like you do now.


* I am using physical Veeam servers when possible with current version 6.5, regardless of the upcoming tape support,
and I think that this should be the best practice whenever possible.
Some reasons (again - regardless of the tape support):

1. If the SAN fails for whatever reason, including human error, or in other worst case scenarios, it would take more time to start a restore because the backup VM isn't available. A dedicated server outside of the production system eliminates such issues and allows access to backup and restore in such cases.
The backup system should not depend on production whenever possible.

2. You can use SAN mode for fast backups, and without using VMware host resources (cpu, ram, san and lan networking).

3. Protection of the Veeam server itself can be accomplished in many ways, for example using the "backup configuration task" of Veaam v6.5 and above. Or even using a simple USB external disk and Windows Server backup, just for protection and fast restore of the backup server OS itself if needed.

4. The backup server can also be used as a management system with access to SAN management and other tools - in case the production system isn't available. I install such tools in advanced on the backup server for regular maintenance but also for that purpose.

5. There are more advantages that I probably forgot to mention.

* Testing -
You don't need to wait!
You can configure a physical host as a Veeam proxy with connection to SAN and start testing SAN mode right now,
without changing your current deployment and existing backups.
Once you are satisfied with the results, you can plan to go ahead and setup Veeam management server on physical host.

Botton lines:
* Physical Veeam host is a good option.
* You can try it out right now - just make sure to read and follow related instructions and tips about SAN mode (start with FAQ in this forum).

Yizhar

[veremin]

As mentioned, kindly don’t forget about protecting VB&R server. The best option in this case might utilization of Veeam Configuration Backup that is responsible for retrieving configuration data directly from the SQL database.

With regards to recommendations, you can create a share disk, map it to your physical instance of VB&R and use as a target repository for configuration backup. Should any disaster situation happen (physical server goes down, for instance), all you would need to do is to install Veeam on any other machine you have and start backup/replication process from there.

Thanks.

[ninjaburn81]

For backing up the physical server, we still have Backup Exec for physical servers that are not (or cannot) be moved to VMs and I will simply use that to take care of it. Heck I actually use it already to backup my Veeam server due to all the issues I have heard over the years with Veeam trying to backup itself.

I have now read through the referenced FAQ and will definitely use that information in there, and I agree with people saying Veeam shouldn't be stored on the production SAN anyway...lose the SAN, lose Veeam. All great info and food for though, thank you!

[Gostev]

For backing up the physical server, we still have Backup Exec for physical servers that are not (or cannot) be moved to VMs and I will simply use that to take care of it. Heck I actually use it already to backup my Veeam server due to all the issues I have heard over the years with Veeam trying to backup itself.

If you have Veeam B&R 6.5, then this is really not needed anymore... just use our built-in configuration backup, this can go to any repository.

[foggy]

For backing up the physical server, we still have Backup Exec for physical servers that are not (or cannot) be moved to VMs and I will simply use that to take care of it. Heck I actually use it already to backup my Veeam server due to all the issues I have heard over the years with Veeam trying to backup itself.

And actually there are no more issues with using Veeam B&R to backup itself (just a couple of things to keep in mind).