CIFS target at remote branch on private backup network

[ashleyw]

Hi,

Our environment consist of different sites. Each site has it's own VMware 5i farm with it's own private network connecting to a localised CIFS backup target on a network private to that farm. The remote locations are centrally managed from a single vCentre instance (each site being a different datacentre).

The Veeam v6 architecture is great as it allows us to establish a proxy at each of the remote branches and to centrally manage these from a single Veeam console.

The problem we have is that it appears the console needs to be able to see the CIFS paths as well as the proxy. Because the backup target at the remote branch is on a private backup network at the remote branch, there is no network connectivity between the centralised Veeam console and the remote backup target - so therefore we can't specify the remote CIFS location.

Right now the only solution I can see is to present the backup target at the branches as ISCSI or NFS store directly to the remote ESX5i hosts and to use that as a storage location - but we don't want to do that as we want to prevent VMFS abstraction of backup files (from a recovery/performance/managability viewpoint).

It would be great if the checking of the CIFS URLs could be delegated to which ever proxy(s) is going to handle the request - thereby preventing the need for the console to see the remote CIFS target.

Any ideas on how we get around this issue?

cheers
Ashley

[Gostev]

Hi Ashley, interesting scenario. I see no workaround off the top of my head. I will discuss this with devs tomorrow. Thanks!

[tsightler]

*** Warning -- Suggestion below is a completely unsupported hack intended to show only that I am crazy ***

Many people believe that there is no way to use a mapped drive with a service because mapped drives are created only during interactive logins. However, it is fairly trivial to create a statically mapped drive letter to a CIFS share that can be accessed by services. You will need "psexec" by Mark Russinovich, which you can get as part of PSTools download from http://technet.microsoft.com/en-us/sysi ... s/bb897553. After you get this tool follow the following procedure:

1. Open a cmd.exe prompt (Must be elevated/run as administrator)

2. Run the command "psexec -i -s cmd.exe". This will create an "interactive" login as the "system" account.

3. Create the persistent mapped drive with a command like: "net use V: \servername\sharedfolder password /persistent:yes /user:domain\user"

The V: drive will now be visible to all users, although it may show in Explorer as "disconnected" it may give an "access denied" error when attempting to access it as an interactive user. However, the V: drive will be fully available to services that run as the "system" account, including the Veeam repository service. You can then add the repository as a "standard" local drive, not a CIFS share. You may need to create a script to remap the drive letter on startup and schedule it via Task Manager to run on startup.

Once again a hack, but I have tested this hack, and already have one customer that has a very similar situation as you describe that is using this in their environment.

[ashleyw]

thanks, but I'm a little confused.
The issue that I have is that the console VM has no access to the private backup network out at the branch.
For example the CIFS target out at the branch A has a private IP of 10.0.0.66. The proxy out at the branch A (front end IP of 1.2.3.4, private IP of 10.0.0.77) is able to see that private CIFS target because it has a nic physically connected to the private backup network.

The console is sitting at branch HQ with a front end IP of 4.5.6.7 but there is no network route to the CIFS target at branch A on 1.2.3.4

I don't see how a drive letter would help here as it still would not be visible form the console VM would it?

We did think of mapping via a static hosts entry and create a fake share on the console with a static host name of brancha-storage.abc.com mapping to 127.0.0.1 and on the proxy at branchA have the same share but with a static hostsname of brancha-storage.abc.com mapping to 1.2.3.4 but we can't get this to work.

Maybe I'm missing something here but I can't see how we can reliably access remote private CIFS storage?

If we used the powershell APIs to manually create the backup jobs pointing to the correct remote CIFS target - would that work or does the console actually attempt to interact with the remote CIFS storage at other times than initial job configuration?

[tsightler]

With a mapped drive letter you do not need to add the repository as CIFS, it just looks like a local drive on the repository, thus the console does not need access to the CIFS share. The repository is manually mapped to the CIFS share via the local network, while the console simply sees the share as a local drive on the repository. You simply add the repository not as CIFS, but as a Windows system, and the drive will show up in the list. With this configuration, as long as the repository can see the CIFS share, and the console can see the repository, you're all set. The console will no longer need direct access to the CIFS share. Isn't that the issue and what you were asking for at the start (allow the CIFS share to be access by the repository, not the console)?

[Gostev]

Makes sense.

[ashleyw]

thanks guys, I'll run some tests later this morning.
Gostev, it would be be great if Veeam could come up with an out-the-box solution for this type of common scenario.