März 2021
Autor:in des Beitrags
Matthias
Architect Cloud
Veröffentlicht am
15.03.2021 von Matthias
Jetzt Blogbeitrag teilen
Xing LinkedIn Facebook Twitter
Einfach und schnell mit der Powershell AWS CLI

AWS Backup Plan

In diesem Blogbeitrag erweitern wir unser Powershell Script um einen Backup Plan und einer dazugehörigen Selection.

Durch die Selection definieren wir, wie und auf welche Ressourcen der Backup Plan zutrifft.

Eine kurze Übersicht, was wir bereits in unserem Script aufgebaut haben:

  • SNS Topic (mit Attributes)
  • Protocol Type und Notifications
  • Optional: Backup Vault
  • SNS Subscricption

Was wir jetzt noch für einen Backup Plan benötigen, sind folgende Punkte:

  • Das bestehende Skript um neue Parameter erweitern
  • Erstellung des Backup Plan
  • Zuweisen einer IAM Rolle
  • Erstellen der Selection

Neue Parameter

Zunächst brauchen wir neue Parameter, auf die wir uns im Anschluss beziehen können.

Für den Backup Plan brauchen wir:

# PARAMETER BACKUP PLAN

$BackupPlanName = “BESTBACKUPPLAN”

$BackupRuleName = “BESTBACKUPRULE”

$BackupPlanMinutes = “0”

$BackupPlanHours = “1”

$BackupPlanDayOfMonth = “?”

$BackupPlanMonth = “*”

$BackupPlanDayOfWeek = “*”

$BackupPlanYear = “*”

$BackupPlanStart = “120”

$BackupPlanDelete = “30”

$BackupPlanCompletion = “10080”

Hier geben wir neben dem Namen für den Backup Plan und der Rule an, wann ein Backup durchgeführt werden soll und wie lange dieses Backup aufbewahrt wird.

Die Werte für diese Parameter werden mit Cron-Zeichen angegeben. Dadurch können die zeitlichen Abläufe individuell angepasst werden.

Cron-Zeichen:

FeldWertePlatzhalter
Minuten0-59, – * /
Stunden0-23, – * /
Tag des Monats1-31, – * ? / L W
Monat1-12 oder JAN-DEC, – * /
Wochentag1-7 oder SUN-SAT, – * ? L #

Quelle: (Planen von Ausdrücken für Regeln – Amazon CloudWatch-Ereignisse)

Da die Platzhalter auf den ersten Blick eventuell nicht allzu aussagekräftig sind, hier eine kleine Erläuterung:

PlatzhalterBeispiel Erklärung
,Month: „JAN, NOV“; Minutes: “10,40”Month: für die Monate Januar und November; Minutes: immer um 10 und 40 Minuten nach der angegeben Stunde
Month: „1-3“; DayOfMonth: „1-10“ DayOfWeek: „MON-SAT“Month: für die ersten drei Monate des Jahres; DayOfMonth: für die ersten 10 Tage des jeweiligen Monats; DayOfWeek: Montag bis Samstag
*Minutes: „*“Das * steht für jeden Wert. Daher wird das * im Beispiel für jede Minute angesehen. Kann nicht gleichzeitig in DayOfMonth und DayOfWeek verwendet werden! (Im anderen Feld muss stattdessen „?“ eingetragen werden)
?DayOfWeek: „?“Ein ? wird dann verwendet, wenn der Wert keine Rolle spielt, z. B. wenn das Backup nicht an einem speziellen Wochentag erfolgen soll
/DayOfWeek: „?“Minutes: „2/15“; Hours: „0/4“Minutes: alle 30 Minuten mit der zweiten Minute der Stunde (17., 32., 47. Minute); Hours: jede vierte Stunde des Tages
LDayOfWeek: „7L“L gibt des letzten Tag der Woche oder des Monats an.
7L: letzter Samstag des Monats
WDayOfMonth: „5W“W gibt den Wochentag an, daher im Beispiel: fünfter Wochentag
#DayOfWeek: „2#3“DayOfWeek: der dritte (3) Montag (2) des Monats

Der Cron-Ausdruck in unserem Beispiel lautet: cron(0 1 ? * * *)

$BackupPlanMinutes = “0”

$BackupPlanHours = “1”

$BackupPlanDayOfMonth = “?”

$BackupPlanMonth = “*”

$BackupPlanDayOfWeek = “*”

$BackupPlanYear = “*”

Dadurch wird zu jeder vollen Stunde, ohne Einschränkungen auf Tag oder Monat, ein Zeitfenster für die Durchführung des Backups erstellt.

Mit dem Wert „BackupPlanStart“ geben wir in Minuten an, wann das Backup spätestens innerhalb des Zeitfensters gestartet werden soll. Ansonsten wird der Auftrag für das Backup nicht ausgeführt.

Standardmäßig haben Backups sieben Tage Zeit, bis sie nach erfolgreichem Start fertig sein müssen. Ansonsten werden sie verworfen. Mit „BackupPlanCompletion“ kann aber auch ein anderer Zeitraum angegeben werden.

 

Um die Ressourcen für einen Backup Plan zu kennzeichnen, benötigen wir noch eine Selection.

In einer Selection (es können mehrere für jeden Plan erstellt werden) können Ressource ID’s direkt hinterlegt werden.

Der elegantere Weg ist jedoch, mit Hilfe von Tags, eine Ressource dem Plan hinzuzufügen.

Dafür benötigen wir drei weitere Parameter:

# PARAMETER BACKUP
SELECTION

$BackupSelectionName = “BESTSELECTION”

$BackupConditionKey = “BESTTAG”

$BackupConditionValue = “BESTVALUE”

BESTTAG ist in dem Beispiel der Key Name, den wir später unserer Ressource hinzufügen. Wenn die Ressource zusätzlich den Value BESTVALUE besitzt, wird sie für den Backup Plan ausgewählt.

Backup Plan und Selection

Mit den neu gesetzten Parametern können wir nun den Backup Plan erstellen.

# BACKUP PLAN JSON

$JSONPLAN = @”

{

“BackupPlanName”: “$BackupPlanName“,

“Rules”: [

{

“RuleName”: “$BackupRuleName“,

“ScheduleExpression”: “cron($BackupPlanMinutes $BackupPlanHours $BackupPlanDayOfMonth $BackupPlanMonth $BackupPlanDayOfWeek $BackupPlanYear)”,

“StartWindowMinutes”: $BackupPlanStart,

“TargetBackupVaultName”: “$BackupVaultName“,

“CompletionWindowMinutes”: $BackupPlanCompletion,

“Lifecycle”: {

“DeleteAfterDays”: $BackupPlanDelete

}

}

]

}

“@

$JSONPLAN | Out-File -Encoding ascii -file BackupPlan.json

Mit diesem Befehl wird ein JSON File (unter dem derzeitigen Pfad) erstellt, in dem sich unsere oben verwendeten Parameter wiederfinden. Dies ist nötig, damit wir im Anschluss die ID des Backup Plans als neue Variable speichern können.

#BACKUP PLAN ID

$BackupPlanId = (aws backup create-backup-plan —backup-plan file://BackupPlan.json | ConvertFrom-Json).BackupPlanId

Da wir nun den Backup Plan in unserer AWS Umgebung erstellt und die dazugehörige ID als Variable gespeichert haben, können wir eine Selection hinzufügen.

Zunächst benötigen wir allerdings noch eine IAM Rolle, die wir für unsere Selection verwenden wollen.

# BACKUP IAM ROLE

$IAMBackupRole = $IAMRoleList -match “AWSBackupDefaultServiceRole” -split ‘”‘ -match “arn:aws:iam”

Wir nutzen hier einfach die vorgefertigte Rolle für Backups von AWS.

Wie bei dem Backup Plan, erstellen wir uns zunächst ein JSON File mit dem Inhalt der Selection. Dazu gehören der Selection Name und die IAM Rolle sowie der Key Name für den Tag und dessen Inhalt (Value).

# BACKUP SELECTION JSON

$JSONSELECTION = @”

{

“SelectionName”: “$BackupSelectionName“,

“IamRoleArn”: “$IAMBackupRole“,

“Resources”: [],

“ListOfTags”: [

{

“ConditionType”: “STRINGEQUALS”,

“ConditionKey”: “$BackupConditionKey“,

“ConditionValue”: “$BackupConditionValue“

}

]

}

“@

$JSONSELECTION | Out-File -Encoding ascii -file BackupSelection.json

Zu guter Letzt bringen wir die ID des Backup Plans und das JSON File für die Selection zusammen.

# BACKUP SELECTION

aws backup create-backup-selection —backup-plan-id $BackupPlanId —backup-selection file://BackupSelection.json

Unser PowerShell Script ist jetzt fertig!

Wir können nun neben SNS Topic, SNS Notification und Backup Vault auch einen Backup Plan mit einer Selection mit nur einem Klick erstellen.

Das Einzige was jetzt noch fehlt, ist der Ressource, die wir dem Backup Plan hinzufügen wollen, den Tag (BESTTAG), sowie das Value (BESTVALUE), aus der dazugehörigen Selection zuzuweisen.

Fazit

Zugegeben, manche Dinge sind nicht sehr intuitiv, was AWS in Kombination mit PowerShell angeht. Doch mit ein paar kleinen Tricks, kann man so gut wie alles in ein Script packen und automatisieren.

Ich hoffe, dieser Blog (und auch der erste Teil: AWS Backup Notifications) war hilfreich und motiviert den ein oder anderen, mehr AWS Befehle in PowerShell zu nutzen.

Das könnte dich auch interessieren

Blogbeitrag

Echtes Zero Trust im Citrix-Workspace mit deviceTRUST

Conditional Access prüft beim Login, deviceTRUST während der gesamten Citrix-Session: kontinuierlich und kontextbasiert. Wie du deine Citrix-Umgebung zu einem Zero-Trust-Workspace weiterentwickelst, der Security-Anforderungen und Alltag der Fachbereiche zusammenbringt.
Weiterlesen
Blogbeitrag

Secure Boot 2026: Warum Unternehmen jetzt handeln sollten

2026 laufen wichtige Secure-Boot-Zertifikate ab – erfahren Sie, warum Unternehmen ihre Systeme schon heute prüfen und vorbereiten sollten.
Weiterlesen
Blogbeitrag

KI wirtschaftlich einsetzen: Warum der richtige Workflow wichtiger ist als der Prompt

Mit der verbrauchsabhängigen Abrechnung von Microsoft Copilot Cowork wird Wirtschaftlichkeit im KI-Einsatz zur operativen Frage. Der Artikel zeigt, warum nicht der Prompt, sondern vor allem der passende Workflow über Aufwand, Transparenz und Nutzen entscheidet.
Weiterlesen
Blogbeitrag

US-Urteil zur FTC: Handlungsbedarf für Microsoft-Kunden?

Das Urteil des US Supreme Court zur FTC sorgt für neue Fragen rund um das EU-US Data Privacy Framework. Wir ordnen ein, was das für Microsoft 365, Azure und die nächsten Schritte in der Praxis bedeutet.
Weiterlesen
Blogbeitrag

Die neue Infrastrukturkostenkrise

Hardwarepreise steigen, Virtualisierungslizenzen werden teurer, Energiekosten unberechenbarer. Wer jetzt einfach verlängert, trifft eine Entscheidung, ohne neu gerechnet zu haben. Was sich gerade verändert und warum es sich lohnt, die eigene Infrastruktur neu zu bewerten.
Weiterlesen
Provectus Team
Blogbeitrag

25 Jahre Provectus: Eine Reise, die im Biergarten begann 

Christian Jupe und Josef Lang blicken auf 25 Jahre Provectus zurück: von den ersten Ideen im Biergarten über prägende Kundenprojekte bis zur heutigen Vision als Smart-Work- und Business-Partner. Im Interview sprechen sie über Unternehmenskultur, Werte, Wandel und die Zukunft mit KI.
Weiterlesen
Blogbeitrag

Vom Trainee-Programm ins Kundenprojekt: Unser Rückblick auf acht intensive Monate

Unsere Trainees berichten von den ersten Monaten im Provectus-Traineeprogramm, geben Einblicke in Workshops, Lernphasen und den täglichen Einsatz von KI-Tools und zeigen, wie sie auf ihre Rolle als Junior Professionals vorbereitet werden.
Weiterlesen
Webinar

Moderne Apps brauchen moderne Plattformen: Warum der Betrieb über Ihren Erfolg entscheidet

Für alle, die verstehen wollen, warum Cloud-Projekte nicht an der Migration scheitern, sondern im Betrieb. Unternehmen kämpfen mit steigenden Kosten, fehlender Transparenz und neuen Risiken. Der Grund: Cloud ist kein Infrastrukturthema, sondern ein Betriebsmodell mit klaren Anforderungen.
Weiterlesen
Blogbeitrag

Virtual Workplace Evolution 2026

Wir sind dabei und freuen uns auf einen spannenden Austausch zur Transformation von IT Workplaces. Besuchen Sie unseren Vortrag von Danny Kopper, Principal Consultant & Michael Mahlbacher, Leiter Arbeitsplatz bei MLP Finanzberatung SE zum Thema: Microsoft-Lizenzen optimal nutzen
Weiterlesen
Webinar

DORA-konformer Cloud-Betrieb: So setzen Sie Anforderungen praxisnah um

WEBINAR, 18.06: DORA-konformer Cloud-Betrieb praxisnah erklärt: Erfahren Sie im Webinar, wie Finanzunternehmen regulatorische Anforderungen wirksam, prüfbar und dauerhaft im IT-Betrieb umsetzen.
Weiterlesen
Jetzt Blogbeitrag teilen
Xing LinkedIn Facebook Twitter