repository format/layout choice questions

[stormlight]

Hello,

We have a SAN that we want to maximize its use and not just have it simply be a Veeam repository. What is the best way to do this? One thought is to format the entire device as VMFS. This allows us to place other VMs on the SAN while at the same time not limit it to Veeam. One of these VMs could be a windows machine that Veeam directs its backup files to. If we do that how should we share out that windows server? Should we create software ISCSI targets in the windows VM? Should we use SMB shares?

How much of a hit does performance take if we do it this way verse using block level storage format on the SAN?


Any other ideas to share a Veeam repository?

For what its worth we don't want to cut the san up into volumes (one of veeam one for VMs). We find that we are always fitting volume size limits at the end of the day.


Thanks

[skrause]

Best practice is to not have your backup storage be on the same device as production VMs. If you have a hardware failure you potentially lose both your production data and your backups.

If your backup repository server is already a physical server and you are fine with keeping it that way, I would still expose the backup storage portions as LUNs to the repository server directly. If you then create other SAN volumes and map them to your VM infrastructure for datastores that would work.

[stormlight]

Best practice is to not have your backup storage be on the same device as production VMs. If you have a hardware failure you potentially lose both your production data and your backups

We are not doing this or want to. What we want to do is to share our Veeam repository that holds the backups from another production SAN with Dev and other VMs. For example, SAN1 production VMs get backed up to SAN2. SAN2 can also act as a storage location for Dev,test, and other low hanging vmdks. If we need to back up these dev VMS they would get backed up somewhere else.

If your backup repository server is already a physical server and you are fine with keeping it that way, I would still expose the backup storage portions as LUNs to the repository server directly. If you then create other SAN volumes and map them to your VM infrastructure for datastores that would work.

This is what we do now and as stated we do not want to do this anymore. Once we cut our luns up we run into storage partitioning balance acts. (even with san thin provisioning) We want to have the SAN be one single format. We are leaning towards VMFS. Any ideas about the questions in my first post?

[skrause]

In that case, you could format the entire thing as one big LUN and expose it to the hosts, creating VMFS volumes on top of that.

Then you could have your repository server be a windows server that you create virtual disks for the repository volumes on that server. Just treat it like any big virtual windows file server.

I would probably create multiple datastores, leaving the Veeam repository volumes on their own datastores that don't share with the other VMs to cut back on possible I/O contention issues.

[stormlight]

Yes, that is what I proposed to do above in my first post. The questions I have are:

1. Generally how much overhead does using a windows VM to store veeam backups in a VM add verse using block storage on the SAN? No specifics just general thoughts.
2. If we go the windows vm route what is the better way to share the repository from the VM. Should we use software ISCSI in the VM? Should we use SMB shares in the VM?

[dellock6]

In regards to 1. I would not do it, not because of the overhead but for the complexity of a restore: If you use a plain LUN mounted to a physical windows repository, you format it with NTFS, consume it as a repository, and if you lose the Veeam repository "any" windows machine connected to the SAN can immediately see the NTFS partition and import the backups once Veeam is re-installed.
If instead you format it with VMFS, then you need a new ESXi, mount the volume, scan it, register the VM, power on the VM to be at the same point as before. It's way easier to have around a windows box than an ESXi, and there are 2 fewer layers that can break (VMFS and VMDK).
for the protocol, way better to use iscsi (and you can use again any windows machine, even a laptop with an ethernet card, to mount the ntfs via iscsi).

If you have additional space in the array, I'd format the first volume with ntfs for Veeam, and another volume with vmfs for dev/test. There's no need to put both in the same vmfs volume.

[Vitaliy S.]

Here is an existing topic that is worth looking through > Don't Store Backups on VMFS...But why not?