• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

Debian OS - Spiegeln

Networking

Neu angemeldet

Registriert
16 Dez. 2017
Beiträge
29
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.
 

musv

Bekannter NGBler

Registriert
15 Juli 2013
Beiträge
3.453
Ort
/dev/null
Ich spiele manchmal mit den Einstellungen rum und manchmal geht etwas schief und ich muss alles neu installieren.
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.

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.
Was ist denn "eine CD"? Redest du von dieser veralteten Umweltverschmutzung aus dem Anfang der 2000er?

Kann mir jemand erklären, wie man das machen könnte?
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:
    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

Bitte sehr.
 

alter_Bekannter

N.A.C.J.A.C.

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
@Laui:
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:

Networking

Neu angemeldet

Registriert
16 Dez. 2017
Beiträge
29
  • Thread Starter Thread Starter
  • #5
OS ist nicht Live. OS ist installiert auf interne Festplatte.
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.561
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.
 

Steeve

Vereinsheimer
Barkeeper

Registriert
15 Juli 2013
Beiträge
41.121
@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.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@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 ...)
 

Networking

Neu angemeldet

Registriert
16 Dez. 2017
Beiträge
29
  • 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?
 

Steeve

Vereinsheimer
Barkeeper

Registriert
15 Juli 2013
Beiträge
41.121
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?
 

X-Coder

Aktiver NGBler

Registriert
14 Juli 2013
Beiträge
149
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 LVM-snapshots 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.
 

musv

Bekannter NGBler

Registriert
15 Juli 2013
Beiträge
3.453
Ort
/dev/null
was ist so verkehrt daran mit der dd Methode meine HDD auf eine SSD zu klonen?

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.

Mit BTRFS habe ich aber noch keine Erfahrung.
https://www.linux.com/learn/how-create-and-manage-btrfs-snapshots-and-rollbacks-linux-part-2
https://wiki.ubuntuusers.de/Befehle_Btrfs-Dateisystem/#btrfs-subvolume-snapshot

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:

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.561
@musv: 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?
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@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.
 
Oben