Schlagwort-Archiv: backup

Debian-Paketlisten sichern und wiederherstellen

Für den Umzug auf neue Hardware möchte ich meine installierten Pakete auch auf dem neuen System installieren. Air Jordan Uomo 9 Dazu sichere ich die Paketlisten mit dpkg. Nike Air Max 1 Heren Dabei geht allerdings die Information verloren, Herschel Walker UGA Jersey ob ein Paket manuell oder aufgrund von Abhängigkeiten automatisch installiert wurde.

Neue Versionen von duplicity (0.5.02) und ftplicity (1.4.0b1)

Nach längerer Zeit überprüfte ich mal wieder den Status meiner Backup-Programme. Maglia Shaquille O’Neal Da bisher auch alles wunderbar lief war es vorher nicht unbedingt notwendig. ray ban homme pas cher Offensichtlich hatte sich in der Zwischenzeit so einiges getan, sodass es mal wieder einen kleinen Artikel rechtfertigt. Neue Versionen von duplicity (0.5.02) und ftplicity (1.4.0b1) weiterlesen

duplicity 0.4.6 released

ACHTUNG: Die in diesem Artikel besprochenen Versionen sowohl von ftplicity als auch duplicity sind bereits veraltet. Die grundsätzlichen Erklärungen sind zwar weiterhin valid, aber die Syntax oder Konfigurationsparameter könnten sich geändert haben. Bitte verwendet den Such-Tag “duplicity” bzw. den Such-Tag “ftplicity” und die Kommentare, um aktuelle Informationen zu finden.

So, die neue Version 0.4.6 von duplicity wurde vom Team released (endlich mal kein RC) und auch umgehend von mir installiert und getestet.

Die Installation ist denkbar einfach:

  • Bitte vorher ein eventuell installiertes Distributions-Paket deinstallieren, damit es keine Konflikte mit der Paketverwaltung gibt. Eigenhändig installierte Vorversionen müssen aber nicht entfernt werden.
  • Download der Files:

    cd downloads # Beispielpfad
    wget http://savannah.nongnu.org/download/duplicity/duplicity-0.4.6.tar.gz

    Entpacken

    tar -xzf duplicity-0.4.6.tar.gz

  • In das Verzeichnis wechseln.

    cd duplicity-0.4.6

  • Version bauen und installieren

    python setup.py build
    python setup.py install

  • Fertig.

Für die Verwender von ftplicity: Wie alle duplicity-Versionen ab 0.4.4 funktioniert nur dies mit meiner angepassten Version von ftplicity.

LINK: Zum [duplicity]-changelog…

duplicity-Patch für FTP mit Portangabe (0.4.4RC2)

UPDATE: Der Patch wurde in den 0.4.4RC3 aufgenommen. 🙂 Es besteht also kein Grund mehr für das manuelle Patchen. (zum offiziellen Changelog)

Da Daniel in dem HOWTO zu ftplicity nach einer Möglichkeit zur Verwendung eines anderen Ports beim Verbinden mit seinem FTP-Server gefragt hat und diese Möglichkeit bei duplicity scheinbar nicht ganz gegeben ist, habe ich mal fix einen Patch für die entsprechende Datei erstellt.

Das Interessante dabei ist, dass die Funktionen schon alle da sind (Port aus der URL herausfinden usw.), sie aber für FTP einfach nicht genutzt werden.

Patch für duplicity 0.4.4RC2 (backends.py)

Dieser Patch gestattet es, auch in FTP-URLs einen Port anzugeben a la “user@host:port/dir”. Der Port wird verwendet sobald eine Port-Angabe exisitiert und vom Port 21 (Standard) abweicht.

Die zu patchende Datei liegt in der Standardinstallation von der duplicity-Seite in /usr/lib/python2.4/site-packages/dulicity

Die Verwendung ist zwar bei mir getestet, erfolgt aber dennoch ohne Gewähr!

Auf Kommentare bin ich gespannt.

automysqlbackup: versionierte Sicherung von mysql-Datenbanken

Die Sicherung von Datenbanken ist immer wieder eine Aufgabe, die man schnell vergisst und, wenn man sich dann damit befasst, für Kopfschmerzen sorgen kann.

Die Gründe:

  • Während des Betriebs des Datenbankservers ist es meist nicht möglich einen konsistenten Abzug der Datendateien zu erhalten.
  • Ein Anhalten des Datenbank-Server hat aber Auswirkungen auf das gesamte System.
  • Selbst wenn man die Dateien kopieren kann, ist es nicht 100%ig sicher, dass man nach einem Absturz die Daten in einen neuen DB-Server mit vielleicht veränderter Versionsnummer einspielen/ einkopieren kann.

Es bietet sich daher an, statt der Datenbankdateien nur die gespeicherten Daten zu sichern. Dies ist mittels eines sog. dumps (eng. “Halde”) möglich, bei dem die Daten im Klartextformat ausgegeben und optimalerweise gleich in die Befehle eingeschlossen werden, die die Daten automatisiert wieder in einen neuen Datenbankserver einspielen können.

Auch wenn MySQL bereits von Hause aus Tools mitbringt, die diese Sicherungsmethode ermöglichen und auch Hilfstools wie phpMyAdmin eine Option zum Erzeugen von DB-dumps bieten, suchte ich eine noch simplere Methode, die ggf. noch Mehrwert bietet.

automysqlbackup

Das Projekt automysqlbackup ist unter sourceforge gelistet und derzeit in der Version 2.5 aktuell. Das Projekt scheint nicht mehr weiterentwickelt zu werden, denn der letzte Release ist vom 14.02.2006. Dies ist aber nicht weiter problematisch, da es sich im Prinzip nur um einen Wrapper für das mysql-tool mysqldump handelt und damit nicht sonderlich wartungs- oder weiterentwicklungsbedürftig ist.

Die Vorteile der Nutzung von automysqlbackup sind (von der Homepage):

  • Backup aller oder ausgewählter Datenbanken
  • gesamtes Backup in eine Datei oder einzelne Dateien pro Datenbank
  • Platzsparend durch wahlweise Komprimierung mit gzip oder bzip2
  • Sicherung auch von entfernten Servern
  • Manueller Start oder cron-job-Steuerung möglich
  • Ermöglicht die Zusendung des Logs oder der DB-Sicherung an eine bestimmte Mailadresse

Nach Befolgung der Installationsanweisungen auf der Homepage erzeugt das Tool regelmäßige Backups in dem gewählten Ordner und ermöglicht durch verschiedene Ordner ein versioniertes Backup, durch das man auch Zugriff auf ältere Versionen einer Datenbank hat.

Alles in allem ein sehr sinnvolles Tool und ich möchte es nicht mehr missen.

Fragen? Probleme? –> Schreib mir!

ftplicity: inkrementelle Backups sicher ablegen

ACHTUNG: Die in diesem Artikel besprochenen Versionen sowohl von ftplicity als auch duplicity sind bereits veraltet. Die grundsätzlichen Erklärungen sind zwar weiterhin valid, aber die Syntax oder Konfigurationsparameter könnten sich geändert haben. Bitte verwendet den Such-Tag “duplicity” bzw. den Such-Tag “ftplicity” und die Kommentare, um aktuelle Informationen zu finden.

Nachdem ich durch einen Beitrag von Matthias wieder mal erinnert wurde, dass nicht Jeder Backups macht bzw. sie aktuell hält, dachte ich, dass ich mal kurz einen Teil meiner Backuplösung vorstelle:

Vorteile

In einem (schon älterem) Artikel der c’t (13/2006) wurde ein Tool vorgestellt mit dem man eine einfache und sichere Backup-Strategie für z.B. Root-Server fahren kann. Das Tool heißt ftplicity und ist im Prinzip nur ein Wrapper für das umfangreichere duplicity. Wie der Name schon sagt, kann möchte ftplicity nur via FTP kommunizieren, denn dies ist laut c’t (und auch meiner Erfahrung nach) der häufigste und simpelste Weg einen Backupspace zu erreichen.

Nun beseitigt ftplicity bzw. das dahinterliegende duplicity gleich mehrere Probleme, die bei dem “plain old Dir-to-FTP-sync” enstehen:

  • Übertragungsqualität: FTP tendiert bei längeren durchgehenden Übertragungen (= eine große Datei) zu Fehleranfälligkeit und der ganze Upload muss noch einmal begonnen werden oder (was viel schlimmer ist) die Backupdatei ist zerstört/ fehlerhaft und lässt sich im Ernstfall nicht mehr richtig wiederherstellen.

    Lösung: kleine Dateien übertragen durch Erstellung von Volumes

  • Vertraulichkeit: Wer einen zweiten Server mit guter Anbindung hat braucht sich um diesen Punkt nicht zu sorgen, aber alle anderen, die entweder etwas Platz bei einem Bekannten in Anspruch nehmen oder von Ihrem Provider einen gewissen Platz an FTP-Space zur Verfügung gestellt bekommen (z.B. Strato, Hetzner) müssen sich schon fragen, ob denn der jeweilige Serveradmin nicht nachts mal aus Interesse sich durch das Mailbackup wühlt.

    Lösung: Verschlüsselung der Daten mittels GPG

  • Authentizität: Das oben genannte Problem wirft ebenfalls die Frage auf, wie weit man den so gesicherten Daten noch vertrauen kann, wenn “Unbekannte” auf die Daten Zugriff hatten. Nichts wäre wohl schlimmer, als dass man sich mit dem Restore auch gleich eine passwd-Datei mit neuen SSH-Usern runterzieht (nette Idee, btw).

    Lösung: Die Signatur der Daten mittels GPG, welche auch beim Restore geprüft werden.

  • Datenvolumen: Je mehr Daten man gesichert hat, desto leichter findet ein Restore statt. Allerdings nimmt damit auch das Übertragungsvolumen zu, was erstens mehr Backupzeit kostet und zweitens in den meisten Hosterverträgen auch begrenzt ist.

    Lösung: Inkrementelle Backups (nur geänderte Daten) unter Nutzung der erprobten rsync-Bibliothek

Diese Probleme werden also von der hier vorgestellten Lösung bereits vermieden. Aber – richtig eingerichtet – kann es noch mehr:

Weitere Vorteile

  • Einzelrestore: Wer kennt das nicht: Schnell mal die Config vom Mailserver bearbeitet und statt die alte Zeile auszukommentieren löscht man sie… und siehe da, rien ne va plus! Der Mailserver startet nicht mehr und man kann sich partout nicht mehr an die besagt Zeile erinnern. Wohl dem, der ein Backup von den Configdateien hat und noch wohler dem, der nicht das ganze Backup wiederherstellen muss, um die Einzeldatei zu erhalten.

    Lösung: ftplicity besitzt einen Befehl, mit dem man Einzeldateien oder -ordner an einen beliebigen Ort wiederherstellen kann

  • Versionierung: Manchmal wäre es schön, wenn man eine Datei nicht nur in dem Zustand des nächtlichen Backups erhielte, sondern sich auch mal die Config ansehen könnte, wie sie vor zwei Wochen war.

    Lösung: Ein Argument des oben erwähnten Befehls ermöglicht es, ein Datum oder einen Zeitraum für die wiederherzustellende Datei anzugeben.

So, als ich diese Punkte damals alle las, war für mich klar: Das will ich haben! Wenn es DIR jetzt auch so geht, dann lies jetzt weiter, denn ein kleines Howto folgt. ftplicity: inkrementelle Backups sicher ablegen weiterlesen