I configured Windows Azure Backup on my VM hosted on Azure. I did manage to create and upload a certificate following this tutorial and this tutorial.
I downloaded the server agent to the VM and configured it, I then managed to perform a manual backup and it worked fine.
However I scheduled it to run every day at 3am using the wizard provided and it's not running. I check every day, and the last backup that is listed is the one I did manually. The dashboard in the Backup Server Agent shows it's scheduled, but it's not running.
I tried leaving the agent open overnight, and it didn't help.
Any insight on the situation will be helpful.
Thanks,
After checking my VM's event log, I figured out that the backup wasn't running as expected due to limited space in the HD. After I cleared some space it started running as expected.
Related
Rougly what im trying to do is:
Start VM automaticly(already doing this with Azure Automation)
Have the VM run an application(it already auto runs on startup) This is where the problem is, since the app runs fine when the VM is started manually with RDP, but is not run when the VM is started automaticly with Azure automation.
Stop VM (already doing this with Azure Automation)
All this must happend automaticly in the cloud so i dont have to do it manually trough the RDP sever application
i have an Azure VM that auto runs a console application on startup, this app do some work and then upload some files to my Azure storage. This console application needs to be run once a day, so im thinking that ill use the Azure Automation Account to auto start/stop it once every day, which i did and its working fine, atleast i can see the VM change status on the Azure portal at the specified times, however the files are not being pushed from my console application to my Azure storage when.
First question question is, do the Automation Account auto start of VM just make the VM avalible for use, and doesnt infact turn the OS on?
This would explain why the console application which should run auto on startup arent being run and therefor not pushing files.
Second question. If this is the case, how do i run my Azure VM without running the RDP manually aka somewhere in the cloud?
Normally it wouldnt be that big an issue for me to run the RDP myself once a day, but if i could automate it that would be ideal. Also when im traveling its not allways possible for me to get good enough internet access, and the VMs console application file pushing is vital for a website and a Xamarin Android app im managing, so its not something i can allow to "skip" sometimes whenever inconvenient.
There is so much wrong in this question that I don't even know where to start.
First of all, if you need to run something once a day, why not use Azure Automation, Azure Functions, etc?
Second, you cannot turn on VM but not turn on OS. how do you even suppose this might happen.
My thoughts - you configured your app to run on user login, not on startup, or the scheduled task doesn't run when the user is not logged in.
We are evaluating Azure ASR for cloud Backup and Site Recovery.
Started a month ago with Backup services to backup files, folders and SQL servers and everything worked fine, MABS is installed in server A.
We have also added a physical server to Site recovery, installing the Azure site recovery on the same server A. Since then, every dashboard referring to Backup information has not been updated though its clear that GRS Storage is used for backups.
Tried to uninstall/re-install MABS without any success, any ideas? there are no errors in the MABS MMC console.
It is not recommended to install backup (MABS) and site recovery on the same machine since both Services are using similar tasks there will be lot of conflicts.
When I try to register the Azure Backup Agent from my Windows 7 machine, the following error appear:
The Microsoft Azure Recovery Services Agent cannot connect to the OBEngine service. (ID: 100052)
Verify that the OBEngine service is present in the Services Control Panel and that the port 6049 is available.
I've checked that the service is running and the port is available.
Any suggestions?
I run into this error many times when my DPM online recovery points attempt to run. I believe they fail because other backup jobs (like disk-to-disk jobs) are still running on the same protected data sources. So the online recovery points start while another backup is already running and it fails. This causes the OBENGINE service to falter and get stuck. I have had good luck with spreading out my backup job schedules within my protection groups. For instance, my disk-to-disk backups run in the latePM/earlyAM. My Online Recovery Points run during the work day, lateAM/earlyPM.
If I find some online backups failed with error:
The Microsoft Azure Recovery Services Agent cannot connect to the OBEngine service. (ID: 100052)
...I first look to see if any backups are running. If not, I restart the OBENGINE service. When you look in services, this is the "Microsoft Azure Recovery Services Agent" which is running obengine.exe. Here is a good command to restart this service, which you can run on your DPM server in a command prompt or in PowerShell:
net stop obengine && net stop obengine
After restarting the service, restart the online recovery point jobs that failed. However it is likely your jobs may fail again tomorrow, so get those schedules spread out.
we had a strange issue a couple of times now with our Azure service.
We have a cloud service installed that has a web application running on it.
The service was created sometime around beginning of december and he first deployment was done that time as well. After that we did multiple deployments to the cloud service, but (it happens a couple of times now) sometime the Azure decides to roll back the deployment to initial one - the one that was made 2 months ago. This happened this midnight once again and we see that the files creation date on the "restored" or "rolled back" instance is 12/5/2013, which seems to be the date when we did an initial deployment.
A question:
1) Why does that happen?
2) How can we determine what caused this rollback?
3) How can we prevent the rollback?
or
4) How can we make a "snapshot" of the cloud service so when the Rollback happens, it actually rolls back to the latest stable image?
Thanks,
Denis
How are you doing "After that we did multiple deployments to the cloud service"? Are you doing this via WebDeploy or via RDP to the Azure VM?
PaaS cloud service VMs are stateless. The code that is running your website will frequently be rebuilt from the original .cspkg that was uploaded. See http://blogs.msdn.com/b/kwill/archive/2012/10/05/windows-azure-disk-partition-preservation.aspx for a bit more info.
If you want to make changes to your webrole then you need to upload a new cspkg. See http://msdn.microsoft.com/en-us/library/windowsazure/hh472157.aspx for more information.
If you are deploying via WebDeploy you should know that these changes are only intended for development/testing cycle and that the changes are only temporary. See http://msdn.microsoft.com/en-us/library/windowsazure/ff683672.aspx for more information, in particular the "For development and testing purposes only" section.
I have a question about Remote Desktop deployment on Azure Cloud Application.
First of all I published my app via visual studio.Everything is working.
Yesterday I connected with remote desktop to my azure app and changed some attributes in my web.config files.
First thing : My cloud app is getting so slowly so I think IIS restart etc. but I don't know why my site is coming slowly ?
Second thing : Today when I enter to my app , I can't see my changes and when I check it via remote desktop all my changed things are roll back. Why ?
Do I have to all my deployment via Visual Studio ?
How is staying my deployment in Azure machines ? This machine is sometimes changing or never change when I delete it ?
Thanks,
This is not the expected way to change the settings. Azure is free to relocate your instance to another VM or restart it in-place and erase all your local changes.
So if you want to do some permanent changes you have to do them locally, build the service package and deploy the new package to Azure. This way Azure will have an updated package and your changes will persist.
If you want to change something frequently you have to use the <ConfigurationSettings> node of the service configuration. Your code will have to query the setting and react accordingly. If you want some activity triggered when the service configuration is changed your code has to handle the RoleEnvironment.Changing event.
You cannot make changes in the VM directly, because these changes are not persisted (as you have already noticed). The VM can be recycled and restored at any moment. So you have to make changes by applying them locally and redeploy the site.