Debian OS - Spiegeln

Jump to last post
N

Networking

Neu angemeldet
Registriert
16 Dez. 2017
Beiträge
21
Ich spiele manchmal mit den Einstellungen rum und manchmal geht etwas schief und ich muss alles neu installieren. Das kann passieren, nicht sehr tragisch aber leider immer etwas zeitaufwendig.

Wenn man die OS neu installiert hat, dann will man natürlich die Softwares und Tools etc. die man gerne hat und über die Zeit auch personalisiert hat nachinstallieren. Diese Nachinstallationen sind natürlich Zeit konsumierend.

Kann man, wenn man die OS neu aufgesetzt hat und alle persönlichen modifikationen vorgenommen hat, dann einfach die gesamte OS kopieren/spiegeln und als .iso auf eine CD brennen. Damit wäre bei einer neuen Installation gleich alles wieder beim alten.

Kann mir jemand erklären, wie man das machen könnte?

Danke.
 
Networking schrieb:
Ich spiele manchmal mit den Einstellungen rum und manchmal geht etwas schief und ich muss alles neu installieren.
Zum Vergrößern anklicken....
Du hast 'ne komische Einstellung. Wenn ich das handhaben würde, wäre das für mich ein Desaster. Für manche Konfigurationen hab ich Monate oder Jahre gebraucht, bis es so funktioniert wie gewünscht.

Networking schrieb:
Kann man, wenn man die OS neu aufgesetzt hat und alle persönlichen modifikationen vorgenommen hat, dann einfach die gesamte OS kopieren/spiegeln und als .iso auf eine CD brennen. Damit wäre bei einer neuen Installation gleich alles wieder beim alten.
Zum Vergrößern anklicken....
Was ist denn "eine CD"? Redest du von dieser veralteten Umweltverschmutzung aus dem Anfang der 2000er?

Networking schrieb:
Kann mir jemand erklären, wie man das machen könnte?
Zum Vergrößern anklicken....
Es gibt mehrere Strategien:

1. Du willst das ganze OS spiegeln (Holzhammer)
Voraussetzungen:
  • Du hast eine Partition mit genügend Platz, um alle Daten Deines OS unterzubringen
  • Live-USB-Stick mit irgendeinem Linux drauf.
Vorgehen:
  1. Live-Linux booten
  2. alle Partitionen des Quell-OS mounten. Ich wollte jetzt einen Befehl hinschreiben. Aber ich kenn Dein Partitionsschema nicht. Wichtig dabei ist, auch die Partitionen (sofern vorhanden) für /home und /boot usw. mit zu mounten, z.B. nach /mnt/debian
  3. leere Partition mounten, z.B. nach /mnt/backup
  4. Code:
    Expand Collapse Copy 
    cd /mnt/debian
cp -a * /mnt/backup
Hast du dann was versaut, kannst du entweder die Copy-Partition im Grub (grub.cfg anpassen) gleich als neue OS-Platte verwenden oder du kopierst alles zurück. In meinem ersten Nebenjob als Linux-Admin hatten wir das so ähnlich. Aber da waren dann gleich beide Partitionen über den Grub auswählbar, so dass man beim Booten gleich problemlos zwischen der Haupt- und der Backuppartition wählen konnte.

2. Nur die Configs wegsichern
Persönliche Configs stehen in Deinem /home, globale Configs in /etc. Also reicht es, diese Verzeichnisse zu sichern.

3. Git
Du vergittest /etc und Dein /home. Baust du Mist, checkst du einfach die alte Version wieder aus.

Achtung:
Per Default sichert Git alle Dateien und Verzeichnisse, die mit . beginnen, nicht mit. Aber genau das willst du ja in Deinem /home. Also musst du die .gitignore noch anpassen.

4. btrfs
In BTRFS kannst du Snapshots erstellen. Bei Bedarf lädst du dann einfach einen älteren Stand

Networking schrieb:
Danke.
Zum Vergrößern anklicken....
Bitte sehr.
 
You do not have permission to view link please Anmelden or Registrieren

Das ist die unflexibelste Art das ganze Umzusetzen, auch mit dd.

Die nächstschlmampigste Lösung die deinem Vorschlag überlegen wäre:
dd if=/dev/sda of=/wo/immer/platz/ist/plattenimage.img

Das könnte man immer noch direkt mounten aber man belegt keinen ganzen logischen Datenträger der mindestens die selbe Größe haben muss (also Tendenziell eher viel zu groß ist). Was in unbrauchbarem da nicht allokiertem Speicher resultiert der ein Zurückkopieren sogar komplizierter macht. Beispiel: Wenn du die Partition dann entsprechend vergrößerst wird das zurückspielen richtig (Zeit)Aufwendig. Selbst wenn nicht mehr Speicher benötigt wird als in der Quelle vorhanden. Was da alles schiefgehen kann bei jemandem der diese Frage stellt will ich mir garnicht vorstellen sonst schreibe ich den Rest meines Lebens nur noch potentielle Probleme sortiert nach Wahrscheinlichkeit auf.

Falls man nicht vor hat das image zu mounten kann mans gleich noch packen und dabei zumindest den gesamten freien Speicher einsparen:
dd if=/dev/sda | gzip > /wo/immer/platz/ist/backup.gz

Besonders was den Plastikmüll angeht bin ich voll bei musv.
Die Dinger vermisse ich so wenig wie VHS oder Musikkassetten.
Die sind im Gegensatz zu USB Sticks nichtmal Maschinenwaschbar.(Das war nur halb ein Witz, 2/2 ausversehen mit einer Hose gewaschenen USB Sticks habens überstanden. Ohne Daten oder Funktionsverlust.)
 
Zuletzt bearbeitet:
  • Thread Starter Thread Starter
  • #5
OS ist nicht Live. OS ist installiert auf interne Festplatte.
 
1) Sichere dir dein Home-Verzeichniss
2) Sicher dir "etc" et cie....
3) var sichern
4) "apt list | grep installiert ODER grep installed > myInstalls.txt"

Wenn du noch irgendwas am laufen hast, wie mails (maildir) oder Co. das natürlich auch sichern.

Wenn du dein Debian einspielst, neue "Installation"

MyInstalls.txt so bearbeiten, das es nur noch Paketnamen enthält - geht mit einen halbwegs fähigem Editor enthält.

Danach installierst du das neue System, so wie du willst.

Du legst zum Beispiel den User "stefan" an... bei der Installation.

Danach kannst du dir "etc" kopieren auf das Zielsystem.
Dann holst du die Pakete "apt install < myInstalls.txt"

Installiert alle Pakete aus myInstall.txt die noch gültig sind. Ohne Versionsnummer und Co.

Notifys beachten beim Update/Upgrade.

Und zu guter letzt Home Verzeichniss und oder Maildir var/www wiederherstellen.

Und das Home Verzeichnis von "stefan", also alles da reinkopieren.

Mehr braucht es eigentlich meiner Meinung nach nicht.
 
@alter bekannter. Mein Befehl klont einfach nur, nicht mehr und nicht weniger. Sprich ich habe auf einer 2ten FP eine 1:1 Kopie. Ich werde es demnächst so machen wenn ich ich mir eine SSD hole.
 
@Laui: Das ist das Dümmste, was du einer SSD antun kannst.

Ums kurz zu machen: rsync -ahu QUELLE ZIEL

Zur eigentlichen Fragestellung: phre4k hat recht, BTRFS-Snapshots sind da eigentlich das Mittel der Wahl. Wenn das nicht möglich, umständlich oder sonst irgendwie konzeptbrechend ist, obiger Befehl macht genau das, was du willst. Achtung nur an einer Stelle: Sowas macht man entweder via LiveCD oder direkt aus dem System raus, dann aber mit Ausnahmen (kein /proc, /tmp, /run, /sys ...)
 
  • Thread Starter Thread Starter
  • #12
@Metal_Warrior:

Ja. Ich habe das Stichwort von phr3ak nachgeschlagen. Scheint ergiebig zu sein.

Zusatz info: Ich habe nur eine Partit. eingerichtet und die ist mit nur 20% des gesamten Internen Speicher belegt. 1/2TB habe ich noch frei zur verfügung. Da Linux von natur aus schon schön wenig MEM verbraucht, hätte ich also noch locker Platz die entstehende Data Abb. auf der Internen zu speichern.

Möchte aber noch schnell fragen, da ich die OS mit LUKS verschlüsselt install. habe, könnte das conflicts geben?
 
Ist zwar nicht mein Thread und ich will den auch nicht entführen, aber was ist so verkehrt daran mit der dd Methode meine HDD auf eine SSD zu klonen?
 
Jedesmal erst mit dd, (schonender wäre rsync) wegsichern/ISOs anlegen etc. wäre mir zu umständlich und zeitaufwändig, das eignet sich nur für Backups, aber nicht wenn man mal eben was testen will.

Bei meinen letzten "Experimenten" habe ich in der letzten Zeit immer mit
You do not have permission to view link please Anmelden or Registrieren
gearbeitet (Voraussetzung ist ein LVM System), da ging das Anlegen und Wiederherstellen innerhalb von Sekunden. Mit BTRFS habe ich aber noch keine Erfahrung.

Allerdings waren dass immer nur Volumes für virtuelle Maschinen, ein Snapshot des Host-System direkt habe ich noch nicht versucht, dort sollte es aber auch mit einer LiveCD gehen. Bei der Snapshot-Methode im laufenden Betrieb muss man aber auch auf Datenbanksysteme aufpassen, die liegen ja teilweise im RAM und benötigen eine extra Behandlung.

Man muss dabei auch aufpassen dass das Snapshot-Volume nicht platzt: das Snapshotvolume wächst mit jeder Änderung des original Volumes, es benötigt daher ausreichend Speicher wenn das zugehörige Volume geändert wird. Sollte das Snapshotvolume überlaufen, zerstört es sich selbst.

Für kurzfristige Experimente würde ich in etwa so vorgehen:
  1. System auf einem LVM-Volume installieren und einrichten <- Voraussetzung
  2. LVM-Snapshot erstellen
  3. Snapshot mounten und System hiervon booten
  4. Auf dem Snapshot die Tests durchführen und original LVM-Volume aus 1. in Ruhe lassen
  5. Entweder Snapshot verwerfen oder Snapshot zurück mergen wenn alles passt
Die Schritte 2/3/5 müssten dann mit einer LiveCD oder ähnlich statt finden. Oder man macht das ganze direkt mit LVM im Host+virtuellen Maschinen und spart sich die LiveCD.
 
Laui schrieb:
was ist so verkehrt daran mit der dd Methode meine HDD auf eine SSD zu klonen?
Zum Vergrößern anklicken....

Im Hinblick auf die SSD ist das jetzt nicht so schlimm. Während auf einer HDD beim Schreiben die Daten mit möglichst wenig Fragmentierung angelegt werden sollen, verteilt die SSD die Daten nach dem Prinzip, alle Sektoren möglichst gleichmäßig oft zu beschrieben, um die Lebensdauer zu erhöhen.

Es ist aber generell nicht sinnvoll, den Zustand eines OS generell dadurch zu sichern, dass man ein komplettes Image der Platte zieht. Das ist langsam und aufwändig.

X-Coder schrieb:
Mit BTRFS habe ich aber noch keine Erfahrung.
Zum Vergrößern anklicken....
You do not have permission to view link please Anmelden or Registrieren

You do not have permission to view link please Anmelden or Registrieren


Verwendet hatte ich es bisher mal unter SLED12. BTRFS wird von Suse in der Entwicklung stark vorangetrieben. Die legen dann für jedes Verzeichnis in Root, d.h. /usr, /var/, /var/irgendwas, /etc usw. eine eigene Partition an. Und bei jeder größeren Änderung wird erst mal ein Snapshot angelegt. Das Rollback erfolgt dann bequem über das Bootmenü. Den Snapshot wieder dauerhaft herzustellen, kann man dann über Snapper. Das hatte mir auf Arbeit schon einige Male die Haut gerettet.

Bei Suse (SLED12) ist das automatisch drin. Für die Konfiguration bei meinem System zu Hause war mir das bisher zu umständlich. Ich hatte auch noch nicht die Zeit, dass mal in einer VM zu testen.

Anstatt der ganzen Partitionen würde ich halt einfach gern / in ein Subvolume sichern. Allerdings weiß ich nicht, ob das Subvolume ein Unterverzeichnis des zu sichernden Hauptverzeichnisses sein kann.
 
Zuletzt bearbeitet:
You do not have permission to view link please Anmelden or Registrieren
Rein von der Logik her, sollten eigentlich "/mnt", "/media" und "/dev" oder ähnliches Ignoriert werden, sonst würde das ganze in einer ewigen Loop festhängen und von sich selbst, auf sich selbst kopieren...

Aber lustigerweise hab ich dazu auch nichts finden können, was das irgendwie textlich belegt, vielleicht ist die Frage zu selbstverständlich... das es es nicht tut - aber davon wäre auszugehen?
 
@Laui: dd kopiert dir alles, also auch Sektoren, auf denen nix liegt. Das ist völlig unsinnig (zusätzliche Belastung der SSD durch nutzlose Daten). Außerdem bricht es bei Lesefehlern sofort ab, was du ebenfalls nicht haben willst. Rsync kopiert nur die Daten, lässt mit -a aber alle Eigenschaften unangetastet (inklusive Symlinks), h ist nur human-Readable (falls man zusätzlich Loggen will) und u bedeutet Update, falls man einen Snapshot gern mal updaten möchte (dann werden nur Änderungen übertragen, nicht nochmal der ganze Sums wie bei cp. Außerdem kann rsync SSH, was ein nettes zusätzliches Gimmick ist.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben