rsync

rsync-sidekick – rsync’s dufter Kumpel

Gastbeitrag von Sven Wick

Wenn es darum geht Daten zu synchronisieren, findet sich auch heute noch das bewährte rsync im Werkzeugkoffer der meisten Admins. Doch bei den Mengen von Daten heutzutage zeigt sich bei rsync das ein oder andere Manko besonders deutlich.

Geänderte Ordnerstruktur

Ändert man z.B. einfach nur die Ordnerstruktur, ist das für rsync nicht direkt ersichtlich
und es wird im schlimmsten Fall erneut komplett alles übertragen. Um dieses Problem zu lösen, gibt es in rsync selbst den --fuzzy Parameter, der jedoch nur bedingt gut funktioniert. Projekte wie casync lösen ähnliche Probleme, können teilweise aber nicht, wie man es von rsync gewohnt ist, benutzt werden.

rsync-sidekick räumt auf

Ansetzen möchte hier das Projekt rsync-sidekick. Das Tool, das vor dem Aufruf von rsync gestartet wird, schaut sich alle Dateien in Quelle und Ziel an und versucht zu ermitteln, welche Dateien und Ordner verschoben oder umbenannt werden müssen, damit der normale rsync-Aufruf danach nur wenig Gerade ziehen bzw. nur Daten, die wirklich fehlen, übertragen muss. Dabei werden Daten nicht direkt verändert, sondern am Ende wird einfach nur ein Shellskript ausgespuckt, das man entweder manuell ausführt oder direkt von rsync-sidekick starten lassen kann. Danach sollte man unbedingt nochmal rsync selbst drüberschlichten lassen, um das ein oder andere Fältchen gerade zu bügeln…

Auf GitHub zu Hause

Um das Vergleichen der Daten zu beschleunigen, wird nicht die komplette Datei, sondern nur einzelne Stellen darin gehashed (das Verfahren ähnelt dem von OpenSubtitles). Um rsync-sidekick zwischen Hosts zu nutzen,
muss man sich derzeit noch mit SSHFS oder ähnlichem behelfen. Das Tool wird auf GitHub entwickelt, wird unter der Apache-2.0 License veröffentlicht und steht in Version 1.22 als Quellcode zum Download bereit.

64449155

Teilt den Beitrag, falls ihr mögt

5 Kommentare

  1. Ich blicke bei der Softwareentwicklung nicht mehr durch, wenn ich das github Repository ansehe. rsync-sidekick ist in Go geschrieben, was eigentlich toll ist, da man mit Go portable statische Binaries erhält. Das Problem “works on my machine” sollte damit minimiert sein.
    Statt aber eines Binaries anzubieten, gibt es nur den Quellcode oder alternativ einen Docker-Container. Ich verstehe beim besten Willen nicht den Sinn ein Go-Binary in einen Docker-Container zu stecken? Immerhin ist das Go-Binary bereits self contained und der Container damit doch obsolet.
    Ernst gemeinte Frage, kann mir das jemand erklären?

    0
  2. schon mal RClone ausprobiert ?
    https://github.com/rclone/rclone/releases
    https://rclone.org/docs/

    iss auch gut für Nextcloud, statt auf Microsoft’s “OneCloud” sachen hoch zu laden,
    kann man auch rclone dazu benutzen in Verbindung mit seiner cloud, ,
    nebenher kann man auch das configurationsfile benennen und so dann rclone variabel zu machen
    und verschiedene configurations-dateien zu benutzen die man dann mittels –config .\config.conf
    kann man um zu erstellen oder wieder aus zu lesen ein bestimmtes config-file bnutzen, wie config1.conf oder dann config2.conf und mittels “sync” ohne “–” cann man rclone als sync-programm auf einer Cloud benutzen.

    feines Proggy..

    2

Kommentar hinterlassen