When I am trying to create a backup of Sharepoint within the Admin Console, the backup is never created. It shows that it is running, but then I never have an actual backup file to restore to another server.
One of the services continually stops and restarts when the "backup process" is running.
Was expecting to have a backup file that I could then move to a different server to have as a test environment.
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.
I have 2 web applications in azure on a Standard App Service Plan (S1 Standard).
After I finish a scheduled backup configuration, it returns to the backup blade and show the following message:
"Backup and Restore feature requires your App Service plan to be Standard or higher. Click here to upgrade your App Service plan and access this feature."
Also all the backup options are grey out.
But I have a standard service plan already...
Is there other requirement that I'm missing?
Sometimes if I keep refreshing I can access the backup configuration again, but when I try to configure the backup it never finishes loading the backup options (Storage account/Schedule/Database).
Is there a problem with the backup system?
I just created a Azure Web App in South Central US location and tested its backup feature. It worked fine on my side.
Is there other requirement that I'm missing?
No, what you did is right. The issue maybe a temporary problem of Azure backup service or caused by the cache of your browser. Please clear the cache or history of your browser and try your steps again.
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.
My Scenario is very simple
A website running in azure which is the host of the webjob (the webjob will run under the context of this website).
A webjob, which is a console based application, scheduled to run every 5 minutes. Printing just a log message using COnsole.Writeline
Now, if i stop the website and go and check the execution logs of the webjob, it still gets executed every 5 minutes.
So when we say webjob runs in the same context of the website, what it actually means?
I believe the "context" here means that the WebSite and WebJob run in the same environment, with access to the same files. For example, you can prepare data for the WebSite in the WebJob. Conversely, you can save data in the WebSite scripts to be later batch-processed by the WebJob. You can also manage WebJobs the same way as the WebSite, they are all accessible using the same FTP(S) account.
If you look at the kudu documentation, it says :
Process model
The Kudu service site runs in the same sandbox as the site. By default, it runs in the different process as the site.
The only thing that really 'connects' the Kudu site to the real site is the file system, and that works regardless of what process or machine they each run on.
So your webjob run under the same environment but used a different process. It shares settings, files but if your website is turn off your web jo will continue on running.
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.