Gedankenexperiment: git init auf dem Root-Verzeichnis

[paedubucher]

Was passiert eigentlich, wenn man folgendes macht:

Code: Alles auswählen

# cd /
# git init

Könnte man sich damit ein allumfassendes System-Recovery-Tool bauen? Vielleicht müsste man /dev zu .gitignore hinzufügen. Aber was wäre z.B. mit /proc? Könnte man dadurch den genauen Zustand des Rechners konservieren, oder ist so etwas gar nicht möglich, zumal auch git ein Prozess mit einem Status ist?
Nur ein kleines Gedankenexperiment Noch traue ich mich nicht, es auszuführen.

[smutbert]

Ich kenn mich mit git so gut wie nicht aus, aber ich nehme an du willst einfach das komplette System in einem git-Repo speichern?

Um die virtuellen Dateisystem loszuwerden - neben devtmpfs bzw. /dev und proc gibt es ja auch noch sysfs, mehrere tmpfs, fuse,… - könntest du das /-Dateisystem und alle weiteren gewünschten ein weiteres Mal irgendwo unter /mnt mounten und von dort sichern.
So mache ich das schon lange, wobei ich das mit den btrfs-Subvolumes und Snapshots besonders bequem finde.

Allumfassend ist es aber trotzdem nicht - es fehlen Dinge wie Partitionstabellen, MBR und bei uefi-Systemen der Booteintrag der Firmware. Das ist aber nichts, was sich nicht wieder leicht herstellen ließe.
Außerdem muss man berücksichtigen, dass man so auch Dateien sichert, die "offen" sind und möglicherweise gerade geschrieben werden. Es gibt also keine Sicherheit, dass alle Dateien in einem konsistenten Zustand sind (zB die Paketdatenbank während einer Installation oder eines Updates).

[paedubucher]

Ich kenn mich mit git so gut wie nicht aus, aber ich nehme an du willst einfach das komplette System in einem git-Repo speichern?

Eigentlich will ich gar nichts, ich hatte nur diesen Einfall, und habe darüber nachgedacht, was das ganze bewirken könnte, bzw. welche Probleme dabei auftreten könnten.

Um die virtuellen Dateisystem loszuwerden - neben devtmpfs bzw. /dev und proc gibt es ja auch noch sysfs, mehrere tmpfs, fuse,… - könntest du das /-Dateisystem und alle weiteren gewünschten ein weiteres Mal irgendwo unter /mnt mounten und von dort sichern.
So mache ich das schon lange, wobei ich das mit den btrfs-Subvolumes und Snapshots besonders bequem finde.

Das wäre dann ein konsistenter Snapshot, ja?

Allumfassend ist es aber trotzdem nicht - es fehlen Dinge wie Partitionstabellen, MBR und bei uefi-Systemen der Booteintrag der Firmware. Das ist aber nichts, was sich nicht wieder leicht herstellen ließe.
Außerdem muss man berücksichtigen, dass man so auch Dateien sichert, die "offen" sind und möglicherweise gerade geschrieben werden. Es gibt also keine Sicherheit, dass alle Dateien in einem konsistenten Zustand sind (zB die Paketdatenbank während einer Installation oder eines Updates).

Danke für die Erläuterungen!

[smutbert]

[…]
Das wäre dann ein konsistenter Snapshot, ja?

Wenn ein laufendes System gesichert wird, können trotzdem Dateien geöffnet sein. Selbst wenn man vor dem Backup einen read-Only Snapshot des Systems anlegt und den sichert, könnte der Snapshot gerade während eines Schreibzugriffs erstellt worden sein und damit irgendwelche unvollständig geschriebene Änderungen, also Inkonsistenzen enthalten, aber man kann auch versuchen das zu vermeiden:

Läuft ein Dienst der wichtige Daten speichert zB ein Datenbankserver wie mysql-server kann man den Dienst vor dem Beginn des Backups beenden oder man kümmert sich getrennt um die Sicherung der Datenbank.

Ebenfalls könnte man versuchen zu vermeiden, dass Benutzer während des Backups Dokumente oder andere Dateien bearbeiten.

Wenn man noch darauf verzichtet während des Backups Updates auszuführen oder Pakete zu (de-)installieren sollte nicht mehr allzu viel schiefgehen können.
Bei einem typischen Desktopsystem ohne besondere Dienste wie Datenbankservern, das regelmäßig gesichert wird, muss man im Endeffekt meist gar nichts unternehmen. Ist zufällig gerade irgendein Dokument offen, oder ein PDF oder ein Download unvollständig geschrieben, dann wird die Datei eben beim nächsten Backup korrekt gesichert - mehrere Backupgenerationen sollte man ja sowieso immer behalten, weil man Fehler nicht unbedingt sofort bemerkt.

[schorsch_76]

git zeichnet keine uid/gid auf. Ein checkout würde dann die Rechte nicht mehr richtig setzen

http://unix.stackexchange.com/questions ... ip-on-pull
.

[gehrke]

Ich mache das schon länger so, allerdings nicht allumfassend, sondern nur für /etc. Hat mir schon mehrfach geholfen und kostet fast nichts.

[Liffi]

Ich mache das schon länger so, allerdings nicht allumfassend, sondern nur für /etc. Hat mir schon mehrfach geholfen und kostet fast nichts.

Mit etckeeper ist es sogar sehr günstig .