[snip]

...

rsync -azrulHpogtv --exclude '/proc/' --rsh="ssh -l root" \ root@rechner:/ backupverzeichnis

Das funzt so weit prächtig, allerdings wird nicht alles aus /dev mitgenommen, rsync beschwert sich hier über nicht reguläre Dateien.

Die Dateien in /dev sind ja auch keine regulären Dateien, die man sichern müßte. Eigentlich solltest du /dev überhaupt nicht sichern.

Oder hast du einen besonderen Grund, wieso du die sichern mußt?

Gruß,

Sebastian

Gibt es denn hier nicht die Möglichkeit, die komplette Festplatte inklusive der Devices zu sichern? Sowas wäre doch ganz Sinnvoll wenn die Platte mal defekt ist, einfach Sicherung zurückspielen und fertig is, oder nicht? Gruß Jörg Monka

Am 10 May 2003 um 17:54 hat Frieder Simmeth geschrieben:

Am Samstag, 10. Mai 2003 17:46 schrieb jmmailing@freenet.de:

...

Gibt es denn hier nicht die Möglichkeit, die komplette Festplatte inklusive der Devices zu sichern? Sowas wäre doch ganz Sinnvoll wenn die Platte mal defekt ist, einfach Sicherung zurückspielen und fertig is, oder nicht?

ja, nur sind die device files iirc nicht wirklich auf der fesplatte, das /dev dateisystem wird vom kernel gemacht und somit ist es im normalfall reichlich sinnlos die zu sichern. ähnlich wie /proc.

Frieder

Dann kann man sich das /boot Directory auch sparen, was ja auch wahrscheinlich ziemlich Sinnlos wäre. Was ist denn eigendlich mit Rückverlinkungen, erkennt rsync die Schliefen. z.b ein Link der in Rootdirectory zurückführt? Jörg Monka

Hallo, * Christian Schoepplein schrieb am 10.Mai.2003:

On Sam, Mai 10, 2003 at 06:13:30 +0200, jmmailing@freenet.de wrote:

...

Am 10 May 2003 um 17:54 hat Frieder Simmeth geschrieben:

...

Am Samstag, 10. Mai 2003 17:46 schrieb jmmailing@freenet.de:

...

...

...

Gibt es denn hier nicht die Möglichkeit, die komplette Festplatte inklusive der Devices zu sichern? Sowas wäre doch ganz Sinnvoll wenn die Platte mal defekt ist, einfach Sicherung zurückspielen und fertig is, oder nicht?

...

...

ja, nur sind die device files iirc nicht wirklich auf der fesplatte, das /dev dateisystem wird vom kernel gemacht und somit ist es im normalfall reichlich sinnlos die zu sichern. ähnlich wie /proc.

Naja, in /dev liegen zwar keine wirklichen Files, aber irgendwas wird da schon auf Platte gespeichert sein, schließlich wir nicht alles vom Kernel erzeugt wie in /proc.

Als erstes ist /dev selber ein ganz normales Verzeichnis, mit ganz normale Einträge. Diese Einträge sind, abgesehen von ein paar wenige Unterverzeichnisse und Symlinks, Gerätedateien. Gerätedateien belegen auf der Platte, ähnlich wie Named Pipes, Symlinks und wahrscheinlich auch Sockets, nur eine I-Node. Verzeichnisse und nichtleere normale Dateien belegen neben der I-Node noch Datenblöcke. In der I-Node stehen alle Verwaltungsangeben, wie die drei Zeiten, die Rechte, Besitzer und Gruppe, Dateigröße und Anzahl der Hardlinks. Bei den normalen Dateien und den Verzeichnissen steht darüberhinaus noch die Adressen der Datenblöcke, in denen sich die wirklichen Daten befinden. Dort befinden sich dann auch nur die Daten und sonst nichts. Bei Verzeichnisse sind dies die Namen der Einträge und die dazugehörigen I-Node-Nummern. In den Gerätedateien, um die es hier geht, stehen noch Major- und Minor-Device-Number, die zusammen mit dem Gerätetype (Block- oder Characterdevice) eine eindeutige Kennung ergeben, die wiederum der Kernel versteht. Hier tritt der Kernel ins Spiel. Aber die Dateien sind völlig real. So etwa ist eine Partiton eine Blockdevice, da eine Partiton Blockweise beschrieben wird. Die erste Primäre Partition am ersten IDE-Controler heißt allgemein /dev/hda1 und hat die Majordevicenumber 3 und die Minordevicenumber 1. Wenn nun diese Partiton eingebunden werden soll, so weiß der Kernel erst mal nicht, was /dev/hda1 sein soll. Aber es ist eine normale Dateiadresse, damit kennt sich der Kernel aus. Und da kann er nachschauen und weiß nun die Devicenumber und damit kann er was anfangen. Es ist genausogut möglich eine Datei /tmp/blumenkohl vom Type Blockdevice anzulegen und ihr die Majordevicenummer 3 und die Minordevicenummer 1 zu geben. Dann kann man sein Verzeichnis auch auf /tmp/blumenkohl einbinden und es ist das gleiche als bände man es auf /dev/hda1 ein. Ich brauche wohl nicht zu erwähnen, daß man es trotzdem nicht machen sollte. Bei /proc hingegen ist es anders. Dort wird das ganze Dateisystem vom Kernel generiert. Das ganze Dateisystem ist somit virtuell. Das einzig reale ist der Mountpoint, der aber beim mounten, wie jeder andere Mountpoint auch, vom gemounteten überschrieben wird. Vom Mountpoint wird nur der Name genommen.

...

Dann kann man sich das /boot Directory auch sparen, was ja auch wahrscheinlich ziemlich Sinnlos wäre.

Nein! In /boot liegen wirkliche Files, z.B. der Kernel oder die Dinge die der Bootmanager grub benötigt usw. Das _muss_ man unbeidngt mitsichern, wenn man einen Rechner komplett sichern möchte und /boot lässt sich auch problemlos kopieren, packen oder sonst was.

ACK Und /dev sollte auch gesichert werden. Bernd -- Was ist quoten? Quoten ist das Zitieren aus einer mail, der man antwortet. Und wie macht man es richtig? Zitate werden mit "> " gekennzeichnet. Nicht mehr als nötig zitieren. Vor den Abschnitten das Zitat, auf das man sich bezieht, mit einer Zeile Abstand oben und unten. |Zufallssignatur 12

On Sam, 10 Mai 2003 at 17:54 (+0200), Frieder Simmeth wrote: Deine Shift-Taste klemmt.

Am Samstag, 10. Mai 2003 17:46 schrieb jmmailing@freenet.de:

...

Gibt es denn hier nicht die Möglichkeit, die komplette Festplatte inklusive der Devices zu sichern? Sowas wäre doch ganz Sinnvoll wenn die Platte mal defekt ist, einfach Sicherung zurückspielen und fertig is, oder nicht?

ja, nur sind die device files iirc nicht wirklich auf der fesplatte, das /dev dateisystem wird vom kernel gemacht und somit ist es im normalfall reichlich sinnlos die zu sichern. ähnlich wie /proc.

/dev sind natürlich _richtige_ Dateien, die auch auf der Festplatte liegen! Und die werden auch vom System benötigt. Was Du meinst, ist /dev/fd, da liegen die Dateideskriptoren der geöffneten Dateien drin. Ein Komplett-Backup muss /dev mitnehmen, sonst scheiterts beim Restore schon an der fehlenden Konsole. Das kannst Du auch testen, indem Du mal von CD bootest und Dir dann die / Partition der Festplatte anschaust. Jan

Hi! On Sat, 10 May 2003, Christian Schoepplein wrote:

Hi!

On Sam, Mai 10, 2003 at 05:25:12 +0200, Sebastian Helms wrote:

...

* Christian Schoepplein schrieb am 10 May 2003:

...

Ich möchte eine Linuxkiste vollständig übers Netzwerk in ein Verzeichnis auf meiner Platte sichern, also nicht nur ein paar einzelne Verzeichnisse sondern das ganze System. Dazu habe ich bis jetzt folgendes ausprobiert:

rsync -azrulHpogtv --exclude '/proc/' --rsh="ssh -l root" \ root@rechner:/ backupverzeichnis

Das funzt so weit prächtig, allerdings wird nicht alles aus /dev mitgenommen, rsync beschwert sich hier über nicht reguläre Dateien.

Die Dateien in /dev sind ja auch keine regulären Dateien, die man sichern müßte. Eigentlich solltest du /dev überhaupt nicht sichern.

Oder hast du einen besonderen Grund, wieso du die sichern mußt?

Das die Files in /dev/ keine wirklichen Dateien sind, weiß ich. Nur warum lassen sie sich dann mit cp -a kopieren und nicht mit rsync?

Read the Fine Manual ;-) - die man page zu rsync sagt zum Thema "devices": -D, --devices This option causes rsync to transfer character and block device information to the remote system to recreate these devices. This option is only avail- able to the super-user.

Gut, ich könnte tar nehmen, alles mit gzip packen und es dann übers Netz rüberschaufeln usw., aber irgendwie verstehe ich diese Problematik mit rsync trotzdem nicht wirklich...

Ich hab' mit tar beim Erstellen kompletter System-Images bisher gute Erfahrungen gemacht - auch übers Netz: ssh host "cd /dir && tar c . | gzip -9 ; sleep 30s" >image.tgz (Der sleep-Aufruf soll verhindern, dass die Verbindung abgebrochen wird, bevor alle Daten rübergeschaufelt sind - dummes ssh-Problem...) Gruß Martin

On Mon, 12 May 2003, Christian Schoepplein wrote:

Bei Backups mit tar ist mir allerdings aufgefallen, dass Sockets nicht mitgenommen werden:

# tar czf dev.tar.gz /dev/ tar: Removing leading `/' from member names tar: /dev/log: socket ignored

Leider kann ich die Dienste auf dem Rechner nicht stoppen, während ich ein Backup mache und z.B. postfix verwendet sehr viele Sockets während es läuft... Macht das was, wenn die diversen Sockets nicht mitgesichert werden?

Soweit ich das verstanden habe, weren Socketnamen nicht "real" im Dateisystem abgespeichert, sondern dynamisch erzeugt und entfernt (ähnlich den Einträgen im /proc-Dateisystem); daher *kann* tar (oder auch rsync) sie garnicht sichern! (I could be wrong...)

Bei postfix weiß ich, dass diese bei einem Neustart des Dienstes wieder angelegt werden, jedenfalls sind mir noch keine Probleme aufgefallen, aber kann man davon bei allen Deinsten ausgehen?

Ich installiere regelmäßig komplette Systeme von einem Tar-Schnappschuss - mit Sockets gab's da noch nie Probleme.

Und wie siehts mit diesem log unter /dev/ aus? Für was ist das eigentlich?

Das ist der Socket, über den man den Syslog Daemon anspricht. Gruß Martin