silvesterlangen.de

Seite
Menü

Backups mit Linux

Backups sind neben dem einwandfreien Betrieb eines Servers oder Netzwerk das nächste Wichtige in einem Unternehmen. Verlorene Daten bedeutet verlorenes Wissen, verlorene Belege und das kann für ein Unternehmen unter Umständen der Ruin sein. Darum ist es wichtig eine ordentliche Backupstrategie zu entwickeln.

 

Ein paar Gedanken zu Backups

Bevor wir loslegen können sind einige Fragen, die wir uns stellen müssen:

  • Wer macht die Backups? Ich? Der Kunde?
    1. Das kommt sich immer darauf an wer der Kunde ist. In der Regel ist das so, dass sie sich selbst nicht wirklich helfen können. Wir sind oft diejenigen, die überhaupt erst mal den Gedanken mitbringen Backups zu erstellen. Für den Kunden ist ein "Backup" schon ein Backup, wenn sie die Daten per Copy/Paste auf eine andere Festplatte bringen. Von Regelmäßigkeit kann da nur selten die Rede sein.
  • Wohin sichere ich die Daten? NAS, USB-Festplatte, Tape oder...?
    • Speicherung auf einem NAS
      Das NAS ist nicht schreibgeschützt und der Clientcomputer hat stetigen Zugriff auf den Datenbestand des Backups. Ein verseuchter Client-PC kann den gesamten Datenbestand in Gefahr bringen. Eine mögliche Lösung wäre ein NAS, was Snapshots kann.
    • Per Copy/Paste auf die USB-Festplatte.
      Sie kann nach dem Backup wieder abgesteckt werden. Klingt erst mal gut. Das Problem ist hier die Verwechslung mit der Festplatte. Es wäre nicht das erste mal, wenn sich jemand Daten von der USB-Platte auf den PC holt, weil er die Datenträger verwechselt hat und sich damit wichtige neue Daten überschreibt.
    • Tapes sind immer noch beliebt
      aber bei einem Totalausfall sind sie einfach zu langsam, wenn es um die Wiederherstellung geht.
  • Womit sichere ich die Daten?
    • Die Wahl der Backupsoftware spielt eine große Rolle, denn nicht jede Software ist dafür geeignet. Mit DD lässt sich kein Inkrementelles Backup ohne weiteres machen. Die Backupsoftware muss den Bedürfnissen der zu sichernden Daten angepasst sein. Ist ein Datenbankserver während des Betriebes zu sichern, dann ist es nicht damit getan die Daten einfach zu "kopieren".
  • In welchem Intervall sichere ich?
    • Man muss sich fragen in welchem Zeitraum was für Datenmengen erzeugt werden und wie die Wichtigkeit ist. Sichere ich unregelmäßig und es gehen ein paar Urlaubsbilder verloren, dann ist das sicher kein Untergang. Verschwinden aber Daten aus der Finanzbuchhaltung, dann wird es haarig. Obendrein werden diese Daten je nach Unternehmen minütlich erzeugt. Je weniger Verlust, desto besser. Wann sichert man also in diesem Fall? Drei mal täglich oder sogar noch öfter?
  • Wie sichere ich? Vollbackup, Differenzielles Backup, Inkremental Backup?
    • Vollbackup
      Eine vollständige Sicherung
    • Differenzialbackup
      Dieses Backup hat als Basis immer das letzte Vollbackup. Beispiel: Mo = Vollbackup, Di = Diff.-Backup und Mi = Diff.-Backup. Das System "stirbt" am Mittwoch wenige Stunden nach dem Backup. Will ich es wiederherstellen, so brauche ich das Vollbackup von Mo. und dann das Diff.-Backup von Mittwoch und schon bin ich wieder auf dem aktuellen Stand der Dinge.
    • Inkrementelles Backup
      Anders als beim Diff.-Backup basiert nur das erste des Inkremental-Backups auf dem letzten Vollbackup. Jedes weitere Inkr.-Backup basiert dann auf dem letzten Inkr.-Backup. Bei der Wiederherstellung benötige ich also das letzte Vollbackup und ab dann alle Inkr.-Backups bis Mittwoch und spiele sie der chronologischen Reihenfolge nach ein.

  • Was sichere ich denn alles?
    • Konfigurationen
      Aktuell erlebe ich das wieder, dass sinn- und wahllos alles "gesichert" wird, was nicht niet- und nagelfest ist. Braucht man das alles? Welche Konfigurationsdateien sind wirklich notwendig und welche befinden sich noch im Originalzustand nach der Installation?
    • Logfiles
      Wenn ich einen Apache betreibe, brauche ich dann die Logfiles des Samba nur, weil er per Standartinstallation mitinstalliert worden ist?
    • Daten
      Gibt es Daten, die vielleicht gar nicht gesichert werden müssen? Auch das sollte man prüfen. Kommt nicht so oft vor, aber trotzdem sollte man sich dem Gedanken mal annehmen.
    • virtuelle Festplatte(n)?
      Habe ich VMs, die gesichert werden sollen? Ist es nicht einfacher die VMs komplett zu sichern? Stichworte: Kapazität, Zeit, Recovery ...
  • Was geschieht mit den gesicherten Daten? Mit nach Hause nehmen?
    • Mit nach Hause nehmen
      Das ist eine Möglichkeit. Dabei muss man sich aber fragen was unterwegs so alles passieren kann. Verlieren, gestohlen, Unfall usw... Unterwegs kann alles mögliche passieren. Bei Verlust des Datenträgers (geklaut, verloren...) könnte eine Verschlüsselung des Datenträgers helfen. Das bringt die Daten zwar nicht zurück, aber verhindert, dass jemand anders die Daten liest.
    • Im Unternehmen lagern
      Was kann alles im Unternehmen passieren? Einbruch, Feuer etc... Auch hier sind die Daten sicherlich nicht sicher. Es könnte aber helfen die Datenträger in einem anderen Brandabschnitt aufzubewahren. Verschlüsselung wäre hier aber auch eine gute Sache. Vielleicht sogar in den Tresor legen.
  • Sollen/müsen wir Backups verschlüsseln?
    Zwar habe ich das quasi oben schon vorweg genommen, aber man kann es nicht oft genug sagen: Verschlüsselung hilft gegen Datenklau. Ob daheim oder im Unternehmen. Egal wo die Datenträger liegen.
  • Per SSH transportieren
    Geläufig ist, dass man vom Backupserver einen Tunnel zu Client aufbaut und dort dann die Daten holt. Was ist aber, wenn es für Port 22 (SSH) kein Portforwarding zum Client geben darf? Wie soll der Backupserver eine Verbindung aufbauen?

    Der Client baut per Script im Intervall (testet alle 15 Min, ob der Backupserver erreichbar ist) eine Verbindung zum Backupserver auf. Ist der Verbindungsaufbau erfolgreich, dann wird über die geöffnete Verbindung eine Rückverbindung hergestellt, sodass der Backupserver auf den Client zugreifen kann. Wie das geht kann man hier lesen.

weiter zu:

« vorige Seite Seitenanfang nächste Seite »
Seite
Menü
Earned Certificates:
LPIC-1 LPIC-1 LPIC-1
Powered by CMSimple | Template by CMSimple | Login