Why can't I force the next step in a SureBackup job?

[kjstech]

I'm trying Surebackup jobs to test certain appliations and upgrade scenereos and needless to say it takes a very long time. If I do not give enough "power on time" for the virtual domain controller that starts up first, and I don't log into that DC and change it to DHCP from its original static IP... the Surebackup tests will fail and the whole session will be torn down, despite things actually working.

So to mitigate that I have to change the power on time for the first VM in the SureBackup job (a Server 2012 R2 Domain Controller) to 1800 seconds, which is a half hour. This is quite a while. In fact Everything should be reachable now 19 minutes in from initially kicking off the job, but I have to sit here and wait another 11 mintues until it runs some test scripts and then moves on to powering up the next machine.

I noticed in the Sure Backup job properties you can right click any of the machines in the list and the option of "Start" comes up in the menu but its greyed out. Isn't there a way to get this to move on a little faster?

The DC takes the longest because it boots up, and you can't log in right away (Says no login servers available for your request), but then it automatically reboots itself and then you can log in. Its pretty slow, average disk read latency on VeeamBackup_veeam.domain.com is 331.273 ms, maximum of 3463 minimum 0. But once logged in I have to go into network properties and change it to DHCP, as it will get an address from the Veeam_SureBackup_Lab_Proxy VM, and then since its a DC I specify 127.0.0.1 as the DNS, and in all subsequent machines in the SureBackup job I will specify the IP that the SureBackup Lab Proxy gave the DC as their DNS, which appears to be 10.0.0.1 oddly when the network masquerade address is 10.11.0.0/16.

[kjstech]

Actually everything seemed up and fine to me but the stinking SureBackup job just tore it down! It said OS did not boot in the allotted time! I can assure you it did and I was actually in and using it when it tore it down! So I just wasted a half hour of my time on this. How can we get these sure backup machines to just start up and run until I... IIIIIII ... I tear it down? I already have in the job "Keep the application group running after the job completes" but the dang thing tears it down anyway.

[kjstech]

Ugh, I just spent over an hour getting a DC up and running and finally SureBackup started the next machine in the list. Then sadly the dang Surebackup undid everything and tore it all down wasting all of that time because the second machine did not "boot" in time, ill-regardless the fact I was in the machine myself poking around.

I have to come up with another solution perhaps manually power up the surebackup lab proxy, and manually do instant vm recoveries with the network disconnected on these machines, then by hand connect them to the surebackup network in order to test an upgrade.

Surebackup suresucks.

[foggy]

Keith, what kind of storage do the VMs run from during SureBackup?

[nike284]

@foggy, I'm running into the same issue, I have the threshold set to 7200 seconds and it would still fail.
I already have a case open, but wanted to express that this is a very common issue.
Of course my dedup appliance is probably the main reason for all this slowness.

[foggy]

Yes, running SureBackup from dedupe storage is not among highly recommended approaches.

[Zew]

Surebackup Jobs have been the most painful thing or me to implement as well. multiple support calls on it.

They highly recommend a FAST vPower NFS datastore. which I'm gonna create a post to hopefull get some better idea on how I can improve my spin up times of a SBJ.

But I agree it be nice to tell the SBJ that the VM is indeed ready to spin up teh next VM in those situations where you have to manually up the allotted time but not sure exactly how much time it really needs.

[dyna]

Lots of problems with surebackup and VM's not powering on as well.

Yes from dedupped backup storage device so i can understand it's not perfect but the results differ so much that it can't be just the dedup backup storage.
For example i was just trying some things, first try the exchange server power on completes in 21 minutes, next run it fails after 1 hour. However the VM itself can be logged into fine using remote console from vmware. In fact in previous testings i noticed it increased the succes rate dramatically just by logging in to the VM. If all i did was log in into the VM using vmware remote console then fail % would drop down to 0 (or almost 0).

So yes i understand how storage can have an effect, but not that much. Snce it was midday the dedup backup storage was not used for anything else. So how can 1 run stat successfully in 21 minutes, but the next run fail in 1 hour? And why can i login and check services stats with 100% succes rate after 10 minutes?


SureBackup is still not Veeam worthy tbh.
Next to this, imo pretty big usability issue, there's also the issue that both application groups and linking it to a whole job don't offer enough flexibility so you may need to create strange setups (exclude option for linking, please). And let's not even talk about the SQL script
We use it, but don't really take it that serious. Surebackup jobs failed...oh well...must be surebackup that's burping again. Don't have time to check it today so i'll just assume it was surebackup that burped and not that it's a real issue...You get the picture.

[bstilts]

I agree, I'm running some older Windows NT VM's that SureBackup can't seem to verify that they have started and then they tear the whole job down before the second VM can power on. Very annoying when it's supposed to be an enterprise level backup verification tool. Supports solution is to get rid of the NT VM's, well that's all well and good, but when it's running an old financial application that we need to maintain for reference purposes because we couldn't import the data into our newer financial package, then that response doesn't fly. And any IP based verification solution should be able to do something as simple as a ping test to verify the system is online, even if the operating system is not supported any longer. Basically if VMware can run it as a VM, Veeam can back it up and it can communicate through TCP/IP, then SureBackup should be able to verify it's existance. This solution can't even get past the initial power on verification, so it never even gets to the ping test. Alternately why would you tear it down when we still need to verify that the rest of the VM's in the job are operational? In my opinion that makes this tool nothing more than a novelty.