Recap zu GitOps-Datensicherung und digitalen Zwillingen

Zu meinem Beiträgen mit den GitOps-Datensicherungen¹ und digitalen Zwillingen² haben sich einige Rückfragen angesammelt, die ich hier subsummieren möchte:

Veeam kann aber viel mehr als Deine Lose-Script-Sammlung…

Das ist unbestritten. Ich betrachte nur einen kleinen Bereich eines großen Portfolios. Am Ende des Tages geht es um vollständige und stets verfügbare Backups eines HyperV-Hypervisors mit seinen VMs. Eines, das schnell wieder auf einer frisch installierten Maschine befördert ist auch bei einer komplett abgebrannten Infrastruktur. Und da sieht ein meist im AD-integrierte Veeam mit seiner Business Continuity³ nicht gut aus.

Erschwerend hinzu kommt, dieses Szenario muss auch in 10 Jahren funktionieren. Das leistet kein kommerzieller Anbieter mit seinem jeweils proprietären Format. Gerade wenn das Geschäftsmodell auf Abo-Modellen mit raschen Versionssprüngen und einem Vendor-Lock-In basiert. Als Negativ-Beispiel kann ich Acronis nennen, wo es beim letzten Versionssprung erhebliche Probleme mit ältere Backups gab, die plötzlich nicht mehr wiederhergestellt werden konnten.⁴

Veeam sichert live, das kann HyperV nicht…

Ein häufig gehörter Einwand. Möglicherweise ist es einigen entgangen, dass HyperV ebenfalls VMs live ohne Unterbrechung sichern kann.⁵ Selbst Terminalserver mit vielen angemeldeten Benutzern stellen kein unüberwindbares Hindernis dar. Lediglich bei Datenbank-Servern empfehle ich zusätzlich zur VM-Sicherung auch noch Dumps in Gestalt von Halbtages- oder Tagesbackups zu machen.

Und was ist mit Exchange?

Wer heute ein On-Prem Exchange immer noch nicht gegen eine schlankere und besser zu verwaltende (Linux-) basierte Lösung ersetzt hat und das auch noch als Rechtfertigungsgrund für zusätzliche proprietäre Software heranzieht, der möge bitte von der nächsten Ransomware-Welle weggefegt werden.

Kannst Du ein solches Power-Shell Skript für den vorgestellten digitalen Zwilling posten?

Auch von mehreren nachgefragt, verständlich da PowerShell selbst nach Microsoft-Standards miserabel schlecht und in Teilen komplett unlogisch ist. Hier ein Skript zum Copy-Paste als Vorlage mit Kommentaren, your milage may vary da es gerade bei der Isolierung große Unterschiede gibt. So sind häufig nicht nur Name und vLAN sondern auch MAC-Adressen zu setzen. Aufgerufen wird das nachfolgende Skript mit dem Namen der gewünschten VM, von der es ein Zwilling zu erstellen gilt. Weitere Details in den Kommentaren:

param([string]$VM)

if (-not ([string]::IsNullOrEmpty($VM))) {

   # Diese Variablen bitte anpassen! 

   # Suffix für VM
	$NewVM = $VM + "-testing"
   
   # Ziel vLAN für Testumgebung
	$NewVLAN = 86

   # Name der internen VM Switch 
	$VMSwitchName = "VM Switch"

	# Quelle, das tägliche Backup
   $OriginFromBackup = Join-Path "D:\daily" $VM

   # Ziel, wo die VM hin soll
   $Destination = "C:\StorageMount\"
   $DestinationPath = Join-Path $Destination $NewVM

   # Entfernen einer vorherigen Testversion
	if (Test-Path $DestinationPath) {
      $VMexists = Get-VM -Name $NewVM -ErrorAction SilentlyContinue
      if ($VMexists) {
         Stop-VM -Name $NewVM -Force -ErrorAction SilentlyContinue
         Remove-VM -Name $NewVM -Force
         }
      Remove-Item -Path $DestinationPath -Force -Recurse -Confirm:$false
      }

   # Kopieren und importtieren
   Copy-Item -Path $OriginFromBackup -Destination $DestinationPath -Recurse
   $VMConfigPath = join-path $DestinationPath "Virtual Machines"
   $VMConfigFile = Get-ChildItem -Path $VMConfigPath -Filter *.vmcx | Select-Object -First 1
	if ($VMConfigFile) {
   $VMImported = Import-VM -Path $VMConfigFile.FullName -SmartPagingFilePath $DestinationPath -SnapshotFilePath (join-path $DestinationPath "Snapshots") -VhdDestinationPath (join-path $DestinationPath "Virtual Hard Disks") -VirtualMachinePath $DestinationPath -GenerateNewId -Copy
   if ($VMImported) {

      # Umbenennung
      Rename-VM -VM $VMImported -NewName $NewVM

      # Stop bei vorhandener Live-Sicherung
      Stop-VM -Name $NewVM -Force -ErrorAction SilentlyContinue

      # Kein automatischer Start
      Set-VM -Name $NewVM -AutomaticStartAction Nothing

      # Aktuellen Netzwerk Adapter feststellen
      $Network = Get-VMNetworkAdapter -VMName $NewVM

      # Adapter entfernen und neu hinzufügen (=neue MAC)
      # Sonderfall: Mehrere Adapter berücksichtigen!
      Remove-VMNetworkAdapter -VMName $NewVM -Name $Network.Name
      Add-VMNetworkAdapter -VMName $NewVM -SwitchName $VMSwitchName

      # in ein anderes VLAN setzen
      Set-VMNetworkAdapterVlan -VMName $NewVM -Access -VLanId $NewVLAN
    	}
	}
}

Wie sieht es auf Servern mit völlig unterschiedlichen VMs, Pfaden und Einstellungen aus. Wo liegt der Vorteil eines GitOps wenn alles eh unterschiedlich ist?

Ich arbeite alleine als Admin, warum der zusätzliche Aufwand?

… GitOps ist ein zusätzlicher Komplexitäts-Layer.

Als ISB oder Unternehmen will man genau prüfen und wissen, was gesichert wird. Wer hat was, wann am System etwas gemacht. Es geht um Nachvollziehbarkeit und Transparenz, den Eckpfeilern eines jeden ISMS. Genau da spielt ein GitOps-Workflow seine Stärken aus. By the way, eine VM Infrastruktur sollte nach Möglichkeit einheitlich sein.

In der Rolle eines Admins oder Entwicklers kann ich selbst heute nicht sagen, was ich vor einem Monat bei Kunde X oder Projekt Y gemacht habe. Ein kurzer Blick in das Repo gibt Gewißheit. Nicht nur mir, sondern auch anderen. Ganz ohne Notwendigkeit, auf kritischen Systemen herum zu klettern und Zugänge verteilen zu müssen.

… wir sind ISO 27001/ BSI Grundschutz/ TISAX/ bla bla bla auditiert…

Ist das jetzt eine Schutzbehauptung? Ein Skript oder ein selbst definierter Prozess hat gegenüber einem Produkt von der Stange keinen Nachteil. Beide müssen dokumentiert und einer Risikoanalyse unterzogen werden. Beide sind in regelmäßigen Tests zu überprüfen und bei beiden sollte auch ein kontinuierlicher Verbesserungsprozess etabliert sein. Das alles ist bei GitOps einfacher als bei einer proprietären Blackbox.

In diesem Sinne,
ein schönes Wochenende
Tomas Jakobs