Backing up to esos host using veeam?

[Dan Swartzendruber]

So I use veeam to back up my vsphere host.  It has 3 different types of repository it can use: a windows server, a linux server or a CIFS/SMB network share.  In the linux case, it seems to use ssh to set up a netcat type connection so it can write backup files there.  What does this have to do with esos?  Well, if my vsphere datastore is on an srp fileio target (so as to use the linux page cache - is this the right way to go?  I have 32GB ram on the esos host, so I would like to use it lol), the target would be in /mnt/vdisks/vsphere, with the target itself being a file in that directory, correct?  So my point being, is there any reason I can't create a directory /mnt/vdisks/veeam (presumably putting that in /etc/fstab) and point the veeam backup config at that directory?

[Randy Schapel]

Dan:

  We are actually looking at Veeam here as well. So your plan is to install VM proxy which will then connect to the Linux repository via the Veeam "transport services". In your case the linux repository would be the ESOS box, which is also hosting your VMFS volumes for your ESX servers correct? This would be the same group that your backing up? 

As long as you be able to get transport services installed onto your ESOS server, I think what your saying would work. You need to keep in mind that one corrupted file system that space gets messed up and you could lose both your primary and backups (making a guess that your not using separate hardware for /mnt/vdisks/vsphere and /mnt/vdisks/veeam you have hardware to worry about as well) . 

I don't know the amount of space your dealing with or if you have another choice, but I would avoid having all those eggs in one basket (if possible, I know resources are limited). Additionally if that is not an option, I am not sure your gaining much over just using VM proxy and mounting a direct storage from the SAN on it (you could even cut VMFS out of the equation). As a matter of fact it would be better "performance" since at the very least you would be pushing it through one less server transaction to get to a disk. Depending how you set things up  (and your architecture) it could one less push through the network as well.  Is there a reason you ruled this out? 

--Randy

 

  

On Mon, Mar 30, 2015 at 11:15 AM, Dan Swartzendruber <dsw...@druber.com> wrote:

So I use veeam to back up my vsphere host.  It has 3 different types of repository it can use: a windows server, a linux server or a CIFS/SMB network share.  In the linux case, it seems to use ssh to set up a netcat type connection so it can write backup files there.  What does this have to do with esos?  Well, if my vsphere datastore is on an srp fileio target (so as to use the linux page cache - is this the right way to go?  I have 32GB ram on the esos host, so I would like to use it lol), the target would be in /mnt/vdisks/vsphere, with the target itself being a file in that directory, correct?  So my point being, is there any reason I can't create a directory /mnt/vdisks/veeam (presumably putting that in /etc/fstab) and point the veeam backup config at that directory?

--
You received this message because you are subscribed to the Google Groups "esos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to esos-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dan Swartzendruber]

Wow, lots of meat here, thanks!  This is not for the proxy (that is on a windows server 2008r2 VM), but the backup repository.  If I go with a ZFS SAN, I have to use a CIFS share on the ZFS SAN as the backup repository - if I go with a Linux solution (esos?), it can be a simple pathname.  Like I said, I *think* it just does ssh to the Linux backup repository, and pushes over a command to run netcat or somesuch (I can't believe they are doing the backup through ssh - the encryption overhead would kill throughput!)  Correct, in theory I have a single point of failure, but I have veeam configured to duplicate the daily backups to another backup repository (which at the moment *is* a linux VM).  As far as your last point, I think you are alluding to 'Direct SAN Access?'  If so, I think I can't use that here (on the proxy), since from what I can tell, veeam configures the windows proxy to access the iSCSI target directly, boosting performance by cutting out the hypervisor I/O stack.)  In this case though, the SAN storage is exported via SRP, which (as far as I can tell), the Windows VM proxy has no way to see.  I was hoping that I could have the IB/SRP target access the same underlying storage as an iSCSI target, which would allow me to do this, but I'm not sure if that is possible.  It certainly doesn't seem to be from the GUI, as I get 'no device' or 'in use' or whatever, if I try to do this.  I suspect the IB/SRP target and iSCSI target would step on each other?  It surely doesn't seem to work for writes, although in theory it could still work for the veeam iSCSI proxy since that only accesses the target for read.

[Randy Schapel]

Dan:

  I am not IB expert (or even novice for that matter) so I can't say what is and isn't possible on direct mappings for your VM Veeam proxy (Windows server 2002R2). But what about just adding a disk to your VM that points to a different VMFS volume?  This should show up as a "local" disk to your VM Veeam proxy right? You could create this extra disk on it's own VMFS volume (keeping is separate). This would be slightly more intertwined with vmware infrastructure than installing the linux repository option on ESOS server, but since it sounds like your going to be replicating to another setup at some point so you'll get added resiliency there. Plus, your not mixing SAN server (OS side) up directly in your Veeam backup scheme. There would be additional overhead (hyper visor I/O stack en all), but maybe worth it for the simpler setup? 

I would be interested to hear what ever direction you go. 

--Randy

On Mon, Mar 30, 2015 at 2:59 PM, Dan Swartzendruber <dsw...@druber.com> wrote:

Wow, lots of meat here, thanks!  This is not for the proxy (that is on a windows server 2008r2 VM), but the backup repository.  If I go with a ZFS SAN, I have to use a CIFS share on the ZFS SAN as the backup repository - if I go with a Linux solution (esos?), it can be a simple pathname.  Like I said, I *think* it just does ssh to the Linux backup repository, and pushes over a command to run netcat or somesuch (I can't believe they are doing the backup through ssh - the encryption overhead would kill throughput!)  Correct, in theory I have a single point of failure, but I have veeam configured to duplicate the daily backups to another backup repository (which at the moment *is* a linux VM).  As far as your last point, I think you are alluding to 'Direct SAN Access?'  If so, I think I can't use that here (on the proxy), since from what I can tell, veeam configures the windows proxy to access the iSCSI target directly, boosting performance by cutting out the hypervisor I/O stack.)  In this case though, the SAN storage is exported via SRP, which (as far as I can tell), the Windows VM proxy has no way to see.  I was hoping that I could have the IB/SRP target access the same underlying storage as an iSCSI target, which would allow me to do this, but I'm not sure if that is possible.  It certainly doesn't seem to be from the GUI, as I get 'no device' or 'in use' or whatever, if I try to do this.  I suspect the IB/SRP target and iSCSI target would step on each other?  It surely doesn't seem to work for writes, although in theory it could still work for the veeam iSCSI proxy since that only accesses the target for read.

--

[Dan Swartzendruber]

Hmmm, so I create an N GB virtual disk in vsphere and attach it to the existing win 2008r2 VM already being used as a backup proxy, and tell veeam 'hey, use V:\veeam (or wherever) to write backup files?  That sounds interesting and would eliminate some overhead, I think.  Let me give that a try and get back to you...

[Dan Swartzendruber]

Seems to be working just fine.  Created a 512GB file on that LUN and veeam is backing up to v:\

[Dan Swartzendruber]

The basic idea works just fine, but I can't use it on the VM I tested it on.  This should have occurred to me at the time, but this is a utility VM which is backed up as a matter of course.  Things get *interesting* when veeam is backing up a VM to storage on that VM :)