Details

Category: #Leinetal

Published: 25 March 2023

Was ist besser als ein Backup?

Ein Backup das nicht mit dem Server verbrennt.

Unsere Webseite ist vielen Bedrohungen (threads) ausgesetzt und es macht Sinn sich darüber Gedanken zu machen.

Wie immer bei komplexen Themen hilft die Verschriftlichung:

Bedrohungen

Es gibt viele Bedrohungen, doch es gibt ein Muster:

Kategorie 1

• Fehlbedienung
• Software Fehler nach update (CMS, CMS Erweiterungen)

Kategorie 2

• Software Schwachstellen
  • Verschlüsselungs-Virus

Kategorie 3

• Angriffe auf IT-Service Ebenen unterhalb CMS
• Hardware Fehler (Webseiten benötigen Server)
• Naturgewalten (Server stehen an einem Ort = Erdbeben, Feuer, Wasser)
• Infrastruktur (Server benötigen Gebäude, Strom, Kühlung, Internet-Anbindung)
• Terror (gegen Infrastruktur)

Natürlich kann sich jeder seine eigene Liste zusammenstellen.

Diese realen Bedrohungen habe ich bereits in Risiko Kategorien zusammengefasst.

Risiken

Natürlich werden Risiken auch bewertet. Üblicherweise nach Eintrittswahrscheinlichkeit und Schwere der Auswirkungen.

Diesen Schritt überspringen wir für heute, da es uns nicht helfen wird wenn wir uns auf ein unwahrscheinliches Ereignis nicht vorbereiten und es dennoch eintritt. 

Statt dessen, planen wir mit diesen Risken umzugehen.

Wir haben Möglichkeiten

Diese sind, ein Risiko zu akzeptieren (accept), es an Jemanden zu übertragen (transfer) oder Maßnahmen zu ergreifen die Auswirkungen abzumildern (mitigate).

Risiko Kategorie 3 "Server Betrieb"

Alle Bedrohungen dieser Risiko Kategorie übertragen wir (transfer) zum Hosting Partner.

Je nachdem welchen Hosting Partner, oder welchem Hosting Paket man sich mit seinem Projekt anvertraut, ist man hier gut oder besser für den echten Notfall beraten. Ich weiß mich seit rund 20 Jahren mehr als nur gut betreut und kann auf ein Sicherungs Netz Könnern vertrauen.

Wenn es zum Schlimmsten kommt, bin ich sicher das Webhosting Infrastruktur mit allen Inhalten wieder Herrgestellt wird.

Es könnte natürlich sein, das temporär nur eine "Ersatz Hosting Umgebung" bereit steht, beispielsweise wenn ein Rechenzentrum abbrennt.

Das wäre dann die nächste Stufe. Gleichzusetzen mit dem Fall, das mein Hosting Partner komplett ausfällt.

Ich benötige eine "Desaster Vorsorge".

Risiko Kategorie 1 "die Zeit zurück drehen"

Oh es ist ein Update verfügbar....

Natürlich muss man Software updates einspielen um Sicherheitslücken zu schließen oder neue Funktionen freizuschalten.

Leider macht nicht jedes Update immer Alles besser. Genau wie Konfigurationsänderungen oder Änderungen unter Zeitdruck.

Bei einer Webseite ist es möglich die Zeit zurück zu drehen, wenn die letzte Aktion so garnicht das gewünschte Resultat hervorbringt.

Kein Backup - Kein Mitleid

Weil es diese Momente gibt, in denen man sich wünscht etwas ungeschehen zu machen, gibt es das Backup.

Klug handelt derjenige, der ein Backup erzeugt bevor er eine nachhaltige Änderung durchführt.

Mit nur einem Mausklick ist die Arbeit von Stunden, Tagen, Wochen oder Monaten zerstört.

Mit einem weiteren Mausklick ist sie Wiederherrgestellt.

Sofern man ein Backup hat und weiß wie der Restore, also das Zurückspielen funktioniert.

Backup hatte ich ja bereits eingerichtet und den Restore geübt.

Risiko Kategorie 2 "Angreifer suchen & nutzen Schwachstellen"

Es gibt so genannte Software Schwachstellen, die sind völlig harmlos weil sie die Funktion nicht beeinträchtigen.

Sie werden zum Problem wenn sich Dritte über diese Software Schwachstellen Zutritt oder Zugriff auf Systeme und Informationen selbst erlauben, obwohl es ihnen nicht gestattet ist.

Software Entwickler tun ihr bestes um "gute" Software zu "schreiben", doch andere suchen hartnäckig nach neuen Möglichkeiten eingerichtete Barrieren zu überwinden oder zu umgehen und für ihre Zwecke auszunutzen.

Wieder Andere suchen ebenso hartnäckig nach diesen Möglichkeiten um die Software Enwickler darauf hinzuweisen wenn sie fündig geworden sind.

Schwachstellen Ausnutzer und Software Entwickler liefern sich ein ewiges Rennen.

Es verliert der Software Anwender dessen Webseite Besuch bekommt bevor die Sicherheitslücke mit einem Update versiegelt wurde.

Leinetal.de basiert auf einem Content Management System und zahlreichen Erweiterungen (Komponenten), die zahlreiche Module und Plugins mitbringen. Es sind Hunderte Software Pakte die jedes für sich ein Betriebsrisiko sind.

Konkret:

1 Content Management System

7 Komponenten

8 Module

197 Plugin

Daher macht es Sinn ungenutze Software zu deinstallieren.

Im schlimmsten Fall ist es Angreifern möglich eigene Programme zu installieren und auszuführen, was schlicht den Totalverlust aller Dateien, Konfigurationen und Inhalte bedeutet.

Hiervon sind dann auch alle Backup Dateien betroffen die auf diesem Webspace liegen.

Daher macht es Sinn das Backup nicht (nur), auf dem Webspace des selben Servers zu lagern.

Das Backup beispielsweise zu Hause auf dem Computer oder in einem Cloudservice zu speichern ist eine gute Desaster Vorsorge.

Desaster Vorsorge cold Backup

Ein soeben erstelltes Backup per ftp Client herunterladen, fertig. Das geht manuell prima. Weil nach einem CMS Update oft auch Komponenten ein Update benötigen, kann dies zu mehreren Backups in kurzer Folge führen.

Natürlich wird nicht jedes heruntergeladen.

Nach einer Weile wird zu bemerken sein, das die Backup Datei immer größer wird.

Das liegt dann vermutlich daran, das das jedes Backup alle Backup Dateien beinhaltet die auf dem Server liegen der gesichert wird.  

Das wirkt sich nachteilig auf den benötigten Platz und die Zeit für Download und Upload aus.

Backup Konzept 

Wenn man es aufschreibt, sollte es den Titel "Backup & Recovery Konzept" tragen.

Es beinhaltet die Anforderungen und wie sie umgesetzt werden. Es dient als lebendes Dokument der Dokumentation der aktuellen Konfiguration. Hierbei kann man sich auf das Wesentliche beschränken.

Eine Ergänzung um die Beschreibung von Routine Aufgaben macht es zum "Betriebshandbuch Backup & Recovery".

Disaster Recovery Plan

Ein Extrakt der Routine Aufgaben, hierbei insbesondere der Restore Prozess, dient als Desaster Recovery Plan und sollte mindestens jährlich aktualisiert und geprobt werden.

Besser ist es den "Desaster Restore Prozess" in den Entwicklungs- & Testprozess zu integrieren. So wird er mehrfach im Jahr ausgeführt und damit auch geprobt.

Backup Profile & Post Processing

Wenn man auf seine Daten angewiesen ist stellt man mehr Anforderungen an seine Backup Software als nur Backup & Restore.

Backup Profile diesen dazu verschiedene Backup Konfigurationen zu verwalten und sie nach Bedarf einzusetzen.

Teil-Backup, Voll-Backup, nur Verzeichnisse & Dateien, oder nur die Datenbank oder alles? 

Was passiert mit alten Datensicherungen - automatisiert löschen, ausser sie werden noch gebraucht?

Aktuell nutze ich zwei Backup Profile.

Beide erzeugen ein Vollbackup aller Ordner und Dateien inklusive der kompletten Datenbank in eine Backup Datei.

Das erste Profil speichert lokal auf dem Server, das zweite Profil ist soweit identisch mit dem ersten.

Nur das es die Backup Datei nach Erstellung,  als weiteren Verarbeitungsschritt (post-processing) nicht lokal sondern im Cloud Dienst meiner Wahl speichert, von wo es auch wiederherstellbar ist.

Alte Backupdateien werden automatisch vom Server gelöscht. Ich lösche sie später manuell aus dem Log.

Mit einem weiteren Profil werde ich das Backup file zum Testserver übertragen. Dort kann ich es lokal wieder herstellen und habe damit mein Testsystem aktualisiert.

Fazit:

Mit etwas mehr Aufwand bei Planung und Implementation können neben dem obligatorischen Backup auch weitere Themen wie Desaster Wiederherstellung und Testsystem Aktualisierung abgedeckt werden.  

Last Updated: 26 March 2023

Hits: 57