Bug in Powershell commandlets?

[htwnrva]

Originally I was chaining a group of backup jobs using the built in "Post-job activity" function in 4.1.1. This worked great for backups however when I had to "retry" a job in the morning it would retry the backup job and then it would continue down the chain of backups causing duplicate backups. So I thought I would be smart and start each backup chain with a powershell script and task scheduler. This works great but I have run into a bug that I can't figure out.

If I run the powershell script below from the powershell console in Windows 2008 R2; it works as expected and each job does an incremental backup. I can verify that because it creates a .vrb file and the first 3 VMs in this job take < 10 minutes for each backup.

StartVeeam.ps1
#Add the Veeam Commandlets
Add-PSSnapin VeeamPSSnapin
Get-PSSnapin

#Run Development Backup Path 1
Start-VBRJob DEV_CORPMSG
Start-VBRJob DEV_DBA
Start-VBRJob DEV_BAS
Start-VBRJob DEV_ITSEC
Start-VBRJob DEV_ENT

Now - If I set a scheduled task to run the same powershell script using the settings below - Veeam creates a .vrb file but each VM takes approximately 45-60 minutes each to run. Coincidently this is almost exactly how long a "full" backup of each of these three VMs takes. So it appears that something in the scheduled task running of this script is causing veeam to do a "full" backup rather than an incremental.

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
<RegistrationInfo>
<Date>2010-03-26T14:04:32.8911544</Date>
<Author></Author>
</RegistrationInfo>
<Triggers>
<CalendarTrigger>
<StartBoundary>2010-03-26T16:00:00</StartBoundary>
<Enabled>true</Enabled>
<ScheduleByDay>
<DaysInterval>1</DaysInterval>
</ScheduleByDay>
</CalendarTrigger>
</Triggers>
<Principals>
<Principal id="Author">
<UserId></UserId>
<LogonType>Password</LogonType>
<RunLevel>HighestAvailable</RunLevel>
</Principal>
</Principals>
<Settings>
<MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
<DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
<AllowHardTerminate>true</AllowHardTerminate>
<StartWhenAvailable>false</StartWhenAvailable>
<RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
<IdleSettings>
<StopOnIdleEnd>true</StopOnIdleEnd>
<RestartOnIdle>false</RestartOnIdle>
</IdleSettings>
<AllowStartOnDemand>true</AllowStartOnDemand>
<Enabled>false</Enabled>
<Hidden>false</Hidden>
<RunOnlyIfIdle>false</RunOnlyIfIdle>
<WakeToRun>false</WakeToRun>
<ExecutionTimeLimit>P1D</ExecutionTimeLimit>
<Priority>7</Priority>
</Settings>
<Actions Context="Author">
<Exec>
<Command>C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe</Command>
<Arguments>d:\PowerShellScripts\StartDevPath1</Arguments>
</Exec>
</Actions>
</Task>

I only noticed this because since moving to the powershell starts my daily backup window has been as big as my "full" backup window. Also to note that I am getting daily .vrbs that are incremental-sizes, it's just taking "full" backup times to get them. Any Ideas?

[Gostev]

Hmm, no idea what could be causing this, I guess we need to try to reproduce this.
So you actually see start/finish time difference increased in the job's session report?
Do you use the same (your) user account in this task?

Can you try starting job with PowerShell script launched by Task Scheduler, but using command line from the last step of the wizard instead of Start-VBRJob cmdlet, and see if the issue persists?

[htwnrva]

Backups are going right now but tomorrow I will post actual start/finish times on the selected configs. I'm not following on what you mean by starting the job without the cmdlet.

[Gostev]

I mean using the command you used for
chaining a group of backup jobs using the built in "Post-job activity" function

[htwnrva]

Oh OK - I follow you now- I will try that when I get in this morning.

Thanks,

[htwnrva]

What would be the best to implement this from a powershell script? I've tried using the Start-Process but it runs them all synchronously rather than waiting for one to finish before going on to the next?

[Gostev]

One job to run should be enough for this test... just to see it the job runs slower or normally when launched this way.