Ciatronical
Anmeldungsdatum: 26. Juli 2009
Beiträge: 170
|
Hey All, ich benutze beim Programmieren als Versionsverwaltungstool Git. Als Git-Fan, möchte ich natürlich auch mein komplettes Dateisystem ca (20GB) mit Git verwalten. Da Git keine Besitzer kennt, möchte ich die File-Owner gern in einer Datei speichern. Ich dachte mir das so: 1. Owner-File erstellen 2. git add /var /etc /home /..... 3. git commit 4. git push Letzteres speichert die Änderungen mit einem Minimum an Daten-Trafic auf (m)einem Git-Server. Bei einer kompletten Rücksicherung werden via Script aus dem Owner-File die Besitzer geändert (chown) Was meint ihr dazu?? Geht das so?? Viele Grüße Ronny
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7790
|
Als Git-Fan, möchte ich natürlich auch mein komplettes Dateisystem ca (20GB) mit Git verwalten.
Viel Spaß. Git kann mit Binärkram nicht so gut umgehen. Wenn ich mich recht erinnere gibts sogar ein Projekt das diese explizit aus dem Git-Tree heraushält und stattdessen nur Link-Tracking macht.
Da Git keine Besitzer kennt, möchte ich die File-Owner gern in einer Datei speichern.
git hat entsprechende Hooks, in denen man sich das vielleicht zusammenwursteln kann. Also beim Commit automatisch die Rechte mit und beim Checkout wieder her. Vielleicht hat das auch schon jemand gelöst, viel Spaß beim Suchen. Google findet git-cache-meta aber vielleicht gibts da noch was anderes.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 13213
|
Ciatronical schrieb:
Was meint ihr dazu?? Geht das so??
Vielleicht. Die bereits erwähnten Hooks sind sicherlich einen Blick wert. Auffälligerweise arbeiten Backup-Lösungen üblicherweise anders. Das könnte ein Hinweis darauf sein, dass Dein Ansatz Nachteile hat. (Wobei ich die jetzt nicht benennen könnte.)
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17524
|
Für Binärdateien wir gerne git-annex als Ansatz genommen, aber grundsätzlich: Versionsverwaltungen hassen Binärdateien. mfg Stefan Betz
|
Vain
Anmeldungsdatum: 12. April 2008
Beiträge: 2510
|
Wenn es um das komplette System geht, ist das vielleicht wirklich nicht so der beste Ansatz. Das merkst du schon daran, dass du einen Workaround für Ownership brauchst. Zusätzlich gibt es aber auch noch andere Sachen, die Git nicht abbildet, zum Beispiel ACLs oder Capabilities und alles, was mit Extended Attributes realisiert ist. So grundlegende Attribute wie „mtime“ sind auch nicht abgebildet – da kannst du aber üblicherweise drauf hoffen, dass die keine ausschlaggebende Rolle spielen. „Moderne Dateisysteme“ liegen ja derzeit voll im Trend. ZFS, btrfs. Vielleicht ist da was für dich dabei.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 13213
|
Vain schrieb: Wenn es um das komplette System geht, ist das vielleicht wirklich nicht so der beste Ansatz. Das merkst du schon daran, dass du einen Workaround für Ownership brauchst. Zusätzlich gibt es aber auch noch andere Sachen, die Git nicht abbildet, zum Beispiel ACLs oder Capabilities und alles, was mit Extended Attributes realisiert ist. So grundlegende Attribute wie „mtime“ sind auch nicht abgebildet – da kannst du aber üblicherweise drauf hoffen, dass die keine ausschlaggebende Rolle spielen.
Ja, aber es ist u.U. schon praktisch, wenn man das echte Modifikationsdatum hat, damit man an der Datei direkt sehen kann, wann sie geändert wurde.
„Moderne Dateisysteme“ liegen ja derzeit voll im Trend. ZFS, btrfs. Vielleicht ist da was für dich dabei.
Mit "modern" meinst Du in diesem Zusammenhang, dass das Dateisystem die Möglichkeit bietet Snapshots anzulegen, nehme ich an.
|
Thomas_Do
Moderator
Anmeldungsdatum: 24. November 2009
Beiträge: 8808
|
Welche Vorteile versprichst Du Dir konkret, die "klassische" Backuplösungen nicht bieten? GIT ist doch sehr auf Quellcode o.ä. zugschnitten.
|
Vain
Anmeldungsdatum: 12. April 2008
Beiträge: 2510
|
rklm schrieb: Vain schrieb: „Moderne Dateisysteme“ liegen ja derzeit voll im Trend. ZFS, btrfs. Vielleicht ist da was für dich dabei.
Mit "modern" meinst Du in diesem Zusammenhang, dass das Dateisystem die Möglichkeit bietet Snapshots anzulegen, nehme ich an.
Einerseits das und dann auch, dass man die Snapshots dann per SSH woanders hinübertragen kann, IIRC auch inkrementell (Unterschied zum letzten Snapshot).
|
Ciatronical
(Themenstarter)
Anmeldungsdatum: 26. Juli 2009
Beiträge: 170
|
Thomas_Do schrieb: Welche Vorteile versprichst Du Dir konkret, die "klassische" Backuplösungen nicht bieten? GIT ist doch sehr auf Quellcode o.ä. zugschnitten.
Einen geringen Traffic und eine Versionsverwaltung für jede einzelne Datei. Ein weiterer Vorteil ist, das ich Git kenne. Zur Zeit benutze ich rsync.
Wie ich da eine Änderung in einer Datei von vor drei Wochen wieder rückgängig machen kann weiß ich nicht. Meines Wissens gibt es auch nicht so tolle Tools wie git bisect https://kleinweby.de/2012/03/git-bisect-wer-hat-wann-was-kaputt-gespielt/,
gitk oder gitweb. Des weiteren können kleinere Backups auch im Web auf Bitbucket gespeichert werden.
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17524
|
Um es kurz zu machen: git skaliert nicht für 20GB Daten und viele Änderungen. Das hat man dir schon 2-3x mal gesagt. Dazu kommt das Extented Attributes und Permissions komplett über den Jordan sind damit. Sehr effektiv ist z.b. borg backup, das Arbeiten mit btrfs (COW) oder Log Structured Dateisystem die jede Änderung Prinzipbedingt mitschreiben. Effektiv übertragen kann man Änderungen wenn man nicht erst scannen muss was sich geändert hat, daher gibt es diese neumodischen Dateisysteme mit COW als Backend. Die Wissen sofort was sich geändert haben, und müssen nicht erst wie rsync/borg prüfen was sich den geändert hat und worin den die Änderung besteht. mfg Stefan Betz
|
Thomas_Do
Moderator
Anmeldungsdatum: 24. November 2009
Beiträge: 8808
|
encbladexp schrieb: Effektiv übertragen kann man Änderungen wenn man nicht erst scannen muss was sich geändert hat, daher gibt es diese neumodischen Dateisysteme mit COW als Backend. Die Wissen sofort was sich geändert haben, und müssen nicht erst wie rsync/borg prüfen was sich den geändert hat und worin den die Änderung besteht.
Das ist natürlich chic! Wobei ich zur Zeit mit BorgBackup für über 800 GB Daten unter 5 min zum Scannen brauche. Das wären für 20 GB unter 10s. Da könnte man Snapshots in sehr kurzen Intervallen anlegen und durch die Deduplikation wächst die Datenmenge nur, wenn sich etwas verändert hat. Außerdem kann Borg im Gegensatz zu GIT ältere Snapshots/Datenstände sehr einfach "ausdünnen".
|