You don't restart Managed Instance. The beauty of PaaS is that the cloud service provider ensures that you get a certain uptime SLA-- 99.99% in this case.
The service is abstracted away. Microsoft will ensure that the service is "always" up and running. They handle patching and maintenance on the OS and the instance (and necessary restarts that go along with those things).
If you need to stop, scale, or make other changes to the instance, you'd do that from the Azure portal (either the web GUI or PowerShell).
Figured out the solution:
Go to the resource group you want to create the managed instance in > Policies > Assignments > Allowed resource types (with the scope subscription/resourcegroupname) parameters > then from the allowed resource types dropdown select Microsoft.Sql.managedInstances
Sign out and into your account, then managed instance will deploy.
When I got the 'Validate Deployment - 'deny' Policy action' error I went to the Activity log, clicked the Validate Deployment error dropown, clicked the 'deny' Policy action, then looked at the JSON tab - if I looked sequntially to see where the error originated I found this section
"category": {
"value": "Policy",
"localizedValue": "Policy"
},
"eventTimestamp": "2019-10-30T13:04:54.8516173Z",
"id": "/subscriptions/XXXXXXX/resourceGroups/XXXXXXXXXXXXX/providers/Microsoft.Sql/managedInstances/minamehere/events/77999a0f-d551-45e0-9b3b-1156b246b50d/ticks/637080374948516173",
"resourceId": "/subscriptions/XXXXXXXXX/resourceGroups/XXXXXXX/providers/Microsoft.Sql/managedInstances/minamehere",
"status": {
"value": "Failed",
"localizedValue": "Failed"
Which is what led me to policies and allowed me to troubleshoot and fix the issue - somewhere I knew I needed to add 'Microsoft.Sql/managedInstances' to the Policy category, which fits with the deny policy error I was experiencing.
Best Answer
I doubt that the "compress" setting affects the managed backups either way. But there is no way to check as you don't have direct access to it. I have caught the system taking backups before, the commands show using sp_whoisactive, but can't say that I've ever looked at the full command string before. I will try and catch one of mine at it and update my answer if I can.
As for how managed backups work. The management system periodically takes full and log backups according to it's own schedule. There are some events that seem to spark a full backup to be taken that we have observed. Creating/Restoring a database, failing between failover group nodes and when the service restarts (probably Azure balancing it's internal workload).
These backups are stored in a hidden storage account and can only be accessed through powershell. Cross-subscription restores are not possible through powershell using managed backups.
You can additionally take COPY_ONLY backups to URL and then restore from there. But the backups can only be restored onto another managed instance (so no restore to on-prem of any version). However, if you have enabled TDE with Azure managed key rotation, this option is locked out for you. Enabling TDE is the default for databases created through CREATE DATABASE, although databases restored (as in restored from on-prem) carry their TDE setting with them.