Wer hat sie nicht schon mehr als genug gehört, die gutgemeinte Litanei vom Anlegen eines Backups. In der Firma oder an der Uni mag man dieses leidige Thema mit einiger Berechtigung auf die dortigen Systemadministrator(inn)en abwälzen, doch was ist mit dem Datenbestand zu Hause?

Ein Bandlaufwerk hat dort nur selten jemand, ein Backup auf CD erfordert einen CD-Brenner, und wenn nicht ständig ein Rohling im Laufwerk steckt, ist an Automatisierung ohnehin nicht zu denken. Datensicherung auf Diskette? Das macht man vielleicht mit den Briefen ans Finanzamt, aber kaum mehr mit der 100-seitigen Diplomarbeit und den auf mehrere MByte angewachsenen E-Mail-Wechseln mit verflossenen Lieben.

Lagerstrategien

Bei den heute gängigen Festplattengrößen lässt sich sicher eine dedizierte Partition abzwacken und ausschließlich als Sicherungsplatz nutzen. Schlecht, wenn die Harddisk die ewigen Cyber-Gründe heimsucht, aber besser als gar nichts.

Besser ist da schon eine zweite Platte – selbst mit dem sechs Jahre alten GByte aus dem ausrangierten Rechner kommt man ein gutes Stück weit. Solange der Computer nicht gestohlen wird oder in Flammen aufgeht, ist das gar nicht mal so schlecht.

Keinesfalls zu unterschätzen ist jedoch die (sicherere) Alternative, den Altrechner erst gar nicht einzumotten, sondern zum persönlichen Backup-Schrank zu deklarieren. Natürlich kann es auch das Notebook sein, auf dem aufhebenswerte Daten immer in Zweitausfertigung liegen. Mehr als ein kleines LAN ist dazu nicht von Nöten.

Doch dank Flat-Rates, ADSL & Co. ist selbst der Account im Institut oder der Internetrechner der Freundin ein geeigneter Lagerplatz für ausgewählte Daten. Wer nicht seine gesamte Zwei-GByte-Installation weg sichern will (im Zweifelsfall steht nach dem nächsten Platten-Crash ohnehin ein Update auf SuSE oder Red Hat 13.7 an), sondern sich auf handoptimierte Konfigurationsdateien und the best of $HOME beschränkt, der oder die kann sich vermutlich selbst ein Backup über ISDN oder Modem vorstellen.

Bei solch ketzerischen Aussagen wird jede pflichtbewusste Systemadministratorin natürlich Zeter und Mordio schreien, doch Hand auf’s Herz: Sich in eine ordentliche Backup-Software einzuarbeiten, haben Sie bislang nicht geschafft, und wenn doch, dann sichert die jedenfalls nicht den Freizeitrechner. Sollten Sie zu den löblichen Ausnahmen gehören, stellt sich die Frage, wann Sie das letzte Mal geprüft haben, ob sich Ihr Backup auch tatsächlich wieder zurückspielen lässt…

Backup oder Datenabgleich?

Suchen wir daher nach einer vielleicht nicht ganz so sicheren, dafür aber besser handhabbaren Alternative. Ordentliche Backups werden meist als so genannte inkrementelle Backups ausgeführt. Das heißt, dass einmal (oder besser in regelmäßigen Abständen) eine vollständige Sicherheitskopie aller Daten gezogen wird und zwischen zwei Voll-Backups jeweils nur die Unterschiede zur vorigen Version.

Zudem werden die Backup-Medienrotiert, so dass man, wenn sich eines im Nachhinein als kaputt oder anderweitig unbrauchbar heraus stellt, hoffentlich auf die nächst ältere Sicherungskopie zugreifen kann.

Auf unsere häuslichen Daten angewandt, ist das natürlich ebenfalls der Idealzustand, aber für die Rotation wären für unser Sicherung-auf-Festplatte-Ansinnen mehrere Platten oder gar Rechner von Nöten. Das Stichwort “inkrementell” hingegen hat für uns durchaus seinen Reiz – schließlich wollen wir nicht jedes Mal auch die Daten neu sichern, die sich gar nicht geändert haben.

Wer seine Dateien in verschiedenen Bearbeitungsversionen parat haben will, löst dieses Problem allerdings nicht über ein inkrementelles Backup, sondern besser über eine Versionskontrollsoftware wie cvs, sodass wir uns mit einer Situation zufrieden geben, wo auf dem Zielsystem genau die Daten liegen, die vor dem Datenabgleich in den Quellverzeichnissen zu finden waren – nicht mehr, aber auch nicht weniger.

Was wir also wollen, ist ein simples Spiegeln der Daten, am besten über’s Netz und daher möglichst auf einem Weg, auf dem die Daten und vor allem das Passwort verschlüsselt werden. Damit ein einfaches Zurückspielen der Daten möglich ist, sollen sich in den Zielverzeichnissen keine Dateien ansammeln, die aus den Quell-Directories schon einmal gelöscht wurden. Das bedeutet zwar, dass wir vor jedem Datenabgleich sicher sein müssen, dass alle vorangegangenen Löschaktionen in Ordnung gingen, doch das ist der Preis für nicht rotierende Backup-Medien.

Je nach Kapazität auf dem Zielsystem, Ausbau der Netzanbindung zwischen den beiden Rechnern und der persönlichen Bewertung, welche Daten überhaupt sicherungswürdig sind oder dem Zielrechner anvertraut werden dürfen, geht es jetzt an die Auswahl der zu sichernden Verzeichnisse – und an die Suche einer geeigneten Software.

Eine Frage der Software

Läuft auf dem Zielsystem ein FTP-Server, kann man den natürlich nutzen, doch überträgt man damit Passwort und Daten im Klartext über’s Netz. Zudem sind FTP-Client-Programme von sich aus selten in der Lage, nur die auf dem Client-Rechner neueren Daten auf den Ziel-Server zu übertragen, vom automatischen Löschen in den Quellverzeichnissen nicht mehr vorhandener Daten ganz zu schweigen. Wer trotzdem unbedingt FTP will, muss auf sogenannte Mirror-Software einschwenken, und da kann man eigentlich gleich ein richtiges Backup-Programm nehmen.

Das Secure Coopy-Programm scp, das mit der Linux-Version der Secure Shell oder ihrem Open-Source-Pendant “OpenSSH” mitgeliefert wird, ist da schon geeigneter – hier gehen alle Daten verschlüsselt über’s Netz. Ein SecureShell-Server, der Daemon sshd, gehört ohnehin auf jeden Internet-Rechner, auf dem man nicht nur von der lokalen Konsole aus arbeiten will. Dennoch gilt ein Teil der Kritik an FTP-Clients auch für scp: Für einen Datenabgleich ist es nicht zu gebrauchen.

Wer sich schon ein wenig länger mit Unix beschäftigt, mag sich erinnern, dass das unverschlüsselte Pendant zu scprcp heißt. Dass dieses keinen Datenabgleich durchführen kann, hat mehrere Leute geärgert, darunter auch Paul Mackeras und den eher von Samba bekannten Andrew Tridgell. Und weil deren rcp-Ersatz namens rsync auch den verschlüsselten Datenabgleich über ssh beherrscht, lohnt sich ein Gang zu http://rsync.samba.org/rsync/download.html, sofern die Distribution oder http://rpmfind.net/linux/rpm2html/search.php?query=rsync kein passendes Paket mitliefert.

man entziffert

Ein man rsync erschlägt zunächst damit, dass im Kapitel SYNOPSIS sämtliche Kombinationen von Datenübertragungsmöglichkeiten schematisch präsentiert werden:

rsync [OPTION]… SRC [SRC]… [USER@]HOST:DEST
 rsync [OPTION]… [USER@]HOST:SRC DEST
 rsync [OPTION]… SRC [SRC]… DEST
 rsync [OPTION]… [USER@]HOST::SRC [DEST]
 rsync [OPTION]… SRC [SRC]… [USER@]HOST::DEST
 rsync [OPTION]… rsync://[USER@]HOST[:PORT]/SRC [DEST]

Wie bei der in Manpages verwendeten Backus-Naur-Schreibweise üblich, können Optionen in eckigen Klammern weggelassen werden. Die drei Punkte entsprechen nicht so ganz einer wissenschaftlich exakten Nomenklatur, aber es wird klar, was die Autoren sagen wollen: Hier können noch mehr Angaben vom eben beschriebenen Typ stehen (z. B. weitere Optionen).

Ebenso wenig schwierig wie das Entziffern des [OPTION]...-Platzhalters als “eine beliebige Anzahl der weiter unten im Abschnitt OPTIONS SUMMARY aufgelisteten Optionen” ist die Entzauberung von [USER@] (die optionale Angabe eines Benutzernamens und eines anschließenden @) und HOST (die numerische oder textuelle IP-Adresse des entfernten Rechners).

Mit unserer Erwartungshaltung (wir wollen Dateien und Verzeichnisse übertragen) lassen sich SRC und DEST nur als Source-(“Quell-“) und Ziel-(“Destinations”-)Dateien/Verzeichnisse interpretieren. Da wir unsere Daten über das SecureShell-Protokoll übertragen wollen, interessiert uns die letzte Möglichkeit, einen rsync-Server auf dem PortPORT anzusprechen, nicht, sodass wir die letzte Zeile vergessen können.

Wenn im Abschnitt GENERAL dann noch zu lesen steht, dass die beiden Zeilen mit dem zweifachen Doppelpunkt (::) ebenfalls einen rsync-Dämonen erfordern, sind für uns einfach nur die ersten drei Zeilen interessant:

• Lokale Dateien/Verzeichnisse in ein Verzeichnis auf einem entfernten Rechner kopieren.
• Kopien entfernter Daten in ein lokales Verzeichnis packen.
• Lokale Daten in ein anderes lokales Verzeichnis spiegeln.

Alles lokal

Beginnen wir mit dem letzten und einfachsten Fall: Das Verzeichnis ~/artikel soll als Backup auf eine andere, unter /mnt/backup gemountete Partition kopiert werden.

[trish@lillegroenn ~]$ rsync artikel /mnt/backup
 skipping directory /home/trish/artikel/.

Das war wohl nicht gerade eine Kopierorgie: Keine einzige Datei findet sich im Zielverzeichnis /mnt/backup. Da müssen wir wohl oder übel doch nach den Optionen schauen:

Options[…]
  -r, --recursive             recurse into directories

Wer ganze Verzeichnisse samt Inhalt kopieren will, sollte also ein -r oder --recursive mit angeben:

[trish@lillegroenn ~]$ rsync -r artikel /mnt/backup

Der Plattenlärm indiziert zwar, dass da was passiert, doch was ist das?

write failed on artikel/LM/LU0301/ootb/gramofile-3.html : No such file or directory
 unexpected EOF in read_timeout
 unexpected EOF in read_timeout

Ein schnelles df (“disk free”) bestätigt die Befürchtung:

Filesystem           1k-blocks      Used Available Use% Mounted on
 /dev/hda2               643959    610690         5 100% /mnt/backup

Die Partition ist voll! Also löschen wir das missglückte Backup mit rm -rf/mnt/backup/artikel erst einmal vollständig und rekursiv.

Nun heißt es, mit du heraus zu finden, wo die Übeltäter stecken. Damit die tausend Unter- und Unterunterverzeichnisse nicht völlig an uns vorbei rauschen, beschränken wir uns auf die ersten zwei Verzeichnisebenen unterhalb von ~/artikel:

[trish@lillegroenn ~]$ du --max-depth=2 artikel[…]
 1924    artikel/LM/LU0301
 51      artikel/LM/LU0401
 73270   artikel/LM[…]
 84049   artikel/designer/qt-designer2
 234     artikel/designer/qt-designer1
 100112  artikel/designer[…]

Die Zahlen in der ersten Spalte, die Größe der Verzeichnisinhalte in kByte, sind immer noch reichlich unübersichtlich. Der Übeltäter hat ganz sicher mehr als ein MByte Größe, und zum Glück kennt du die Option -m, mit der die Größenangaben in gerundeten ganzen MByte angegeben werden.

Da gibt’s dann eine ganze Menge Nullen für die Verzeichnisse, die kleiner als ein MByte sind. Um nur die größeren Directories angezeigt zu bekommen, lassen wir awk arbeiten:

[trish@lillegroenn ~]$ du -m --max-depth=2 artikel | awk '$1 > 1'[…]
 2       artikel/LM/LU0301
 72      artikel/LM[…]
 82      artikel/designer/qt-designer2
 98      artikel/designer[…]

awk filtert jetzt alle du-Ausgabezeilen heraus, in denen die erste Spalte ($1) größer als 1 ist, und zeigt den Rest erst gar nicht mehr an.

Auf diese Weise haben wir wohl ~/artikel/designer/qt-designer2 als Übeltäter ausgemacht – und da dieses Verzeichnis nur eine zu testende Software enthält, können wir auch auf das Backup derselben verzichten. Mit dem --exclude-Flag sagen wir rsync nun also, dass es auf alle Dateien verzichten soll, die in Pfad oder Dateinamen ein qt-designer2 enthalten. Doch diesmal sind wir vorsichtiger und machen zunächst einen Trockentest mit -n (“nicht wirklich ausführen”):

[trish@lillegroenn ~]$ rsync -rn --exclude "qt-designer2" artikel /mnt/backup

Der Ernstfall ohne die -n-Vorsichtsoption macht dann doch wieder Kummer:

[trish@lillegroenn ~]$ rsync -r --exclude "qt-designer2" artikel /mnt/backup[…]
 skipping non-regular file artikel/designer/qt-designer1/qt-2.2.3/include/qxml.h

Ein Blick mit ls -l auf die verdächtige Datei bringt die Erklärung:

lrwxrwxrwx   1 trish    users          17 Dec 21 05:32 artikel/designer/qt-designer1/qt-2.2.3/include/qxml.h -> ../src/xml/qxml.h

Die besagte Datei ist ein Link, der einfach nicht mitkopiert wurde. Doch auch dem lässt sich abhelfen: mit der rsync-Option -l, bei der symbolische Links erhalten bleiben.

Netterweise erklärt die Manpage im Abschnitt USAGE auch noch, dass die Archiv-Option -a sowohl rekursiv kopiert, Links beibehält und auch sonst Attribute, Rechte, die Eigentümer-Angaben, aber auch eventuelle Gerätedateien nicht verändert. Genau sowas wollen wir für’s Backup! Ganz nebenbei lernen wir hier noch um die Geschwätzigkeitsoption -v, die wir von nun an auch in unseren Tests verwenden wollen.

Ein Problem besteht weiterhin: Wenn wir nicht darauf achten, dass einmal im Quellverzeichnis gelöschte Dateien auch aus dem Backup verschwinden, läuft Viellöschern irgendwann die Backuppartition voll. Ganz abgesehen davon ist es im Falle eines wirklich benötigten Backups lästig, nach dem Zurückspielen der Daten erst noch all die Dateien auszumisten, die man ohnehin schon längst weggeworfen hatte.

Die entsprechende rsync-Option, die all das auf Zielseite löscht, was auf Quellseite nicht mehr vorhanden ist, heißt --delete. Machen wir also ein Vollbackup, benennen dann testhalber eine Datei aus ~/artikel um und sehen, was passiert:

[trish@lillegroenn ~]$ rsync -av --exclude "qt-designer2" artikel /mnt/backup[viele Dateien]
 artikel/LM/LU0401/Answergirl_0401.html[viele Dateien]
 [trish@lillegroenn ~]$ mv artikel/LM/LU0401/Answergirl_0401.html !#:1_neu 
 mv artikel/LM/LU0401/Answergirl_0401.html artikel/LM/LU0401/Answergirl_0401.html_neu
 [trish@lillegroenn ~]$ rsync -av --delete --exclude "qt-designer2" artikel /mnt/backup
 building file list … done
 artikel/LM/LU0401/
 deleting artikel/LM/LU0401/Answergirl_0401.html
 artikel/LM/LU0401/Answergirl_0401.html_neu
 artikel/LM/LU0401/
 wrote 43868 bytes  read 32 bytes  29266.67 bytes/sec
 total size is 26953280  speedup is 613.97

rsync berichtet pflichtschuldigst, die in ~/artikel/LM/LU0401 nicht mehr vorhandene Datei Answergirl_0401.html auch in /mnt/backup/artikel/LM/LU0401 zu löschen (“deleting“) und dafür die neue Datei Answergirl_0401.html_neu neu anzulegen.

Denjenigen, die sich an das Answer-Girl aus Heft 12/2000 erinnern, kam sicher das !#:1 in der Zeile mit dem mv-Kommando bekannt vor: Mit !# sagen wir der Bash, dass sie stattdessen alles, was bislang auf dieser Kommandozeile steht (also mv artikel/LM/LU0401/Answergirl_0401.html) einsetzen soll. Dank :1 sind wir etwas wählerischer und weisen die Shell an, sich auf Argument Nr. 1 (also das zweite Argument artikel/LM/LU0401/Answergirl_0401.html) zu beschränken.

Wer gern auf Nummer sicher geht und von allen veränderten Dateien (also auch den gelöschten) im Backupverzeichnis eine Sicherheitskopie behalten will, wird sich vermutlich mit der rsync-Option -b anfreunden. Die ersetzt zwar keine Versionsverwaltung, kann aber nicht nur für Feiglinge interessant sein. Standardmäßig erhalten die Backupdateien eine Tilde hinten am Dateinamen angehängt.

Auf in die Ferne!

Viel mehr brauchen wir nicht, wenn wir uns auf das lokale Spiegeln von Daten beschränken. Doch sicherer ist eine Kopie auf einem anderen Rechner allemal. Wenn wir uns an die Synopsis erinnern, war das von rsync-Seite auch ganz einfach zu bewerkstelligen: Wenn sich die Usernamen auf Quell- und Zielrechner unterscheiden, muss letzterer mit einem nachstehenden @ vor der Adresse des Remoterechners angegeben werden. Am Schluss kommt noch ein Doppelpunkt hin, hinter dem das Zielverzeichnis stehen kann – oder nichts, wenn wir mit dem entfernten Homeverzeichnis zufrieden sind:

[trish@lillegroenn ~]$ rsync -av --delete artikel pjung@backup.linux-user.de:

Da auf dem Remoterechner hoffentlich keine r-Dienste laufen, sollte es eine Fehlermeldung geben. Via SecureShell sind wir da besser dran, vorausgesetzt, auf backup.linux-user.de läuft ein sshd. Um rsync zum Übertragen via SecureShell zu bewegen, gibt es die Optionen -e (“execute”) oder --rsh (“Ersatz für rsh“). Die erste will das ssh-Kommando nach einem Leerzeichen, letztere nach einem Gleichheitszeichen (--rsh=ssh) sehen:

[trish@lillegroenn ~]$ rsync -av --delete -e ssh artikel pjung@backup.linux-user.de:

Sollte Ihr ssh-Kommando nicht im Suchpfad liegen, müssen Sie natürlich den vollständigen Pfad mit abgeben, z.B. -e /usr/local/bin/ssh.

Sie möchten das artikel-Verzeichnis auf dem Zielrechner nicht direkt unterhalb von pjungs Homeverzeichnis anlegen? Dann müssen wir auch das Zielüberverzeichnis explizit angeben, etwa:

[trish@lillegroenn ~]$ rsync -av --delete -e ssh artikel pjung@backup.linux-user.de:~/backup

Der USAGE-Manpage-Abschnitt verriet, wenn Sie sich erinnern, noch, dass die Daten mit -z komprimiert übertragen werden. Das spielt nun, da unsere Daten über’s Netz gehen, durchaus eine Rolle, weshalb wir diese Option einfügen, ehe wir tatsächlich die Entertaste betätigen:

[trish@lillegroenn ~]$ rsync -avz --delete -e ssh artikel pjung@backup.linux-user.de:~/backup
 pjung@backup.linux-user.de's password: [Passworteingabe]
 building file list … done

Besser mit Skript

Diesen ganzen Rattenschwanz immer wieder einzutippen – dazu sind wir doch viel zu faul. Wer mehrere Verzeichnisse oder sogar einzelne Dateien wie z.B. die Bookmarks des Webbrowsers sichern will, sehnt sich nach einem kleinen Skript, das – einmal geschrieben – womöglich gar von einem Cronjob automatisch abgearbeitet werden kann.

Die zu sichernden Dateien schreiben wir am besten als mit Leerzeichen getrennte Liste in eine Variable namens BACKUPFILES, während entfernter Benutzername, @, die Adresse des Remoterechners, der Doppelpunkt und das Zielverzeichnis in BACKUPTARGET leicht zu ändern sind. Für das Skript-Äquivalent zum Befehl

[trish@lillegroenn ~]$ rsync -avz --delete -e ssh artikel .netscape/bookmarks.html pjung@backup.linux-user.de:~/backup

sehen die Variableninhalte damit so aus wie in Listing 1.

Doch halt – warum fehlt auf backup.linux-user.de im ~/backup-Verzeichnis jetzt das .netscape-Unterverzeichnis, sodass bookmarks.html plötzlich als ~/backup/bookmarks.html vorliegt? Weil wir, wie die rsync-Manpage verrät, die Option -R (“relativ”) vergessen haben, die dafür sorgt, dass auf dem Zielrechner genau dieselben relativen Pfade eingerichtet werden wie auf dem Quellrechner.

#!/bin/sh
 # zu sichernde Dateien und Verzeichnisse, ausgehend
 # vom Homeverzeichnis
 BACKUPFILES="artikel .netscape/bookmarks.html"
 # Backup-Ziel
 BACKUPTARGET="pjung@backup.linux-user.de:~/backup"
 cd  # Wechseln ins Homeverzeichnis
 rsync -e ssh -aRvz --delete $BACKUPDIRS $BACKUPTARGET

Passwortlos

Will man den Datenabgleich beispielsweise über einen Cronjob automatisieren (vgl. “Diener auf die Minute”, LU 12/2000 S. 80ff.), wird die Passworteingabe zum Problem. Es lässt sich lösen, wenngleich Sicherheitsfanatiker/innen ein Auge zudrücken sollten.

Das Stichwort heißt Public-Key-Kryptographie: Man hat ein Schlüsselpaar, von dem man den einen Schlüssel geheim hält und den anderen öffentlich verteilt. Authentifizierung ist nur dann möglich, wenn beide – geheimer und öffentlicher Schlüssel – zusammen kommen. Wie wir der Manpage zu ssh entnehmen können, unterstützt unsere gewählte Übertragungsmethode dies.

Was wir tun müssen, ist, zunächst einmal den Schlüssel für den Rechner zu generieren, der das Backup-Skript ausführt. Beinahe hätten wir’s erraten: Der Befehl dazu heißt ssh-keygen (“ssh-key generation” – Erzeugen des ssh-Schlüssels).

[trish@lillegroenn ~]$ ssh-keygen
 Generating RSA keys:  ………………ooooooO……………..ooooooO
 Key generation complete.
 Enter file in which to save the key (/home/trish/.ssh/identity): [Enter]
 Enter passphrase (empty for no passphrase): [Enter]
 Enter same passphrase again: [Enter]
 Your identification has been saved in /home/trish/.ssh/identity.
 Your public key has been saved in /home/trish/.ssh/identity.pub.
 The key fingerprint is:
 f7:68:22:9f:a3:be:37:7c:7f:92:c2:fb:a1:86:ff:fe trish@lillegroenn.troll.no

Wer seinen geheimen Schlüssel in der vorgeschlagenen Datei ~/.ssh/identity abspeichern will, bestätigt einfach nur mit der [Enter]-Taste, anderenfalls ist ein Dateiname, am besten mit Pfad fällig.

Kritisch wird es bei der Frage nach dem Passwort: Normalerweise würden wir eins setzen, um den privaten Key zu schützen, aber dann müssten wir ja auch wieder eins eingeben – ein unendlicher Kreis. Daher beißen wir diesmal in den sauren Apfel und tippen wiederum nur [Enter]. Auch bei der letzten Bitte um Wiederholung des (nunmehr leeren) Passworts gilt es, nichts als [Enter] einzugeben. Wem der passwortlose Key nicht geheuer ist, kann die Sicherheit immerhin dadurch erhöhen, dass er oder sie des Öfteren einen neuen Key generiert und verteilt.

Den öffentlichen Schlüssel (abgespeichert mit der Endung .pub) nehmen wir jetzt und übertragen ihn auf den Backuprechner – natürlich über SecureShell (also mit scp oder per Copy&Paste, während man mit ssh eingeloggt ist). Er muss jedenfalls in die dortige Datei ~/.ssh/authorized_keys eingetragen werden, z.B. so:

[trish@lillegroenn ~]$ cat ~/.ssh/identity.pub | ssh -v pjung@backup.linux-user.de cat - >> ~/.ssh/authorized_keys

Dieses umständliche Prozedere statt einem einfachen scp ~/.ssh/identity.pub pjung@backup.linux-user.de:~/.ssh/authorized_keys ist nötig, wenn ~/.ssh/authorized_keys auf backup.linux-user.de schon andere Schlüssel beherbergt. Durch das doppelte >> erreichen wir, dass die mit dem zweiten cat ausgegebene Standardeingabe zu ssh (symbolisiert durch ein -) ans Ende von ~/.ssh/authorized_keys angehängt wird.

Woher kommt diese Eingabe für ssh, die diese an das auszuführende Remote-Kommando cat - >> ~/.ssh/authorized_keys weitergibt? Hier ist die Pipe | verantwortlich, die die Ausgabe von cat ~/.ssh/identity.pub ins ssh-Kommando hinein geschubst.

Jetzt heißt es nur noch testen, ob das Skript tatsächlich ohne Passwort funktioniert. Wenn ja, steht einem Backup-Cronjob nichts mehr im Wege.