Schlagwort-Archive: Backup

Dateien mit scp und Key, aber ohne Passphrase übertragen

Schreibe eine Antwort

Man kann scp ganz wunderbar dazu benutzen, um Dateien auf einen anderen Rechner zu übertragen. Allerdings muss man i.d.R. jedes mal das Passwort des Zielbenutzers angeben. Das ist für automatisierte Prozesse ziemlich unpraktisch.
Nun kann man aber auch einen SSH-Key ohne Passphrase erzeugen und diesen auf dem Zielrechner in der authorized_keys des entsprechenden Nutzers hinterlegen. Dann kann zwar nur derjenige User, der im Besitz des privaten Schlüssels ist, ohne Passwort/Passphrase auf diesen Rechner zugreifen, aber ganz so sicher ist das nicht. Allerdings kann man SSH-Keys auch mit einem sog. „forced Command“ verknüpfen, so dass mit diesem Key nur das definierte Kommando ausgeführt wird, unabhängig davon, was auf der Kommandozeile angegeben wurde. Dies geschieht in der authorized_keys auf dem Zielrechner, in dem man in der Zeile mit den entspr. Key vor diesem das gewünschte Kommando angibt, i.d.R. mit weiteren nützlichen Parametern:

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="mache_nur_was_ich_will" ssh-rsa AAAAB3NzaC…

Aber wie muss das Kommando auf der Zielseite bei scp nun aussehen? Das lässt sich herausfinden, in dem man ein normalen scp-Befehl mit den Debug-Parameter -v absetzt. In der Ausgabe findet man u.a. dann so was wie (wenn nicht: siehe unten):

debug1: Sending command: scp -v -t myfile.txt

Hier taucht der undokumentierte scp-Parameter -t auf, der auch nur vom Programm auf der Zielseite verwendet wird. Wenn wir also das folgenden in der authorized_keys angeben, können wir mit den entspr. Key Dateien in das Verzeichnis /var/local/Backups kopieren – mehr nicht!

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="scp -t /var/local/Backups/" ssh-rsa AAAAB3NzaC…

Aber das funktioniert nicht …

Es kann passieren, dass die Verbindung zwar aufgebaut wird, danach aber nichts mehr passiert. Die Verbindung „hängt“, es findet keine Datenübertagung statt.

Die Ursache ist, dass scp ab Version 9.0 standardmäßig das SFTP-Protokoll benutzen. Man erkennt es daran, dass in der oben erwähnten Debug-Ausgabe nicht das erwartete scp -v -t … steht, sondern:

debug1: Sending subsystem: sftp

Man muss scp auf der aufrufenden Seite also mit dem Parameter –O (großes O) dazu zwingen, das SCP-Protokoll zu verwenden.

Siehe auch: https://serverfault.com/a/88864

Tar-Archive vergleichen

Eine Antwort

Ich sichere bestimmte Verzeichnisse von Rechnern täglich in Tar-Archiven (siehe auch „Verzeichnisse auf einen anderen Rechner übertragen“). Nun kommt es vor, dass diese Archive plötzlich oder auch mit der Zeit größer werden. Dann will man natürlich wissen, wieso. Um im ersten Schritt zu vermeiden, dass ich die Archive auspacken und dann vergleichen muss, lese ich den Inhalt zwei Tar-Dateien aus, bereite sie mittels sed auf und vergleiche sie mit diff:

tar tvf 20140822.tgz |  sed 's/^\([a-zA-Z\-]\{1,\}\) \([^[:blank:]]\{1,\}\) \{1,\}\([0-9]\{1,\}\) .* \(.*\)$/\4 \3/' > 20140822.content 
tar tvf 20140901.tgz |  sed 's/^\([a-zA-Z\-]\{1,\}\) \([^[:blank:]]\{1,\}\) \{1,\}\([0-9]\{1,\}\) .* \(.*\)$/\4 \3/' > 20140901.content
diff -y -W 200 --suppress-common-lines 20140822.content 20140901.content > 20140822vs20140901

Sofern sich nicht all zu viele Dateien geändert haben oder dazu gekommen sind, kann das Ergebnis schon erste Hinweise geben. Ansonsten muss man mit den üblichen Werkzeugen (z.B. grep) weiter filtern und analysieren.

Bootfähigen USB-Stick mit FreeDOS erstellen

Schreibe eine Antwort

So, Sicherung eines Windows-Servers mit Hilfe von Drive SnapShot erstellt und auf der mobilen Festplatte in Sicherheit gebracht. Aber wie spielt man das Image bei Bedarf wieder zurück, wenn die Maschine weder CD- noch Disketten-Laufwerk hat? Klar, mit einem bootfähigen USB-Stick.

Einen solchen Stick zu erstellen ist kein Hexenwerk, zumindest nicht unter Windows. Man besorgt sich dazu FreeDOS und das HP USB Stick Storage Format Tool.

Dann entpackt man das freedos.zip in ein beliebiges Verzeichnis. Anschließen steckt man den Stick in den Rechner und startet das HPUSBFW v2.2.3.exe. Das Tool findet den Stick normalerweise von selbst, hat man mehrere USB-Devices angeschlossen muss man ggf. den Stick bei „Device“ auswählen. Als „File system“ muss „FAT“ eingestellt werden, ein „Volume label“ kann man , muss man aber nicht angeben. Bei „Create a DOS startup disk“ wird ein Häkchen gesetzt und bei „using DOS system files located at“ wird das Verzeichnis eingestellt, in den man vorher das freedos.zip entpackt hat. Nach dem Klick auf „Start“ wird man noch darauf hingewiesen, dass aller Inhalt des Sticks verloren geht, dann ist er bootfähige Stick schon fertig.

Nun muss sollte man die restlichen Dateien und das Verzeichnis FDOS auf den Stick kopieren, sonst können später kein USB-Laufwerke angesprochen werden.

Ist die mobile Festplatte dummerweise NTFS formatiert, so muss man noch NTFSDOS auf den Stick kopieren. Hier reichte mir die read-only-Version. Dieses Tool ist, dank der Übernahme von Sysinternals durch Microsoft, im Netz fast vollständig verschwunden, aber bei 404 Tech Support bin ich noch fündig geworden.

Nach dem Booten mit dem Stick ruft man dann NTFSDOS auf, was dann nach einiger Zeit das NTFS-LW der mobilen Platte findet und als Laufwerk D: (oder entsprechend freien LW-Buchstaben) einbindet.

Natürlich muss auch das Programm SNAPSHOT.EXE von Drive SnapShot auf dem Stick sein, damit man das Image zurück spielen kann.

Eine gute Idee ist es, den entsprechenden Rechner auch mal mit dem Stick zu booten, denn nicht jedes Motherboard bootet von jedem Stick.

Quellen:

Dateien eines Jahres archivieren

Schreibe eine Antwort

Heute stand ich (mal wieder) vor der Aufgabe, in einem Verzeichnis alle Dateien vom Vorjahr zu archivieren.

Im Artikel „Dateien an Hand des Datums und der Uhrzeit finden“ habe ich gezeigt, wie man mit find Dateien eines bestimmten Zeitraums finden kann. Da ich aber für die Archivierung keine Rekursion benötige, kann ich das Ganze etwas einfacher mit einem Einzeiler machen:

stat -c '%n Date:%y' * | perl -n -e 'print "$1
" if /^(.+)sDate:2008/' \n | zip archiv_2008.zip -@

Ich verwende hier stat, um das Ausgabeformat bestimmen zu können. Da die Dateinamen Leerzeichen enthalten können, kann ich keine Leerzeichen als Trenner zwischen Name und Datum verwenden, daher die Kennzeichnung mittels „Date:“. Perl filtert mir erstens alle Dateien von 2008 heraus und gibt auch nur den Dateinamen aus. Zip liest diese von der Standardeingabe, wenn die Dateiliste als -@ angegeben ist.

Soll Zip die Dateien auch gleich entsorgen, so kann man das über die Option -m erreichen.

Backup-Differenzen mit rsync feststellen und zurückspielen

Schreibe eine Antwort

Sowas passiert: Platten-Crash! Aber man hatte ja vorgesorgt und ein Platten-Image gezogen und auch immer schön die wichtigsten Dateien und Verzeichnisse in Sicherheit gebracht, z.B. mit dem in „Verzeichnisse auf einen anderen Rechner übertragen“ beschriebenen Verfahren. Das Image ist schnell auf die neue Platte gespielt, aber wie bekommt man nun die aktuellen Backupdateien wieder ins System, ohne sich beispielsweise die neuere LVM-Config zu zerschießen?

Hier kann das Tool rsync sehr hilfreich sein – auch wenn die Daten gar nicht mit rsync gesichert wurden. Zunächst wechselt man in das Verzeichnis, in dem die Backupdateien liegen. Hatte man ein (komprimiertes) Tar-Archiv angelegt, muss dieses in ein temporäres Verzeichnis entpackt werden.

Nun kann der Inhalt dieses Verzeichnisses gegen den wiederhergestellten Rechner verglichen werden:

rsync -rznciuK -e ssh ./ root@meinLinuxPC:/ | grep -v skipp

Durch den Schalter -n werden keine Daten übertragen, sondern nur angezeigt, welche Dateien aus dem Backup neuer sind als auf dem wiederhergestellten System:

  <fcsT.... etc/SnmpAgent.d/snmpd.conf
  <fcsT.... etc/rc.config.d/SnmpHpunix
  <fcsT.... etc/rc.config.d/SnmpMaster
  <fcsT.... etc/rc.config.d/SnmpMib2
  <fcsT.... var/spool/cron/crontabs/root

Zur Bedeutung von <fcsT.... siehe man rsync, –itemize-changes.

Wenn man die Dateien nicht von Hand übertragen will, kann man das auch rsync machen lassen:

rsync -rzciuKb --suffix=~rsync -e ssh ./ root@meinLinuxPC:/ | grep -v skipp

Hier fehlt der Schalter -n, der oben dafür sorgt, dass keine Dateien übertragen werden. Die Optionen -b und --suffix=~rsync sorgen dafür, dass auf dem Zielrechner die Original-Dateien mit dem Suffix ~rsync erhalten bleiben.

Verzeichnisse auf einen anderen Rechner übertragen

2 Antworten

Im vorigen Artikel habe ich gezeigt, wie man mit TAR ein komplettes Verzeichnis so verschieben bzw. kopieren kann, dass alle Rechte erhalten bleiben. Hier kommt nun die erweiterte Fassung zum kopieren von Verzeichnissen auf einen anderen Rechner mittels SSH und TAR. Und als Bonbon gibt’s ein Script zum Erstellen von Backups von anderen Rechnern.

Um das Verzeichnis foo vom eigenen Rechner auf dem Rechner kermit als Unterverzeichnis von /bar zu speichern benutzt man den folgenden Befehl:

tar cpSf - foo | ssh kermit "cd /bar && tar xpSvf -"

Wie man sieht, ähnelt der Aufruf sehr dem Befehl zum kopieren auf dem lokalen Rechner, lediglich das „ssh kermit“ ist neu (und die Klammern brauchen wir hier nicht). Ich gehe hier davon aus, dass der User des lokalen Rechners auch auf dem Rechner kermit bekannt ist. Soll auf kermit ein anderer Account, z.B. klaus, verwendet werden, schreibt man einfach „ssh klaus@kermit“. Der User muss auf jeden Fall ausreichende Rechte im Zielverzeichnis haben. Da ein Ziel ist, die Rechte beizubehalten, sollte das root sein.

Man kann tar die Daten auch komprimieren lassen und bei geringer Bandbreite das Ganze somit beschleunigen:

tar zcpSf - foo | ssh kermit "cd /bar && tar zxpSvf -"

Man kann das Ganze auch umkehren, also Verzeichnisse des entfernten Rechners auf den lokalen kopieren:

ssh kermit tar cSpf - /foo | (cd /bar && tar xpSvf -)

kopiert das Verzeichnis /foo von kermit auf dem lokalen Rechner ins Verzeichnis /bar.

Man kann dem ersten tar-Befehl übrigens auch mehrere Verzeichnisse übergeben. Das eignet sich hervoragend für ein einfaches Backup, insbesondere zusammen mit gzip:

ssh kermit tar cSpf - /foo /bar | gzip -f9 > kermit_backup.tgz

Das sichert die Verzeichnisse /foo und /bar des Rechners kermit als komprimiertes Tar-Archiv in der Datei kermit_backup.tgz auf dem Lokalen Rechner.

Ich mache so täglich Sicherungen von wichtigen Verzeichnissen meiner Server.

Auch hier kann man tar die Komprimierung übernehmen lassen:

ssh kermit tar zcSpf - /foo /bar > kermit_backup.tgz

Diese Variante ist schneller, die andere komprimiert dafür geringfügig besser.