guy.brush
Anmeldungsdatum: 13. Februar 2011
Beiträge: 216
Wohnort: Earth
|
Hallo, ich interessiere mich aktuell dafür, ob es mit rsync auch möglich ist, inkrementelle/differentielle Backups zu machen, ohne Hard Links zu verwenden? Ich synchronisiere aktuell einen Ordner und verwende --backup-dir. Hierbei werden ja gelöschte (und auch, wie ich letztens erst festgestellt habe, veränderte) Dateien in ein --backup-dir-Verzeichnis geschoben werden. Hiermit kann ich fast einen alten Stand wiederherstellen, indem ich das synchronisierte Ziel-Verzeichnis (= Backup) nehme und entsprechend alle Dateien aus dem --backup-dir-Verzeichnis wieder hineinkopiere. Dadurch werden zwar die alten Versionen wie zu Tag X wieder hergestellt, allerdings enthält das Backup dann noch neue Dateien, die es zum Tag X gar nicht gab. (Meine --backup-dir-Verzeichnisse enthalten immer Datum und Uhrzeit.) Verwendet man --compare-dest, so erhält man z.B. differentielle Backups. Allerdings kann man hier Tag X nicht wiederherstellen, weil evtl. zum Zeitpunkt X schon Dateien gelöscht worden sind, die aber noch im Vergleichordner enthalten sind. Gibt es vielleicht noch einen anderen Weg? Viele Grüße guy.brush
|
JensHol
Anmeldungsdatum: 31. Oktober 2017
Beiträge: 322
|
Nur um das zu verstehen: Wenn du jederzeit einen alten Stand sauber wieder herstellen möchtest, ist das Prinzip der Hardlinks ideal: die Dateien belegen Speicherplatz nur inkrementell und du hast den echten Stand zum Sicherungszeitpunkt. Um zu verstehen was du genau willst: warum sind Hardlinks keine Option?!?
|
Hefeweiz3n
Moderator, Webteam
Anmeldungsdatum: 15. Juli 2006
Beiträge: 5813
Wohnort: Ankh-Morpork
|
guy.brush schrieb: ich interessiere mich aktuell dafür, ob es mit rsync auch möglich ist, inkrementelle/differentielle Backups zu machen, ohne Hard Links zu verwenden?
Hast du eventuell zuviel Platz auf deinen Backupplatten? Denn du brauchst für so eine Lösung immer mindestens (Anzahl vorgehaltener Backups) x (durchschnittliche Backupgröße) Platz. Ich halte das für nicht sinnvoll. Dann brauchst du aber auch nicht --backup-dir sondern kopierst einfach immer komplett in einen neuen Ordner. Tatsächlich ist aber das Problem "inkrementelle Backups mit rsync" nämlich ein gelöstes Problem, nutze doch einfach rsnapshot.
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7651
|
@guy.brush Mir ist von deiner Beschreibung auch nicht klar geworden was eigentlich das Problem ist. Es klingt irgendwie so als würdest du beim Backup erstellen dann Verzeichnisse vermischen, das soll man natürlich nicht machen (zumindest nicht, ohne aufzuräumen). Jedes Backup ein neues Verzeichnis (z.B. für jeden Tag eins), und dieses Verzeichnis spiegelt dann genau den Stand X wieder - Dateien die sich nicht verändert haben sind dann Hardlinks aber dat is ja wurscht. Der Witz bei Hardlinks ist ja gerade, man weiß nicht welche Datei das Original ist und welche die Kopie... Backups die du nicht mehr haben willst kannst du dann einfach löschen (ganzes Backupverzeichnis des jeweiligen Tages) und Dateien auf die dann kein Link mehr besteht werden tatsächlich freigegeben. Diese Kopfschmerzen werden da einfach ans Dateisystem ausgelagert. Wenn du mischst hast du am Ende natürlich Quark, also ein Verzeichnis in dem Dateien drin sind, die so nie (gleichzeitig) existiert haben. Wenn du wissen willst welche Dateien in einem Verzeichnis "unique" sind, man kann die Anzahl der Hardlinks mit stat abfragen. $ echo Hallo Welt > Hallo
$ stat Hallo
File: Hallo
Size: 11 Blocks: 8 IO Block: 4096 regular file
Device: 15h/21d Inode: 392752 Links: 1
$ ln Hallo Welt
$ stat Hallo Welt
File: Hallo
Size: 11 Blocks: 8 IO Block: 4096 regular file
Device: 15h/21d Inode: 392752 Links: 2
File: Welt
Size: 11 Blocks: 8 IO Block: 4096 regular file
Device: 15h/21d Inode: 392752 Links: 2 Vielleicht kannst du dein Problem ja auch mal mit so einem Code Snippet veranschaulichen, also - erstell mal eine kleine Verzeichnisstruktur, sichere die mit rsync, verändere sie (eine Datei löschen, eine Datei verändern, eine Datei erstellen), sichere sie wieder, und dann zeigst du: welche Befehle benutzt du, welches Ergebnis bekommst du, und was hast du stattdessen erwartet?
|
guy.brush
(Themenstarter)
Anmeldungsdatum: 13. Februar 2011
Beiträge: 216
Wohnort: Earth
|
Hallo, vielen Dank für eure Antworten. Ich versuche noch einmal etwas Klarheit in mein Anliegen zu bringen: Ich habe an verschiedenen Stellen gelesen, dass Hard Links ab einer gewissen Menge an Dateien zu Problemen führen. Außerdem finde ich es immer etwas verwirrend, wenn dann 2 Ordner 42 GB groß sind, aber nur 43 GB insgesamt auf der Festplatte belegen. 😉 Daher hatte ich mich gefragt, ob es auch eine Umsetzungsmöglichkeit ohne Hard Links gibt und falls ja, wie einfach diese ist. Die Antwort kann auch sein, dass es keine (gute) Lösung ohne Hard Links mit rsync gibt. Ich bin jetzt nicht unbedingt darauf aus, dass Ganze ohne Hard Links umzusetzen. Ich suche mehr nach "allen Möglichkeiten", um dann für mich das beste daraus umzusetzen. So wie ich rsnapshot verstehe, verwendet dies Hard Links, ist also keine "ohne Hard Links Alternative". @Hefeweiz3n: Deine Aussage verstehe ich nicht ganz. Es geht ja hier um inkrementelle bzw. differentielle Backups. Die dürften mit und ohne Hard Links ungefähr gleich viel Platz verbrauchen. Ich mache auf jeden Fall nicht immer Vollbackups. Aktuell habe ich 3 Vollbackups, die ich in unterschiedlichen Intervallen aktualisiere/synchronisiere. Ich kann also praktisch zu 3 exakten Zeitpunkten in der Vergangenheit zurückgehen. Zusätzlich ermöglichen mir die --backup-dir-Ordner, auch Dateien aus noch älteren Backup-Vorgängen wiederherzustellen (mit gleich erläutertem Nachteil). Ich versuche das einmal kurz zu erklären. Angenommen, ich synchronisieren immer den Ordner "src" mit dem Ordner "dest". Für jeden Synchronisationsvorgang verwende ich immer ein --backup-dir=[...]/YYYY-MM-DD_HH-MM. Gelöschte/Veränderte Dateien sind also immer exakt mit dem jeweiligen Backup-Vorgang zu identifizieren. In diesen Ordner wandern alle veränderten und gelöschten Dateien. Benötige ich einmal eine alte Datei, weil z.B. die aktuelle in src und dest kaputt ist, so kann ich die --backup-dir Ordner nach der jüngsten nicht-kaputten Datei durchsuchen und diese wieder nach src kopieren. Was ich aber nicht kann, ist, den exakten Stand von z.B. vor 3 Tagen wiederherzustellen. Beispiel: Ich habe die letzten 3 Tage jeweils täglich 1x synchronisiert, dann habe ich --backup-dir-Ordner für Sonntag, Montag und Dienstag. Heute (Mittwoch) bemerkte ich, dass mehrere Daten seit Montag kaputt sind und ich möchte den Stand von Sonntag 1:1 wiederherstellen. Jetzt kopiere ich zuerst "dest" nach "src_new". Anschließend kopiere ich den --backup-dir von Dienstag nach src_new, dann Montag und zum Schluss Sonntag. Jetzt habe ich fast den Zustand von Sonntag erreicht. Alle Dateien, die es Sonntag schon gab, sind wieder auf dem Stand vom Sonntag zum Zeitpunkt des Backups. Allerdings kann es in src_new auch Dateien geben, die es am Sonntag noch nicht gegeben hat. Wenn ich bspw. am Montag eine Datei "Speiseplan.txt" erstellt habe und es diese vorher nicht gab, so befindet sich diese auch in src_new. (Das kann, je nach Situation, vermutlich auch gewünscht sein. Immerhin ist diese Datei dann nicht verloren. Ich weiß nicht, ob es Situationen (Virus?) gibt, bei denen das unerwünscht ist.) Das heißt, obwohl mit dieser Methode vermutlich in vielen Situationen alle notwendigen Daten gerettet werden können, ist es eben nicht möglich, den exakten Stand von (in diesem Beispiel) Sonntag wiederherzustellen. Es fehlt die Information, welche Dateien es am Sonntag noch nicht gab, um diese dann bspw. nachträglich zu löschen. Die Option --compare-dest benutze ich nicht. Aber das Verhalten müsste dann wie folgt sein: Ich erstelle am Samstag ein Vollbackup. Am Sonntag, Montag und Dienstag erstelle ich ein quasi-differentielles Backup, indem ich mit --compare-dest=[der Vollbackupordner vom Samstag] nur die veränderten Dateien sichere. Wenn ich jetzt am Mittwoch einen Datenverlust erleide und den Stand von Dienstag wiederherstellen möchte, dann wird mir das nicht 1:1 gelingen. Ich kopiere also wieder das Vollbackup vom Samstag nach "src_new". Anschließend kopiere ich die differentielle Sicherung von Dienstag nach src_new. Jetzt sind zwar wieder alle Daten wiederhergestellt worden, die ich herstellen wollte, aber eben auch ein paar mehr. Habe ich am Montag bspw. ein paar peinliche Fotos vom letzten Malle Urlaub gelöscht, dann sind die jetzt auch wieder da. Diese erneut zu löschen, kann ja nach Situation sehr lange dauern. Hier fehlt also die Information, welche Dateien seit dem letzten Vollbackup gelöscht worden sind. Sofern ich hier keinen Denkfehler gemacht habe, sind also beide Varianten zwar dazu geeignet, keinen Datenverlust zu erfahren, aber sie stellen eben auch nicht genau den Stand von "Tag X" wiederher. Dass dies mit --link-dest und Hard Links so genau möglich ist, ist mir klar. Aber mir geht es aus oben genannten Gründen ja gerade darum, ob es auch eine Möglichkeit ohne Hard Links gibt.
|
guy.brush
(Themenstarter)
Anmeldungsdatum: 13. Februar 2011
Beiträge: 216
Wohnort: Earth
|
Ich würde gerne noch eine Frage hinzufügen: Ab wie vielen Hard Links insgesamt wird man Probleme bekommen? Oder anders gefragt: Wie viele Hard Links sind maximal möglich? Ich finde leider nicht mehr die Quelle, bei der ich etwas dazu gelesen habe (dass es irgendwann Probleme machen soll). Lediglich etwas ähnliches, wobei hier nur gesagt wird, dass man Verzeichnisse mit sehr vielen Hard Links nicht mit der Option "Hard Links erhalten" kopieren soll. Hier wird gesagt, dass ext4 das Limit pro Datei auf 65.000 Hard Links beschränkt. Aber wie viele Hard Links darf es insgesamt maximal auf z.B. einer externen Festplatte mit ext4 geben?
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7651
|
guy.brush schrieb: Ab wie vielen Hard Links insgesamt wird man Probleme bekommen? Oder anders gefragt: Wie viele Hard Links sind maximal möglich?
Dateisysteme wie ext* begrenzen die Anzahl Inodes, aber die teilen sich die Hardlinks ja gerade. Wo keine Hardlinks möglich sind ist bei der Verzeichnisstruktur... jedes Verzeichnis ein inode und natürlich auch Speicherplatz. Also wenn mans allzusehr übertreibt wird man da irgendwann Probleme bekommen... aber jetzt so beim Standard Backup ist das eigentlich sehr weit entfernt. Es gibt halt Spezialfälle, z.B. ein ccache der Millionen Winzfurzdateien anlegt, aber von so einem Cache macht man auch keine Backups. Bei einem normalen Anwendungsfall wirst du da keine Probleme bekommen selbst wenn du tägliche Backups des gesamten letzten Jahres hast. Eher geht dir da der Platz auf natürliche Weise aus (durch Dateifluktuation die nicht durch Hardlinks dedupliziert wird). Und da ext* die Inodes standardmäßig sehr knapp bemisst, kannst du einfach so ins Dateilimit laufen, einfach mal mit df -i schauen wieviele Inodes belegt sind und je nachdem kann man sich dann Sorgen machen.
|
BillMaier
Supporter
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6472
|
Hallo, mich würde an deiner Stelle zunächst interessieren, warum Hardlinks doof sind oder Probleme machen sollen. Mir ist nur bekannt, dass die Löschung von diesen "Hardlink-Ordnern" verhältnismäßig lange dauern soll. Aber sonst? Ich würde keine Lösung suchen für ein Problem das nicht existiert. Ich persönlich mag inkrementell nicht - gerade aus dem Grund, dass man sich einen Backup-Stand wieder zusammen bauen muss - falls das die Software nicht automatisch macht. An rsync finde ich gerade gut, dass es mit jedem differenziellen Kopiervorgang ein Full-Backup erzeugt. Gruß BillMaier
|
guy.brush
(Themenstarter)
Anmeldungsdatum: 13. Februar 2011
Beiträge: 216
Wohnort: Earth
|
Ahh, ok. Das heißt, 1 Inode = 1 Datei/Verzeichnis. 1 Datei mit 10 Hard Links = immer noch 1 Inode. Richtig? Eine meiner Festplatten scheint gut 180 Millionen Inodes zu haben.
Damit wären meine Grenzen für die Anzahl der Backups erreicht durch: Entweder habe ich gut 180 Millionen verschiedene Dateien/Verzeichnisse auf der Festplatte (sofern der Speicherplatz ausreicht) oder ich mache immer Hard Link Backups mit rsync und eine Datei, die es seit dem ersten Backup gibt, wurde nie verändert, dann habe kann ich 65.000 Backups insgesamt machen, bevor das System meckert "Datei X hat zu viele Hard Links", richtig? Und anders ausgedrückt: Die Inodes beschränken die Anzahl der verschiedenen Dateien und wird mit oder ohne Hard Links zum selben Zeitpunkt erreicht. Hard Links ändern an dem Sachverhalt nichts. Habe ich das so richtig verstanden? @BillMaier: Wie oben geschrieben, hatte ich etwas gelesen, dass Hard Links ab einer gewissen Menge zu Problemen führen sollen. Vielleicht habe ich das aber auch falsch verstanden. Zusätzlich finde ich das Konzept manchmal etwas verwirrender. Daher mein Anliegen, ob es auch ohne Hard Links geht. Wie viel länger dauert es denn, einen Ordner mit vielen Hard Links zu löschen? Da ich hoffentlich nur sehr selten ein Backup wieder einspielen muss, ist mir der erhöhte Kopieraufwand bei normalen inkrementellen Backups nicht so wichtig ☺.
|
BillMaier
Supporter
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6472
|
guy.brush schrieb: Wie viel länger dauert es denn, einen Ordner mit vielen Hard Links zu löschen?
Wie viele Dateien? Was sind "viele" Hardlinks? Was für ein System? Probier es aus...
|
JensHol
Anmeldungsdatum: 31. Oktober 2017
Beiträge: 322
|
Aus der Praxis: ich habe auf meiner Sicherungsplatte nach einem Jahr etwa 120 Millionen Hardlinks und noch kein Problem festgestellt 😉 die erste Sicherung braucht ca 6 Stunden, die tägliche Sicherung (Kopie letztes Backup mit Hardlinks und dann Sync als aktuelle Sicherung) zwischen 7 und 10 Minuten. Nachtrag: ca. 300.000 Dateien pro Sicherung) Alte Sicherungen von einem Jahr löschen dauert schon mal 2-3 Stunden (120 Millionen Löschungen)
|
JensHol
Anmeldungsdatum: 31. Oktober 2017
Beiträge: 322
|
Nachtrag zu den inodes: die sind bei mir zu 4% verbraucht, also erst ca 3 mio. Das dürfte der Anzahl der verschiedenen Dateien auf der Festplatte entsprechen, Hardlinks haben demnach darauf keinen Einfluss. Sonst müssten schon mehr verbraucht sein.
|
guy.brush
(Themenstarter)
Anmeldungsdatum: 13. Februar 2011
Beiträge: 216
Wohnort: Earth
|
Das ist doch mal ein gutes Beispiel ☺. Wird durch das Setzen von Hard Links (entweder immer oder durch rsync) der Status auf "schreibgeschützt" gesetzt? Ich versuche gerade, meine Testbackups mit Hard Links zu löschen, aber er meckert bei (fast?) jeder Datei, dass diese schreibgeschützt sei. Das trifft mit "rm" auf. Benutze ich ganz normal Dolphin meckert er nicht (allerdings sind die Daten für den Trash zu groß, weshalb ich jetzt mal rm ausprobiert hab...).
|
BillMaier
Supporter
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6472
|
guy.brush schrieb: Das ist doch mal ein gutes Beispiel ☺. Wird durch das Setzen von Hard Links (entweder immer oder durch rsync) der Status auf "schreibgeschützt" gesetzt?
nein. Führst du rsync mit root aus und bist beim löschen nicht mit root unterwegs?
|
guy.brush
(Themenstarter)
Anmeldungsdatum: 13. Februar 2011
Beiträge: 216
Wohnort: Earth
|
Ja, ich benutze sudo, weil ich auch /etc und /root sichere. Ich vermute gerade, dass es doch nicht alle Dateien sind und nur Dateien, die etwas komische Rechte haben. Ich habe hier bspw. ein paar Sprach-mp3s von einem Lehrbuch, die ich von CD auf den PC gezogen habe. Die gehören zwar in der Regel zu meinem User, haben aber abgefahrene Rechte wie z.B. 400 und 444. Einige Fotos, die ich von Windows-Leuten bekommen habe, haben die Rechte 777. Afaik ist bei (K)Ubuntu der Standardwert für neue Ordner 775. Wie ist er denn aktuell für neue Dateien? Ich dachte, das wäre 664, eine neue Test-Textdatei wurde bei mir aber mit 644 erstellt. Und ich habe auch bemerkt, dass ich solche und solche Dateien habe... (also mit beiden Berechtigungen welche) Und ich habe einen Ordner ".nano" in meinem home-Verzeichnis, der root gehört. Der ist allerdings leer. Sachen gibt's... 🐸 Ich dachte, beim normalen Kopieren von z.B. Dateien von einer CD auf die Platte mittels Dolphin passt Ubuntu das sinnvoll an 😉.
|