"Versionsverwaltung" für das komplette Windows/Linux System?

[MrTony]

Hallo beieinander.

Ich habe in "The Pragmatic Programmer" im Abschnitt über Versionskontrolle heute was gelesen, was für mich total neu war. Die Autoren empfehlen Versionskontrolle für praktisch ALLES zu verwenden. Das beinhaltet wohl auch das Betriebssystem, denn als Beispiel wurde angeführt, wie einer der Autoren Tee mit Milch über seinen Laptop (angedeutet ein Macbook) gekippt hat. Darauf hin musste wohl ein neues Gerät angeschafft werden. Das neue Gerät wurde dann nicht händisch einrichtet, sondern mit "Versionskontrolle" auf den gleichen Stand gebracht, wie das kaputte Gerät inklusive installierter Software und vorhandener Dateien.

Jetzt bin ich natürlich mal sehr neugierig, wie das für MacOS und Linux (und ggf. auch für Windows) gehen soll? Mit klassischer Versionskontrolle via Git oder SVN kann ich mir nicht vorstellen, dass man einfach GIT PULL macht und dadurch das komplette System wieder hergestellt wird.
Klar könnte man wohl vieles in einem Bash Script haben, was man über den Paketmanager installieren kann, aber dann fehlen immer noch alle Dateien, so wie die Konfigurationder entsprechenden Programme.
Ich nehme an, man könnte eine Image des kompletten Systemes machen und diese Image quasi automatisiert über Nacht immer erzeugen lassen, damit sie auch aktuell bleibt?

Zumindest wären das so die Ansätze, die mir einfallen würden.
Weiß jemand, was die Autoren da gemeint/genutzt haben könnten? Gibt es denn eine Software mit der man z.B. sein Linux/Macos oder Windows Notebook automatisiert wieder so herstellen kann, wie es gestern noch war?

VG
Tony

 

[Tamron]

Nennt sich Backup in diesem Fall.

Mac: Time Machine
Neues OS wird installiert und alles andere ist wirklich 1:1 wie vorher

Windows / Linux:
z.B. mit Veeam passendes Backup des ganzen Datenträgers erstellen.
Dann kannst du eine Bare Metal Recovery machen und es auch 1:1 wiederherstellen.

Natürlich ist dein letzter Backup Punkt entscheidend.

Mit GIT oder sowas wäre das m.M.n. unmöglich.
Wie viele tausend Male willst du irgendwelche Log Dateien pushen

 

[Giggity]

Das geht mit einem Vollbackup und dann inkrementelle Backups. Zb 1x pro Woche Vollbackup und dann 6x inkrementelle Backups (nur neue Dateien werden gesichtet)

Die Funktion das sich alles auf den alten Stand wieder einstellt lässt sich Apple aber auch gut bezahlen. Dafür passiert das über iCloud/Time Machine automatisch und man muss sich nicht drum kümmern.

 

[Tamron]

Naja Time Machine kannst du mit jeder Festplatte benutzen, da brauchste keine iCloud für.

 

[Giggity]

Ich hatte jetzt zuerst ans iPhone gedacht aber klar mit Time Machine geht jede externe Festplatte

Ergänzung (7. Juni 2022)

Time Machine nimmt dir die ganze Konfiguration ab. In Windows oder Linux musst du das selbst einstellen.

 

[Marek72]

Hi,

unter Linux gibt es dafür seit Jahren etckeeper - stellt vorrangig den /etc Ordner unter Versionskontrolle. Alle Änderungen werden protokolliert und Änderungen lassen sich auch wieder Rückgängig machen. Eigentlich Standardwerkzeug für Linux Admins. Weitere Verzeichnisse in den configs liegen, können hinzugefügt werden.

Oder meintest Du ein klassisches Backup Programm?

 

[Nixdorf]

Dateiversionsverlauf unter Windows 10 aktivieren - so geht's

 

[PHuV]

Backup und Recovery eines kompletten OS mittels Versionsverwaltung ist absoluter Quatsch. Dafür sind die klassischen Versionssysteme auch gar nicht ausgelegt. Sie sind da, um Dateien wie Textdateien bzw. Sourcecodes usw. zu versionieren, für mehr war es so nicht gedacht. Für Binärdaten verwendet man wiederum eine Artefaktverwaltung (Nexus, Artifactory...), das ist aber auch nur ausschließlich für das Erstellen von Programmen und deren Abhängigkeiten gedacht.

Wie alle hier richtig sagen, für ein OS macht man ein Fullimage Backup mit einem geeigneten Tool und fertig. Viele kleine Dateien zu sichern ist viel zu aufwendig. Mein Windows 11 Ordner hat ca. 300k Dateien, insgesamt für das OS + Programme ca. 500k. Das wäre per Dateisicherung eine lange Zeit. Mit einer Imagesicherung, die den Datenträger einfach blockweise durchgeht, ist dagegen per SSD in wenigen Minuten gesichert und ebenso wieder zurückgesichert. Das schafft kein Versionierungsprogramm.

Wenn die Autoren sowas wirklich als Lösung beschreiben, sind das Idioten, anders kann man es nicht sagen. Aber das wäre ja nicht das erste Mal, wenn sich Entwickler hier dämlich anstellen, anstatt mal einen vernünftigen Admin oder DevOps zu fragen.

 

[Rumbah]

Hmm, für Programme oder vielleicht oft geänderte Configdateien mag sich das ja anbieten, das mit einer Versionskontrolle zu machen. Da kann man dann problemlos auf die letzten Versionen schauen und sich änderungen angucken/rückgängig machen. Aber für Binärdateien ist das ja nur wenig sinnvoll, weil man ja eh nichts mit den Änderungen da drin anfangen kann.

Falls du ein modernes Betriebssystem mit Snapshots wie z.B. btrfs nutzt, dann kannst du das sehr elegant dafür nutzen. So kannst du z.B. jeden Tag ein Snapshot machen und den dann mit btrfs send und receive auch sichern. Da hast du dann die Backuplogik für inkrementelle Backups quasi gleich ins Dateisystem eingebaut.

 

[drake23]

Denke auch, für das OS am besten Snapshots mir btrfs (evtl snapshots remote ablegen) und für Daten rsync.

 

[fgordon]

Naja ich nutze z.-B. nachdem ich das hier entdeckt habe "syncthing" auf unseren Android, Linux, FreeBSD und WIndows Maschinen um die Nutzerdaten aktuell zu halten fürs Backup - und auf den Servern auf denen diese Daten zusätzlich zusammenlaufen auch noch ZFS Snapshots (z.B: wegen Crypt Trojanern etc)

Von dem kompletten OS selber habe ich zwar auch teilweise Diskimages gemacht, so dass man nicht ganz bei 0 anfangen muss - allerdings mache ich die eher selten ~ alle 6 Monate oder wenn irgendwelche ganz grosse Änderungen gemacht wurden am "OS". Die Images ständig neu zu machen ist für mich dann etwas übertrieben, ausgehend von einer 4-5 Monate alten Installation kann ich das System ausreichend schnell wieder so haben, dass es funktioniert - und alle Nutzerdaten sind eh aktuell.

Zusätzliche Versionen zu denen, die ich selber mache als "Meilensteine" habe ich keine wirklich - durch die externen Backups ist aber der Stand aller Nutzerdaten von vor 2,4,6,8,10..... Wochen ja sowieso für "immer" eingefroren.

Hängt aber sich auch von Art der Daten ab wie viele Zwischenversionen man gerne archiviert haben will.

 

[MrTony]

Wenn die Autoren sowas wirklich als Lösung beschreiben, sind das Idioten, anders kann man es nicht sagen. Aber das wäre ja nicht das erste Mal, wenn sich Entwickler hier dämlich anstellen, anstatt mal einen vernünftigen Admin oder DevOps zu fragen.

Ich muss etwas präzisieren, dass sie nicht konkret gesagt haben, dass man das über Git oder SVN tun soll, das ganze Kapitel hat sich aber um Versionskontrolle gedreht und dann wurde das Beispiel mit dem zerstörten Laptop genannt und das auch hier Versionskontrolle genutzt werden sollte. Wahrscheinlich wurden hier einfach einige Kontexte vermischt.
Ich persönlich denke ich werde für mich erst mal die Wege wie von @Tamron beschrieben nutzen und von meinem Macbook und dem Linux Laptop ein "Bare Metal" Backup machen und auf meinem NAS ablegen (ich nehme an da kommen doch einige GB zusammen) und mir dann einen Rhytmus überlegen wie oft ich da ein neues Image erstellen sollte.
Jedenfalls danke an der Stelle für den Input!

 

[BeBur]

Das neue Gerät wurde dann nicht händisch einrichtet, sondern mit "Versionskontrolle" auf den gleichen Stand gebracht, wie das kaputte Gerät inklusive installierter Software und vorhandener Dateien.

Man muss ein wenig unterscheiden zwischen einem Vollbackup und dem (kenne das Buch nicht und rate jetzt ein wenig) was dort gemeint ist. Jedenfalls habe ich ähnliches schon (teilweise) gemacht und das Ziel war nicht 1:1 das selbe wie beim Vollbackup.
Ich habe unter Linux geänderte config-files (so ziemlich alles, was man in Linux nachträglich konfiguriert, steht irgendwo in config files) in git eingepflegt. Dadurch hatte ich u.a. eine Übersicht darüber, was ich denn überhaupt nachträglich so alles configuriert habe. Das könnte man nun verknüpfen mit Automatisierungstechniken wie z.B. Ansible oder automatic installer (+ Daten backup recovery) und könnte auf diese Weise automatisiert die eigene Arbeitsumgebung jederzeit wieder rekonstruieren. Der Vorteil besteht darin, dass du jederzeit einen definierten Basiszustand hast und eine sehr gute Übersicht über diesen und sehr gute Möglichkeiten, diesen anzupassen.

Das funktioniert, erfordert aber ein wenig 'erweiterte' git-Kenntnisse und vor allem erfordert es viel Disziplin. Bei Servern ist das beschriebene Vorgehen ganz normal, für workstations eher weniger, unter anderem da an diesen deutlich öfters Änderungen vorgenommen werden.

 

[TomH22]

Mac: Time Machine
Neues OS wird installiert und alles andere ist wirklich 1:1 wie vorher

Bei iOS/iPadOS geht es ähnlich gut mit iCloud Backup. So „rund“ und ohne Drittanbieterlösungen gibt es das wirklich nur bei Apple.

Unter Windows und Linux ist das deutlich mehr Gebastel und man muss auch jeweils testen, ob der Restore im Ernstfall auch geht.

Ich probiere das nicht mehr, ich halte es eher wie @fgordon, die Nutzdaten müssen gesichert werden, ob nun Cloud oder „klassisch“ kann man geteilter Meinung sein. Es gibt ja auch „private“ Cloud Lösungen entweder proprietär wie von diversen NAS Herstellern, oder Opensource wie Nextcloud. Meine Sourcecode von meinen privaten Entwicklungsprojekten verwalte ich eh in git und mir wichtige Projekte liegen bei GitHub und Bitbucket.

Ich mache zwar auch gelegentlich Image Sicherungen des Betriebsystems, ob ich sie dann wirklich nutzen würde, ist eine andere Frage. Mir reicht es wenn ich einen neuen Computer in maximal einem Tag soweit habe, das ich alle wichtigen Arbeiten damit erledigen kann.

Meine Softwareprojekte laufen größtenteils in Linux VMs, die kann man klonen, Snapshots machen, etc. Zusätzlich kann man innerhalb von Linux noch Docker verwenden.

Wichtig ist halt, das man nicht irgendwelche komplexen über Jahre gewachsene Betriebssystem Installationen hat, wo man nicht mehr weiß, wie man sie reproduziert bekommt.

 

[TomH22]

Ich habe unter Linux geänderte config-files (so ziemlich alles, was man in Linux nachträglich konfiguriert, steht irgendwo in config files) in git eingepflegt. Dadurch hatte ich u.a. eine Übersicht darüber, was ich denn überhaupt nachträglich so alles configuriert habe.

Das ist halt Stärke und Schwäche von Linux zugleich, man kann viel anpassen, aber gerade wenn man was ausprobiert, ist es manchmal schwierig zu dokumentieren, was man gemacht hat. Vor allem wenn neben config Änderungen auch noch andere manuelle Änderungen gemacht wurden (wie etwas händisch eine Shared-Library installieren).
Ich versuche daher solche Änderungen auf ein Minimum zu beschränken. Für Dinge die ich öfter wieder brauche, versuche ich eine Doku zu machen. Config Files speichere ich öfter in GitHub Gists, man könnte natürlich auch ein richtiges GitHub Repo nehmen. Den Aufwand solche Anpassungen automatisiert einzuspielen halte ich für meine Zwecke für zu hoch. Dafür macht man das nicht häufig genug, der Testaufwand wäre höher als das veilleicht einmal im Jahr manuell zu machen.

Ich setze meine Entwicklungs VMs ca. jährlich neu auf, jeweils mit einem LTS Release eines Ubuntu Derivates (bei mir meist Lubuntu). Hintergrund ist, das ich viel mit Xiliinx/AMD FPGAs arbeite, und die proprietäre Vivado Suite ein meiner wichtigeren Tools ist. Immer wenn ich die upgrade, baue ich auch das "drumherum" neu. Ich nehme eine von Vivado unterstützte LTS Version (alles andere führt nur zu viel Frust...), dazu kommen dann alle anderen Tools (z.b. Python). Am System selbst wird nur dass angepasst, was man wirklich muss (meistens Swap Space vergrößern, xrdp einrichten, usw) Dauert meist in Summe einen halben Tag. Meine Git-Repos hängen als submodule unter einem "Master-Repo", damit ist der Dev-Code ganz schnell wieder eingespielt.
Manche tools wie ghdl oder den RISC-V gcc übersetze ich vom Source neu, für ghdl habe ich z.B. einen Docker Container, da es spezielle Abhängigkeiten (z.B. gnat - Ada Compiler) hat.

Seltener gebrauchte Sachen werden dann bei Bedarf installiert, wenn ich sie das erste mal brauche.

 

[BeBur]

Den Aufwand solche Anpassungen automatisiert einzuspielen halte ich für meine Zwecke für zu hoch. Dafür macht man das nicht häufig genug, der Testaufwand wäre höher als das veilleicht einmal im Jahr manuell zu machen.

War bei mir letztendlich auch so. Ich hatte das in einer Phase meines Lebens () gemacht, wo ich u.a. viel mit Desktop Environments und Window Managern rumgespielt habe und auch sonst viel 'optimiert' habe. Das war mir letztendlich zu viel Arbeit, heute versuche ich ebenfalls, Änderungen auf ein Minimum zu beschränken und begnüge mich einfach mit den 80-90% die ein Betriebssystem out of the box mir zur Verfügung stellt.

Ich weiß nicht, in welchem Kontext die Inhalte vom TE geschrieben wurden. In einem größeren Unternehmen mit vielen verwalteten Arbeitsplätzen und einer IT Abteilung, da ergeben die Überlegungen die der TE wiedergibt sehr viel Sinn. Bei uns werden auch etliche (non-Dev) Arbeitsplätze per Ansible, Images und Co. automatisiert ausgerollt und die zugehörigen 'playbooks' sind natürlich in einem git eingepflegt.

Aber für mich als Einzelperson oder zuhause, wo ich alle 3-5 Jahre mal tabula rasa mache? Da schlucke ich lieber die 4-8 Stunden Einrichtungszeit, denn die Automatisierung und die Pflege davon würde ein vielfaches der Zeit beanspruchen.

 

[Garmor]

Neben so automatischen Deploymentsystemen könnten auch so deklarative Systeme wie NixOS gemeint sein, die aus einem Konfigurationsfile gebaut werden, das man dann sichern kann.

 

[PHuV]

Ich habe unter Linux geänderte config-files (so ziemlich alles, was man in Linux nachträglich konfiguriert, steht irgendwo in config files) in git eingepflegt.

Und dann sicherst Du Dir beispielsweise den gesamten /etc-Bereich oder wie?

So habe ich in meinem ganzen Leben noch nicht gearbeitet. Da sind Backups effizienter. Und wenn Du Konfigurationen per Ansible oder Puppet rausrollst, hast Du eh eine zentrale Verwaltung und Konfiguration, die Du irgendwie sicherst, und auf die Clients kommt dann nur eine aktuelle Version. Konfigurationsdateien sind eher statisch, anders als Code. Daher sollte sich hier nicht permanent was ändern, geschweige denn brauchst Du trunks, branches, mußt mergen oder splitten, Berechtigungsverwaltung... Für Konfigurationsdateien sind Versionsverwaltung vollkommen überdimensioniert, der Aufwand rechtfertigt meiner Meinung nach keinesfalls den Nutzen.

Daher, für Code und dessen Verwaltung in Ordnung, ebenso wenn man dedizierte Konfigurationen macht für S|I|PaaC-Anwendungen, die man per Terraform und Scripten rausrollen will. Aber für reine eigene Konfigrationen halte ich es für daneben.

 

[BeBur]

Und dann sicherst Du Dir beispielsweise den gesamten /etc-Bereich oder wie?

Nein, nur die Dateien die ich händisch geändert habe.

Und wenn Du Konfigurationen per Ansible oder Puppet rausrollst, hast Du eh eine zentrale Verwaltung und Konfiguration, die Du irgendwie sicherst, und auf die Clients kommt dann nur eine aktuelle Version.

Und da kommen die konfigs dann ja auch aus einem git.

Konfigurationsdateien sind eher statisch, anders als Code. Daher sollte sich hier nicht permanent was ändern, geschweige denn brauchst Du trunks, branches, mußt mergen oder splitten, Berechtigungsverwaltung... Für Konfigurationsdateien sind Versionsverwaltung vollkommen überdimensioniert, der Aufwand rechtfertigt meiner Meinung nach keinesfalls den Nutzen.

Ja, das ist ein valider Punkt. Allerdings, wenn man so schrecklich viel anpasst im DE/WM Bereich (bei mir damals vim, awesome wm, ...), dann ändert sich doch recht lange relativ viel immer mal wieder. Und man macht auch mal Sachen kaputt ohne es sofort zu merken....
Ich sag nicht, dass das toll ist, ich schrieb ja schon, ich mache das schon eine Weile nicht mehr so .

 

[TomH22]

Die Frage ist, was für ein Ziel die Autoren, des vom TE genannten Buches erreichen wollen?

• Das der Entwickler im Falle möglichst schnell und nahtlos weiterarbeiten kann, wenn sein Rechner kaputt- oder verlorengegangen ist?
  Die Frage ist welche Zeit ist da akzeptabel? Also nach meiner Erfahrung fallen Entwickler viel häufiger durch banale Erkältungskrankheiten aus, als durch ausgefallene Client Computer. Wenn es also 24h dauert, bis der wieder arbeiten kann, ist es immer noch völlig ok. Also reicht es den Rechner von einer Standardinstallation, ein paar benutzerspezifischen Anpassungen (die gibt es in der Praxis ja fast immer) und einen Restore vom Code-Repo wieder herzustellen. Meist braucht man ja gar nicht 100% sofort wiederherzustellen, sondern erst mal nur die Sachen für das aktuell (eventuelle dringende) Projekt und dann in den nächsten Tagen den Rest. Selbst mit einem Linux oder Windows "Out-of-the-box" geht das in der Regel schnell.

• Eine reproduzierbare Build Umgebung schaffen?
  Da sehe ich heute Container oder VMs (wenn sich die Anwendung schlecht oder nicht für Container eignet) als Mittel der Wahl. Da habe ich dann auch viele Möglichkeiten wieder zu einem definierten Ausgangszustand zurückzukommen.

Bezüglich Desktop, etc:

Wenn ich mir meine Arbeit so anschaue, da nutze ich im "Frontend" drei Tools zu 90% der Zeit:

• Visual Studio Code - ich versuche mittlerweile wenn möglichst alles, in allen von mir benutzten Programmiersprachen damit zu machen. Auch z.B. Debugging. Spezialisierte Umgebungen sind zwar mitunter mächtiger, aber es nervt halt wenn man sich ständig umstellen muss.
• Chrome - naja für alles was man im Browser macht :-)
• Bash (auch unter Windows mit WSL)

Die Konfig von VSCode und Chrome werden zwischen allen meinen Computern synchronisiert. So lange diese drei Teile gleich aussehen und funktionieren ist es mir egal auf welchem Computer oder Host-Betriebssystem ich arbeite.