Azure Backupstrategien: Web Apps

12. Juli 2016
In meinem letzten Blogpost ging es um Backupstrategien von Azure Virtual Machines. Heute schauen wir uns die Azure Web Apps an.
 
Prinzipiell möchte ich dazu auf drei Dinge eingehen, die damit im Zusammenhang stehen und unterschiedliche Problemszenarien bedienen: Deployment Source, Scheduled Backup und Deployment Slots.
 

Deployment Source

Hinter dieser Option steht die Frage:
 
„Mein neuestes Deployment enthält kritische Bugs, allerdings habe ich (noch) kein Backup konfiguriert. Kann ich trotzdem auf einen älteren Stand zurückrollen?“
 
Oder:
„Kann ich auf einen älteren Releasestand zurückrollen, ohne auf meinem lokalen Entwicklerrechner Änderungen vornehmen zu müssen?“
 
Schon zu Zeiten des „alten“ Portals gab und gibt es die Möglichkeit, Web Apps auf einen früheren Deployment-Stand zurückzurollen. Es ist dabei egal welche Deployment-Variante ihr gewählt habt: Jedes (erfolgreiche) Deployment kann mit einem Klick re-deployed werden – diese Möglichkeit ist bei der Erstellung einer Web App bereits inbegriffen, d.h. ihr müsst dazu nichts konfigurieren.
 
 

Scheduled Backup

Deployment Source bietet also die Möglichkeit, auf den Stand eines bestimmten früheren Deployments zurückzurollen, aber:
„Was tue ich, wenn ich auf den Stand zwischen zwei Deployments zurückgehen will?“
 
Oder:
„Was tue ich, wenn ich nicht meine bestehende Web App ändern will, sondern das Backup auf einer zweiten  Web App einspielen möchte?“
 
Hierfür bietet Azure seit nicht allzu langer Zeit ein automatisiertes Backup an:
  
 
Mit diesem Tool könnt ihr ein automatisiertes Backup nach einem bestimmten Zeitplan einrichten. Dazu benötigt ihr lediglich einen Storage Account. Komfortablerweise kann hier parallel auch eine Datenbank angegeben werden, welche eure Web App verwendet: Diese wird ebenfalls gesichert und bei einem „Restore“ wird ebenfalls die Datenbank wiederhergestellt.
 
Es besteht zudem die Möglichkeit, dass das Backup nicht auf die ursprüngliche Web App aufgespielt wird, sondern ihr habt auch die Möglichkeit das Backup auf eine völlig andere Web App (in der selben Subscription) einzuspielen. Dazu miss einfach die „Restore Destination“ geändert werden:
 
 

Deployment Slots

Ein etwas anderes Problem wird durch Deployment Slots gelöst, und zwar:
 
„Der Re-Deploymentvorgang und der Restorevorgang dauern mir zu lange – meine Web App muss hochverfügbar sein und stets den aktuellsten, lauffähigen Stand meiner App anzeigen“
 
Diese Funktion hat zwar nur am Rande etwas mit Backups zu tun, aber wenn man sie kennt, kann sie viele Backups überflüssig machen.
Ein Deployment Slot ist ein separate, eigenständige Web App, welcher über den gleichnamigen Menüpunkt in einer Web App erstellt werden kann. 
 
 
Es wird empfohlen, dass jedes neue Deployment auf diesem separaten Slot erfolgt. Damit verfügt ihr über eine voll funktionsfähige Web App, die ihr aber zunächst selbst testen könnt, bevor ihr euren Kunden Zugriff gewährt.
 
Waren das Deployment und eure Tests erfolgreich, so genügt ein Klick auf den „Swap“-Button um eure „Slot“-App und eure „production“-App auszutauschen.
Technisch gesehen wird beim Tausch lediglich dafür gesorgt, dass sämtlicher Datenverkehr jeweils auf die andere App umgeleitet wird.
 
In einem späteren Blogbeitrag werde ich noch detaillierter auf die Möglichkeiten von Deployment Slots eingehen.
 

Fazit

Web Apps bieten äußerst komfortable und praktische Möglichkeiten zur Wiederherstellung an. Anders als bei Virtuellen Maschinen ist zudem ein paralleles Datenbank-Backup integriert und ihr könnt durch Nutzung von Deployment Slots eure Ausfallzeiten selbst bei fehlerhaften Deployments auf null reduzieren.
 

Neuen Kommentar schreiben