Hallo zusammen,
ich suche eine Möglichkeit unter Linux (idealerweise mit C) Änderungen
im Dateisystem festzustellen.
Die Standardantwort darauf lautet: inotify. Das ist zweifelsfrei ganz
nett, skaliert jedoch nicht, da inotify nicht rekursiv arbeiten kann.
Das hat zur Folge, dass man für jedes Verzeichnis eine extra Überwachung
einrichten muss. Das Limit hierfür liegt standardmäßig auf 8192
Watches. Das Dateisystem, dass ich überwachen will, hat aber bereits
jetzt schon ca 14000 Unterverzeichnisse. Tendenz steigend. Da ein neuer
"watch" nicht unwesentlich Systemressourcen belegt möchte ich diese
Standardeinstellung nicht groß anfassen. Irgendwann wird mir das nämlich
auf die Füsse fallen.
Bei der Suche nach Alternativen bin ich bisher nicht fündig geworden.
Die Lösungen, die ich bisher fand, setzten alle voraus, dass ich den
Kernel patchen muss. Meine Begeisterung bei jedem Kernelupdate meinen
Patch anzupassen ist nicht besonders hoch, zumal ich ungern am Kernel
selbst Änderungen vornehmen möchte.
Kennt jemand von euch noch eine Möglichkeit, wie man das ganze angehen
könnte?
Grüße
Sven
Der Hintergrund:
Das ganze soll in einem Backupszenario Anwendung finden. Alle 10 Minuten
soll das Dateisystem gesichert werden. Gesichert wird dabei nur das
Delta. Jedes mal das komplette Dateisystem nach Änderungen zu scannen
ist mir dabei zu träge. Vielmehr möchte ich über einen daemon in
Hintergrund alle Änderungen erfassen und in eine queue stecken um diese
dann alle 10 Minuten abzuarbeiten um so den Server so wenig wie möglich
zu belasten.
das geht schon mal in eine bessere Richtung.
Leider ist es mit fanotify, technisch bedingt, nicht möglich
Dateiverschiebungen, Löschungen oder Umbenennungen zu erfassen. Dies ist
für z.B. Virenscanner egal, für Backups jedoch nicht zu gebrauchen. Da
fatrace auf fanotify aufbaut unterliegt es den gleichen Restriktionen.
Noch eine Idee?
Sven schrieb:> das geht schon mal in eine bessere Richtung.> Leider ist es mit fanotify, technisch bedingt, nicht möglich> Dateiverschiebungen, Löschungen oder Umbenennungen zu erfassen. Dies ist> für z.B. Virenscanner egal, für Backups jedoch nicht zu gebrauchen. Da> fatrace auf fanotify aufbaut unterliegt es den gleichen Restriktionen.>> Noch eine Idee?
Du kannst ein FUSE implementieren. Oder Du kannst gleich so etwas wie
DRBD oder GlusterFS benutzen -- dann werden die Änderungen nicht erst
nach zehn Minuten, sondern sofort auf einen (oder mehrere) Hosts
repliziert.
Sheeva P. schrieb:> Du kannst ein FUSE implementieren.
wäre eine Möglichkeit. Das ganze gibt es quasi auch schon fertig:
LoggedFS. Letztlich wird es mich wahrscheinlich Performance kosten, aber
das könnte ich mal konkret testen.
> DRBD oder GlusterFS benutzen
schlecht, da es sich bei den Backupzielen nicht um von mir betriebene
Server handelt. Die Backups werden einerseits via USB auf Festplatten
und andererseits via FTP auf einen anderen Server geschoben.
TuxDerFuchs schrieb:> Wie arbeitet denn rsync?
rsync scannt den kompletten Verzeichnissbaum, ggf. je nach Aufruf wird
noch eine Prüfsumme für jede einzelne Datei berechnet.
Sven schrieb:> rsync scannt den kompletten Verzeichnissbaum, ggf. je nach Aufruf wird> noch eine Prüfsumme für jede einzelne Datei berechnet.
Ist das nicht das, was du möchtest?
Sven schrieb:> alle 10 Minuten abzuarbeiten um so den Server so wenig wie möglich> zu belasten.
es ist wie immer: entweder kostet die sache speicher, oder cpu, oder es
werden investitionen fällig … ;)
alle 10min zu sichern ist eigentlich wahnsinn, vor allem weil du (wieder
"eigentlich") nur dateien sichern kannst die grade nicht in
benutzung/halb geschrieben sind - du also dienste die auf das zu
sichernde dateisystem zugreifen ausschalten müsstest, um die integrität
der dateien sicher zu stellen.
aber ok. ich würde es mit rsync machen, auf ein anderes dateisystem, mit
hardlinks. KISS eben.
wenn das alle 10min aufgerufen wird, unter der vorraussetzung das
genügend speicher in der kiste ist um den dentry cache (aggressives
caching konfigurieren!) gut halten zu können, geht das recht fix.
als andere möglichkeit böte sich noch ein loggendes dateisystem wie zum
beispiel NILFS an, aber afaik is das immer noch nicht
produktionsgeeignet.
nur mal so aus reiner admin-neugier: was sind denn die grotesken
umstände, die ein 10-minütiges backup nötig erscheinen lassen?
entwicklerdeppen? ^^
Mal abgesehen davon, das so etwas meiner Meinung nach die
Standardanwendung für snapshots mit btrfs bzw lvm + RAID ist (snapshot
in Sekunden machen, Delta in Stunden berechnen und danach sichern):
Ich gehe mal davon aus, das diese 10Minuten Snapshots eher was für den
Fall "uups, das wollte ich nicht löschen/überschreiben" sind.
Spricht da etwas gegen Hardlinks? Einfach den kompletten Dateibaum
duplizieren, dauert auch nur Sekunden und funktioniert auf quasi jedem
Linux-Dateisystem.
Und was die Delta-Sicherung angeht:
Je nach Anwendung reicht es, einfach nur nach den Zeitstempeln der
Dateien zu gehen und die Dateien komplett zu sichern -> geht auch
schnell. Oder halt das Delta nur von Dateien zu berechnen, wo die
Zeitstempel neuer sind.
Da du das ja aller nn Minuten machst, kannst du einfach ein find nehmen,
um die geänderten Dateien zu suchen. Das ist auch ziemlich schnell, je
nach Dateisystem.
Es gibt natürlich auch Backup-Programme, die sowas intern können.
c.m. schrieb:> aber ok. ich würde es mit rsync machen, auf ein anderes dateisystem, mit> hardlinks. KISS eben.
Oh, wieder was über rsync gelernt. Ich sehe schon, ich nutz das zu
wenig.
Darf ich das so verstehen, das rsync erstmal ne Kopie anlegt und dann
für folgende backups immer wieder hardlinks zu dieser Kopie (es sei denn
etwas ändert sich)? Dateisystemübergreifende hardlinks gibt es ja nicht.
LOL schrieb:> Darf ich das so verstehen, das rsync erstmal ne Kopie anlegt und dann> für folgende backups immer wieder hardlinks zu dieser Kopie (es sei denn> etwas ändert sich)? Dateisystemübergreifende hardlinks gibt es ja nicht.
Ja, dank "copy on write" kann RSYNC so arbeiten. Ich mache das auch so
und verwende ein Script, was lose auf diesem hier basiert:
https://wiki.ubuntuusers.de/Skripte/Backup_mit_RSYNC/
LOL schrieb:> Darf ich das so verstehen, das rsync erstmal ne Kopie anlegt und dann> für folgende backups immer wieder hardlinks zu dieser Kopie
jau. das sieht dann etwa so aus:
das älteste backup beinhaltet die "orignaldateien", darauf folgende nur
hardlinks und deltas.
auf rechner "cm" (cm_backup) sieht man das nicht so gut weil sich hier
oft viele daten ändern, aber "orin" (orin_backup) zeigt das ganz
anschaulich: ältestes backup groß, jüngere nur deltas/klein.
c.m. schrieb:> alle 10min zu sichern ist eigentlich wahnsinn
Ich gebe zu. Etwas übertrieben. Aber bei den Anforderungen bin ich
lieber erst einmal extrem. Abrücken davon werde ich noch früh genug.
> vor allem weil du (wieder> "eigentlich") nur dateien sichern kannst die grade nicht in> benutzung/halb geschrieben sind - du also dienste die auf das zu> sichernde dateisystem zugreifen ausschalten müsstest, um die integrität> der dateien sicher zu stellen.
Ja. Allerdings geht es nicht um eine vollständige Systemsicherung (die
habe ich separat) sondern vielmehr um mehrere home-Verzeichnisse + ein
globales Verzeichniss für alle User. Letzlich Anwendungsdaten. Diese
lassen sich bezüglich der Integrität leichter sichern.
> aber ok. ich würde es mit rsync machen, auf ein anderes dateisystem, mit> hardlinks. KISS eben.
das ist die derzeitig existierende Lösung.
> nur mal so aus reiner admin-neugier: was sind denn die grotesken> umstände, die ein 10-minütiges backup nötig erscheinen lassen?> entwicklerdeppen? ^^
Ja. Und ich bin einer davon :)
Und zugegeben. Nötig ist es nicht. siehe Rest meiner Antwort.
LOL schrieb:> Mal abgesehen davon, das so etwas meiner Meinung nach die> Standardanwendung für snapshots mit btrfs bzw lvm + RAID ist (snapshot> in Sekunden machen, Delta in Stunden berechnen und danach sichern):
Das wäre der Istzustand: 6 Platten, im Raid 6 über LVM. Cronjob, der
täglich Snapshots anfertigt und davon ein inkrementelles Backup via
rsync auf ne USB-Platte sichert. 2 Sicherungsplatten. Nummer 1 hängt
immer dran, wird ca. alle 1-2 Monate gegen Nr. 2 gewechselt, die
ausserhalb der Wohnung gelagert wurde. Ausgewählte Verzeichnisse werden
nochmal über das Internet auf einen anderen Rechner via FTP geschoben.
Erwähnte ich, dass ich leicht paranoid bin?
> Ich gehe mal davon aus, das diese 10Minuten Snapshots eher was für den> Fall "uups, das wollte ich nicht löschen/überschreiben" sind.
wäre "nice to have"
> Spricht da etwas gegen Hardlinks? Einfach den kompletten Dateibaum> duplizieren, dauert auch nur Sekunden und funktioniert auf quasi jedem> Linux-Dateisystem.
wie gesagt. Das ist die aktuelle Lösung. Funktioniert, ist aber nicht
wirklich perfomant. Das mag an meinem Server liegen. Außerdem wird es
nachts gemacht. Von daher ist die Performance egal und bei einem
täglichen Backup auch ok. Aber ich würde gerne wie erwähnt die
Intervalle massiv verkürzen.
@all
Danke auf jeden Fall für die bisherigen Rückmeldungen. Ich sollte das
ganze an dieser Stelle vielleicht etwas besser beschreiben:
Ich verfüge derzeit über ein Backupkonzept dass, realistisch betrachtet,
wohl auch ausreichend, und für manche vielleicht auch schon etwas
übertrieben ist. Die gesamte Zeit, die ich jetzt in Verbesserungen
stecke werde ich im Ernstfall nicht wieder gut machen. Doch darum geht
es mir nicht.
Manche Menschen haben eine Freude daran beispielsweise eine
Modelleisenbahn aufzubauen. Das machen die nicht weil sie eine Karriere
als Fahrdienstleiter planen, oder möglichst effektiv Spielzeugfiguren
von A nach B befördern wollen. "Via destinatum est" Der Weg ist das
Ziel. Ich will das nicht machen, weil es notwendig ist, sondern weil es
mich interessiert das Optimum für meine Bedürfnisse zu erreichen.
Daher bin ich am Sammeln von Ideen wie ich ein möglichst effizientes
Backup realisieren könnte. Und die erste Frage die sich da bei mir
stellt ist:
"Wie ermittle ich möglichst effizient, welche Dateien ich wann sichern
muss?"
Und mit effizient meine ich in diesem Fall technisch. Mir erscheint es
sinnvoll nicht jedesmal alles gegenzuprüfen, sondern nur auf die
Änderungen zu reagieren, also quasi einen Hook im Dateisystem zu haben,
über den ich alle Änderungen mitbekomme.
