Web-App benötigt ein Backup? App-Service-Sicherung konfigurieren

CloudTrips benötigt eine wiederherstellbare Kopie der bereitgestellten Web-App-Dateien und der App-Service-Konfiguration. Ein benutzerdefiniertes App-Service-Backup schreibt ein ZIP-Archiv und ein XML-Manifest in einen Azure-Blob-Storage-Container. Es ist von der Quellcodeverwaltung getrennt und ergänzt eine wiederholbare Bereitstellungspipeline, ersetzt sie aber nicht.

Dieser Trip ist eigenständig und führt einen echten Wiederherstellungstest durch. Die Wiederherstellung über eine bestehende App stoppt sie vorübergehend und ersetzt ihre Dateien. Verwende daher nur die isolierten Laborressourcen.

Erstelle die Web-App

Suche nach App Services, wähle Create > Web App und trage ein:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-backup-test-weu
Name: app-cloudtrips-backup-dmytro-test-weu
Publish: Code
Runtime stack: Node 24 LTS
Operating System: Linux
Region: West Europe
Linux Plan: Create new
Plan name: asp-cloudtrips-backup-test-weu
Pricing plan: Basic B1
Zone redundancy: Disabled

Der Web-App-Name muss global eindeutig sein. Basic B1 unterstützt benutzerdefinierte App-Service-Backups und bleibt bis zur Löschung kostenpflichtig. Wähle Review + create > Create.

Erstelle den Backup-Speicher

Erstelle ein Storage account:

Resource group: rg-cloudtrips-backup-test-weu
Storage account name: stctbackupdmytro01
Region: West Europe
Primary service: Azure Blob Storage
Performance: Standard
Redundancy: Locally-redundant storage (LRS)
Public network access: Enabled

Speicherkontonamen sind global eindeutig, kleingeschrieben und enthalten keine Bindestriche. Ist der Name nicht verfügbar, ergänze Ziffern und verwende den resultierenden Namen im gesamten Trip. Konfiguriere auf der Registerkarte Security:

Enable storage account key access: Enabled
Allow Blob anonymous access: Disabled

Das benutzerdefinierte App-Service-Backup verwendet eine vom Speicherkontoschlüssel abgeleitete SAS und schlägt bei deaktiviertem Schlüsselzugriff fehl. Deaktivierter anonymer Blobzugriff hält den Backupcontainer weiterhin privat.

Öffne Data storage > Containers, wähle + Container und erstelle:

Name: appservice-backups
Anonymous access level: Private (no anonymous access)

Öffentlicher Netzwerkzugriff ermöglicht dem App-Service-Backup-Prozess den Zugriff auf den Speicherendpunkt; dadurch wird der private Container nicht anonym. Benutzerdefinierte Sicherung und Wiederherstellung verwenden SAS-basierte Autorisierung. Verwaltete Identitäten werden für diesen Vorgang nicht unterstützt.

Stelle Version 1 bereit

Erstelle einen lokalen Ordner cloudtrips-backup-app mit dieser package.json:

mkdir -p cloudtrips-backup-app
cd cloudtrips-backup-app

{
  "name": "cloudtrips-backup-app",
  "version": "1.0.0",
  "scripts": {
    "start": "node server.js"
  }
}

Erstelle server.js:

const http = require('http');
const port = process.env.PORT || 8080;

http.createServer((request, response) => {
  response.writeHead(200, { 'Content-Type': 'text/html; charset=utf-8' });
  response.end('<h1>CloudTrips Backup</h1><p>Version 1 - protected</p>');
}).listen(port);

Stelle Version 1 aus diesem Ordner bereit:

zip cloudtrips-backup-v1.zip package.json server.js

az webapp deploy \
  --resource-group rg-cloudtrips-backup-test-weu \
  --name app-cloudtrips-backup-dmytro-test-weu \
  --src-path cloudtrips-backup-v1.zip \
  --type zip

Kopiere die generierte Default domain aus der App-Übersicht und bestätige, dass sie Version 1 - protected anzeigt.

Konfiguriere und starte das Backup

Öffne die Web-App und wähle Backups > Configure custom backups:

Storage account: stctbackupdmytro01
Container: appservice-backups
Backup schedule: Enabled
Frequency: Every 1 day
Retention: 7 days
Keep at least one backup: Enabled
Database backup: None

Wähle Configure und anschließend Backup Now. Ein geplantes Backup schützt zukünftige Änderungen; Backup Now liefert einen bekannten Wiederherstellungspunkt für diesen Test.

Warte, bis der Backupstatus Succeeded lautet. Fahre nicht mit einem fehlgeschlagenen oder laufenden Backup fort. Öffne den Speichercontainer und bestätige, dass Azure eine ZIP-Datei mit den Sicherungsdaten und ein XML-Manifest erstellt hat. Verändere keine der Dateien; Änderungen können das Backup unbrauchbar machen.

Erzeuge eine wiederherzustellende Änderung

Ändere die letzte Zeile in server.js zu:

  response.end('<h1>CloudTrips Backup</h1><p>Version 2 - restore test</p>');

Erstelle ein neues ZIP und stelle es bereit:

zip cloudtrips-backup-v2.zip package.json server.js

az webapp deploy \
  --resource-group rg-cloudtrips-backup-test-weu \
  --name app-cloudtrips-backup-dmytro-test-weu \
  --src-path cloudtrips-backup-v2.zip \
  --type zip

Aktualisiere die Standarddomäne und bestätige Version 2 - restore test.

Stelle Version 1 wieder her

Kehre zu Backups zurück, wähle das erfolgreiche On-Demand-Backup und dann Restore. Wähle die vorhandene Labor-App als Ziel und bestätige die Überschreibwarnung.

Die Wiederherstellung stoppt die App vorübergehend und ersetzt aktuelle Dateiinhalte sowie gesicherte Konfiguration. Warte auf den erfolgreichen Abschluss und aktualisiere anschließend die Standarddomäne. Sie sollte wieder Folgendes anzeigen:

Version 1 - protected

Das Backup enthält App-Service-Dateien und -Konfiguration, schützt aber nicht automatisch externe Dienste oder eingebundenen benutzerdefinierten Speicher. Datenbanken, Speicherkonten, Key Vault und andere Abhängigkeiten benötigen eigene Wiederherstellungskonzepte.

Aufräumen

Lösche die isolierte Ressourcengruppe, um B1-Gebühren zu beenden und die Test-Backups zu entfernen:

az group delete --name rg-cloudtrips-backup-test-weu --yes

Bestätige, dass az group exists --name rg-cloudtrips-backup-test-weu den Wert false zurückgibt.