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.
fatrace/fanotify sollte das Richtige in deiner Situation sein.
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:
1 | du -hs /media/cm/BACKUP/*_backup/* |
2 | 89G /media/cm/BACKUP/cm_backup/2016_01_18-074127.done |
3 | 93M /media/cm/BACKUP/cm_backup/2016_01_18-090142.done |
4 | 137G /media/cm/BACKUP/cm_backup/2016_03_07-064049.done |
5 | 71G /media/cm/BACKUP/cm_backup/2016_03_11-094028.done |
6 | 216M /media/cm/BACKUP/cm_backup/2016_03_15-065646.done |
7 | 38G /media/cm/BACKUP/cm_backup/2016_03_18-063150.done |
8 | 39G /media/cm/BACKUP/cm_backup/2016_03_24-071326.done |
9 | 42G /media/cm/BACKUP/cm_backup/2016_04_04-093111.done |
10 | 276M /media/cm/BACKUP/cm_backup/2016_04_08-082605.done |
11 | 57G /media/cm/BACKUP/orin_backup/2016_01_13-083145.done |
12 | 538M /media/cm/BACKUP/orin_backup/2016_01_13-115019.done |
13 | 104G /media/cm/BACKUP/orin_backup/2016_03_07-075609.done |
14 | 5,9G /media/cm/BACKUP/orin_backup/2016_03_11-083900.done |
15 | 1,1G /media/cm/BACKUP/orin_backup/2016_03_18-064956.done |
16 | 1,4G /media/cm/BACKUP/orin_backup/2016_03_24-063329.done |
17 | 975M /media/cm/BACKUP/orin_backup/2016_04_04-095514.done |
18 | 783M /media/cm/BACKUP/orin_backup/2016_04_08-081012.done |
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.
Es gibt noch das Audit-Subsystem und das Tracing-Framework, das arbeitet aber eher auf der Syscall-Ebene.
Sollte nicht das hier genau das sein was du suchst? http://www.tummy.com/blogs/2010/11/01/fun-with-btrfs-what-files-have-changed/ Wobei ich mich frage ob du das überhaupt brauchst, denn das was du insgesamt umsetzen willst entspricht doch dem incremental snapshot transfer, oder? https://btrfs.wiki.kernel.org/index.php/Incremental_Backup Noch ein paar Skripte drum rum, in den Cronjob damit und fertig ist die Laube - wenn ich dich richtig verstehe
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.