Lab: back up and restore an App Service safely

Outcome

Create a training web app on a backup-supported plan, configure a custom backup target, take an on-demand backup, restore into a non-production destination, and prove that the marker content returned. You will deliberately choose an unsupported plan or unusable backup target, diagnose the constraint, and remove all resources.

Before you begin

Use a training subscription and a unique storage-account name. App Service backup/restore support is tier-dependent; confirm the currently selected plan supports the operation in the linked source before spending money. The current documentation lists Basic, Standard, Premium, and Isolated for backup/restore, with Basic limited to the production slot. Do not connect a production database.

az group create --name rg-azlearn-webbackup --location <azure-region>
az appservice plan create --name asp-azlearn-backup --resource-group rg-azlearn-webbackup --sku B1 --is-linux
az webapp create --name <unique-app-name> --resource-group rg-azlearn-webbackup --plan asp-azlearn-backup --runtime 'NODE:20-lts'
az storage account create --name <unique-storage-name> --resource-group rg-azlearn-webbackup --sku Standard_LRS

Do

1. Deploy a tiny marker page (for example, backup-marker-v1) with the portal Deployment Center or a ZIP deployment. Browse it and record the URL and marker.
2. In the web app’s Backups page, choose Configure custom backups. Select the training storage account and create a dedicated private container. Configure an on-demand backup first; only then set a schedule and retention appropriate to the exercise.
3. Start Backup now. Wait for success and record the backup timestamp and storage-container evidence. A custom backup uses a storage target; do not put its SAS or connection information in source control or a pipeline log.
4. Change the deployed marker to backup-marker-v2 and verify that the live app now shows v2.
5. Restore the successful backup to a new training app or slot if available. A restore can overwrite an existing target filesystem, so never aim the first restore at production. Browse the restore target and show backup-marker-v1.

Verify

Capture: selected plan SKU; backup configuration; successful job timestamp; v1 before change; v2 after change; and v1 at the restore target. Explain why an App Service backup is not an application recovery plan until a restore has actually been tested.

Break and fix

1. In a separate training resource group, choose a plan tier that does not expose the custom-backup capability. Record the portal/API constraint; do not try to bypass it. Delete the test plan.
2. Temporarily select or configure a storage target the app cannot use, then start a backup and inspect its job details. Restore a supported target/configuration and repeat until successful. Do not weaken storage access broadly merely to make the error disappear.
3. Explain why restoring over an existing app is riskier than restoring to a new app or slot. If a slot is available, use it for the restore and swap only after verification.

Scenario practice

1. Configure: A Basic-plan training app needs a restore drill. What backup/restore destination is permitted, and what changes when you need slot-based recovery?
2. Diagnose: A custom backup job fails immediately after storage networking changes. Which backup-target reachability and authorization evidence do you inspect before changing the web app?
3. Distinguish: Contrast platform automatic backups with custom backups and a database-native backup. Which one gives you a portable, testable recovery artifact for this lab?

Clean up

Delete the whole training group only after confirming no other exercise uses it:

az group delete --name rg-azlearn-webbackup --yes --no-wait

Sources and re-audit

• Back up and restore an App Service app, checked 2026-08-22.

Re-audit when plan support, custom-backup storage authentication, linked-database support, schedule limits, or restore behavior changes.

Related

App Service · App Service backup · Azure Backup · All labs