Hintergrund:
Da ich ein ziemlicher Feigling bin, habe ich bisher ddganze Dateisysteme für Backups verwendet. Der größte Nachteil war der übermäßige Speicherverbrauch für diese vollständigen Backups (die leider auch freie Blöcke enthielten).
Frage
Ich möchte jetzt nur die Dateien innerhalb des Dateisystems sichern, aber dennoch in der Lage sein, das Dateisystem bei Bedarf neu zu erstellen. Obwohl die Daten leicht extrahiert werden können (z. B. über rsync -a),
frage ich mich, ob es einige gibtFälleIch überseheWozum Beispiel dieWäre die der Datei zugewiesene Inode-Nummer von Bedeutung?
Dies gilt insbesondere vor dem Hintergrund der Sicherung des /Root-Dateisystems mit dem darauf befindlichen System. Ich mache mir nicht so viele Sorgen um das /home/Dateisystem, aber wäre ich einfallsreich genug, um anzunehmen, dass beim Wiederherstellen des Root-Dateisystems etwas Seltsames passieren könnte /und sich die Inodes plötzlich geändert haben?
Eine gute Antwort würde eine möglichst umfassende Liste der Fälle enthalten, in denen die Inode-Nummer eine Rolle spielen und letztendlich Probleme verursachen könnte.
aktualisieren Einige Experimente zeigen, dass zum Beispiel dieHardlinks(die natürlich auf denselben Inode verweisen) erfordern möglicherweise etwas Aufmerksamkeit. Ich bin mir nicht sicher, ob ihnen unbedingt derselbe Inode neu zugewiesen werden muss.
Glücklicherweise beträgt die Anzahl der Hardlinks auf einem einfachen Ubuntu 12.04 hier nur etwa 10 Dateien (so dass ich sie per Skript aufzeichnen und bei Bedarf reparieren kann und rsync -amir die Inode-Nummer egal ist).
Beispiel Ein Fall, den ich für wichtig halte, ist der Fall vonselinuxSicherheitsmodul, da es grundsätzlich Inode-Nummern verwendet. Dies ist also bereits ein Fall, aber vielleicht gibt es noch andere.
Update 2:
Ich habe gerade einen Test durchgeführt, bei dem ich ein Dummy-System mit Ubuntu 12.04 gesichert und wiederhergestellt habe, rsync -aHwährend ich zwischendurch die Partition neu formatiert habe, um ein neues ext4 einzurichten mkfs.ext4 /dev/sdX -U oldfsUUID. Im Wesentlichen waren beim Wiederherstellen der Dateien alle am häufigsten verwendeten Inodes nicht mehr mit den ursprünglichen verknüpft. Glücklicherweise scheinen die Inodes in diesem einen Fall meines Ubuntu 12.04-Setups keine Rolle gespielt zu haben. Mir ist bewusst, dass dies nicht viel beweist. Ich würde mich trotzdem über eine Antwort mit einer Liste problematischer Fälle freuen. Den habe selinuxich bereits erwähnt, aber ich denke, es gibt noch mehr und daher besteht die Chance auf eine gute Antwort von jemandem, der sich auskennt.
Antwort1
Inode-Nummern spielen für normale Anwendungen keine Rolle. Dies liegt zum Teil daran, dass Inode-Nummern kaum Verwendung finden, und zum Teil daran, dass eine Anwendung, die von Inode-Nummern abhängig ist, nach einem Backup- und Wiederherstellungszyklus nicht mehr funktionieren würde. Backup-Systeme stellen die Inode-Nummern also nicht wieder her, Anwendungen sind also nicht von ihnen abhängig und Backup-Systeme müssen die Inode-Nummern daher nicht wiederherstellen.
Die meisten Backup-Ansätze könnten nicht einmal Inode-Nummern wiederherstellen. Der Dateisystemtreiber im Kernel verwendet beim Erstellen einer Datei jeden freien Inode. Es gibt keine Möglichkeit, dies von Anwendungen aus einzuschränken.
Einige Dateisysteme haben nicht einmal Inode-Nummern.
Anwendungen verwenden Inode-Nummern unter anderem, um zu testen, ob zwei Pfade dieselbe Datei bezeichnen: Sie vergleichen die Gerätenummer und die Inode-Nummer zu einem bestimmten Zeitpunkt. Die Gerätenummer und die Inode-Nummer müssen hierfür nicht über die Zeit konstant bleiben. Backup-Programme selbst tun dies, um Hardlinks zu erkennen.
Es gibt keine Möglichkeit, eine Datei anhand ihrer Inode-Nummer zu öffnen oder eine Datei anhand ihrer Inode-Nummer über einen Pfad zu erreichen (außer Debugging-Tools, die Zugriff auf das zugrunde liegende Blockgerät benötigen). Auf den meisten Dateisystemen zeigt der Pfad auf den Inode, aber der Inode enthält keinen Zeiger auf das Verzeichnis, das die Datei enthält. Dies könnte also nicht implementiert werden, ohne das gesamte Dateisystem zu durchlaufen. Außerdem könnte die Datei sogar gelöscht werden (d. h. sie könnte einen Hardlink-Count von 0 haben und darauf warten, geschlossen zu werden, bevor ihr Inhalt gelöscht und ihr Inode freigegeben wird).
SELinux verwendet Inodes, um Kontexte zu verfolgen, nicht Inode-Nummern. SELinux-Kontexte werden wie alles andere in Pfaden gespeichert.
rsync -AHXist eine sichere und gängige Methode zum Erstellen von Backups.
Mir fällt eine Anwendung ein, die Inode-Nummern verwendet: Einige Versionen vonSchurke, eines der ersten Terminal-basierten Vollbildspiele, das die Curses-Bibliothek inspirierte, die noch heute verwendet wird. Es speichert die Inode-Nummer in einer Sicherungsdatei, um das zufällige Kopieren von Sicherungsdateien zu verhindern. Ich habe das noch nie in einer „seriösen“ Anwendung gesehen.