Veeam Local Repo

[lm_ib]

Hello,

I've been looking around for an answer to this one, but couldn't find a clear one;
We currently have 3 esxi servers with local storages, a 4th server is the target machine which holds both local storage and a sas-das md1000 with a large raid for replications. Veeam server is a virtual server on the target machine, installed on windows server 2008 r2.

I am trying to figure out the best way to setup, storagewise...

Replications should go on the md1000 storage, which is one big datastore connected to target machine.
Backups are the catch... should i configure additional disks (2tb) on the esxi, assigned to the veeam server? Should i rather group them together in a windows logical wrap? ...maybe combine space with vmware disk-provisioning (although the option is grayed out since it's a 'dumb' storage - i did manage to create a large vmdk)

The main idea and crucial part would be to keep the backed up data safe in case the veeam server faild, meaning leaving it as stripped as possible. for instance, configuring a large logical volume on the windows server would become a problem in case the server fails?

Any ideas?


Thanks!

[dellock6]

To have a single copy of your backups is a security risk, and to me it does not matters how you design your primary backup storage, as long as you have only one.
The kind of design you described has too many layers to be at the same time efficient and simple to manage: local storage, hardware raid, VMware ESXi with VMFS, then vmdk disks on it, then Windows NTFS in the virtual machine using the VMDK disks.
A much more simple design could be to install directly Windows in the physical machine, and Veeam into it. Windows has no problem in using large storages since you can use GPT partitioning and get access to the whole storage into the MD1000.

Keep the design simple, and protect your backup infrastructure by having multiple copies of your backups.

Luca.

[lm_ib]

Thanks for your replay Luca!
Installing Veeam on a physical server, how would i be able to use the target's local storage or the md1000's?

[veremin]

You can deploy Windows-based machine on a target host (or utilize any existing one, instead), specify it in a Hot-Add mode and use it as a target proxy for replication job.

Furthermore, I’m wondering what proxy servers are being used in your environment. Is it just a VB&R server that plays this role, or you have additional proxy servers deployed on the source ESX(i) hosts?

Thanks.

[lm_ib]

Eremin,

The issue is with access to the backup storage, not the replications... since the md1000 unit is connected directly to the target machine.

[lm_ib]

http://s10.postimg.org/58aq4ggbt/image.jpg

[dellock6]

As I said, if the MD1000 is connected to the physical machine, you should be able to see its storage as an additional local disk of the physical machine itself.

Luca.

[veremin]

I must have misunderstood you slightly.

So, the point is that it’s not possible to utilize ESX(i) storage as a backup repository. Moreover, it is certainly out of “best” practice to store replica data in the same place with backup one. This topic is likely to shed a little more light on what I’m talking about.

If I were you, I’d probably deploy physical Veeam instance, attach the aforesaid appliance (MD1000) to it, and utilize it as a backup repository. Meanwhile, add some local drives to the forth ESX(i) host and replicate critical VMs to it; assuming, of course, that 4TB isn’t enough to host replicated VMs.

Thanks.

[lm_ib]

I must have misunderstood you slightly.

So, the point is that it’s not possible to utilize ESX(i) storage as a backup repository. Moreover, it is certainly out of “best” practice to store replica data in the same place with backup one. This topic is likely to shed a little more light on what I’m talking about.

If I were you, I’d probably deploy physical Veeam instance, attach the aforesaid appliance (MD1000) to it, and utilize it as a backup repository. Meanwhile, add some local drives to the forth ESX(i) host and replicate critical VMs to; assuming, of course, that 4TB isn’t enough to host replicated VMs.

Thanks.

Thank you for your replay Eremin.

Do you mean that the replica and backup storages should be separate for security reasons? if so, i agree. But still, i could use the MD with two RAIDS, 7.5TB each, and designate each for it's job.. the disadvantage here would be that the 2tb limit would force windows intervening with the disks...

Considering your suggestion, I am thinking maybe to use the 2 SAS connections the MD has, and connecting it to the target, and a physical veeam server...

[dellock6]

Well, when you create the two 7.5 TB luns, you can assign one to an ESXi host (and so having the 2 tb limit on the vmdk disks) for replica, but then assign the other one directly to the physical Windows server, that can format it with GPT and then use the whole space as a contiguos file system.

Luca.

[lm_ib]

Luca,

..I am still trying to come up with the best way to do this

With your last example, splitting the storage would allow 7.5TB to be assigned as a storage for replicas (just as in any other scenario, the 2tb limit is irrelevant since it's not a drive assigned to a host). The other 7.5 would be configured on the physical Veeam server, GPT configured...

btw..
how recoverable is a gpt drive? In case windows fails, reinstalling it will keep the drive and its files in tact?

[dellock6]

GPT is as native in Windows 2008 and above as like MBR was before. If you do not delete anything, you can connect the drive to another Windows server and read all the data from there.

Luca.