StoreOnce - replicated target automated import?

[dcolpitts]

Ok - this is something of a weird one... We've a pair of StoreOnce 4700s. One in HQ, one 15 miles away in a colo. We utilize StoreOnce replication on our VBR CIFS share to keep the two 4700s replicated (there is more than just VBR backups on these 4700s, so that is why we use the StoreOnce replication). At the colo, we have a single ESXi host, and it has a single 2008R2 VM with VBR (7.0.0.871) installed - I'll call this server COLO2K8 for reference. Because COLO2K8 is only ever going to be used for recovery purposes (basically in event the HQ is gone), we only have the single default C:\Backup repository that gets installed with VBR. Now I've already tested the fact that if I use Windows Explorer on COLO2K8 and navigate to my replicated target 4700 VBR share(\\192.168.100.2\VBRSHARE), I can manually import the .VIBs and .VBKs there and then restore them. The downside is importing these backups is a manual process, and it can take quite some time to import.

So I figured I should be able to script PowerShell and Import-VBRBackup to grab the newest backup every day and automatically import it. Here is where the issue comes. If I use UNC (i.e. Import-VBRBackup -Server $d -FileName "\\192.168.100.2\VBRShare\QMSTest\QMSTest2014-08-14T182419.vbk") I get "Path ["\\192.168.100.2\VBRShare\QMSTest\QMSTest2014-08-14T182419.vbk"] not found". If I map a drive to V:, and use it, I get the same thing. However, if copy the vbk to C:\ and use C:\, the import completes successfully. I'm assuming it failing to import due to credentials, but I'm 100% sure.

So then I was thinking, ok - we'll just make \\192.168.100.2\VBRShare a repository - but that won't work because it is flagged as readonly.

Anyone have any ideas?

dcc

[dcolpitts]

I think I may have answered my own question...

It appears that the Import-VBRBackup command relies on the VeeamTransportSvc.exe and the VeeamAgent.exe processes it spawns to import the backups, which according to Process Explorer runs as NT AUTHORITY\SYSTEM. Then from there in Process Explorer, I was able to grab the command lines that VeeamTransportSvc.exe uses to launch VeeamAgent.exe, and track down the log files for a manual import. In the logs, I found where the shared credentials were being passed to what I assume is the VeeamAgent.exe for \\192.168.100.2\VBRShare. Obviously, when running Import-VBRBackup from Powershell, there is no options to pass along credentials, so accessing UNC and mapped drives are both going to fail if NT AUTHORITY\SYSTEM doesn't have rights to them.

Armed with this information, and since we utilize Active Directory integration with our StoreOnce units, I simply granted the computer account for COLO2K8 and the user account Built-in\System read rights to the \\192.168.100.2\VBRSHARE share.

To verify that NT AUTHORITY\SYSTEM could now map a drive, I used PSEXEC to launch a command prompt as NT AUTHORITY\SYSTEM using psexec /s "cmd.exe". I verified that the command prompt was in fact running as NT AUTHORITY\SYSTEM by checking Process Explorer again, and then in the command prompt, I ran a simple NET USE * \\192.168.100.2\VBRShare, and the drive mapped without prompting me for credentials and I was able to view the contents using the dir command.

From there, it was just a matter of going to back to Powershell and running Import-VBRBackup -Server $VBRServer -FileName "\\192.168.100.2\VBRShare\QMSTest\QMSTest2014-08-14T182419.vbk" again, and it successfully imported this time.

Now it is just a matter of writing a short Powershell script to find the newest .VIB or .VBK in the folder and to import it at noon every day.

I also now suspect that granting COLO2K8 read rights may have been unnecessary, but I haven't tested that suspicion yet - I'll test that tomorrow.

dcc

[dcolpitts]

Gostev - just a thought / suggestion - but if you are going to allow import or file system access from PowerShell, it shouldn't be assume the user running the PowerShell has pass-through credentials to storage location or remote file system, nor should it be assumed that the underlying services will have pass-through credentials. There needs to be optional parameters to specify credentials to access the file system we are specifying for import or export, or whatever. This is a perfect example of that issue. Had I been able to specify a username / password for my storage in my PowerShell command, then I wouldn't have had issues.

In my case, I figured that since PowerShell was executing under my user permissions and that I could see the share and map a drive, the file system should pass through in the command, but it obviously didn't because of the default security on the StoreOnce shares.

Just my two cents here...

dcc

[dcolpitts]

I also note that Import-VBRBackup does not honor -WarningAction SilentlyContinue or -ErrorAction SilentlyContinue if you attempt to re-import the same file twice. It throws up a dialog box requiring the end user to click ok. I'm not sure how well a scheduled script / task is going to handle this.

dcc

[tsightler]

I think you should be able to add even a read-only repository although it might require a small hack, but then you could just run a rescan on the repo using Powershell. I've done this in the past but it's been quite a while so perhaps something has changed that keeps this from working. I'll try to spin up a couple of VSAs in my lab and give it a spin.

[veremin]

Now it is just a matter of writing a short Powershell script to find the newest .VIB or .VBK in the folder and to import it at noon every day.

The latest backup can be found via the following script:

Code: Select all

$LastVBK = Get-ChildItem "Path to repository" | where {$_.Extension -eq ".vib" -or $_.Extension -eq ".vbk"} | Sort-Object creationtime -Descending | select -First 1

Thanks.

[BrandonH]

Great information! I've budgeted to replace our three Drobo's with StoreOnce 4500's next year. I've been playing with VSA to get everything working in my head for the production system.

I'm just looking forward to having enough room to store more than 14 restore points!