debianforum.de

Verfasst: **06.04.2019 23:53:47**

Hallo zusammen,

ich hoffe, ich bin in diesem Forum richtig und auch in der Richtigen Rubrik gelandet.
Entschuldigt bitte vorweg den langen Text, der Übersichtlichkeit halber habe ich den in mehrere Abschnitte gegliedert.
Ich hoffe, Ihr könnt mir bei meinem Vorhaben helfen und freue mich über Ratschläge von erfahrenen Linuxnutzern.

Vorstellung meinerseits:

Da dies mein erster Beitrag hier ist, möchte ich mich kurz vorstellen.
Ich bin mitte 20, Student eines technischen Studiengangs, jedoch nicht Informatiker. Seit ich Computer nutze war ich bei Windows und habe auch für den Unialltag Windows verwendet, vor einiger Zeit aber mit Linux auf einem RaspberryPi etwas experimentiert.

Da Windows 8.1 bald nicht mehr supportet wird von Microsoft, hätte ich früher oder später auf Windows 10 umsteigen müssen, aus diversen Gründen bin ich von Windows aber seit längerer Zeit eher genervt, praktisch und von meiner fundamentalen Einstellung her.
Da also sowieso irgendwann ein Systemwechsel anstand, habe ich diesen vorgezogen und meine kompletten PC auf Debian umgestellt. Soweit sehr zufriedenstellend, alles wichtige läuft und ich bin zufrieden.
Da mir Datensicherheit recht wichtig ist, stehe ich nur vor dem Problem wie ich meine Backus organisiere.

Mein Problem:
Ich finde es sinnvoll, das Thema Datensicherung ernst zu nehmen bevor die Festplatte kaputt geht oder irgendetwas anderes gewaltig schief läuft.
Nicht private Daten von mir spiegle ich ohnehin in eine Cloudd auf deutschen Servern. Unter Windows hatte ich immer 2mal im Jahr meine Festplanttenpartitionen auf eine weitere Festplatte gespiegelt, sodass, wenn z.B. mein PC geklaut wird, ich den damaligen Stand zurückspiegeln könnte auf einem identischen PC.
Nun nutze ich Debian Stretch und habe bei der Installation LUKS verwendet, um mein System zu verschlüsseln. Wie vorher mit Gparted die Partition zu spiegeln geht daher nicht mehr.
Vorher hatte ich meine 3TB-Externe Festplatte und meine Partitionen auf dem PC einfach 2 mal im Jahr oder bei Bedarf kopiert.

Wie das unter Luks gehen könnte, habe ich mir folgendermaßen überlegt:
Ziel: 3TB-HDD (mit Veracrypt Container) und einen USB-Stick (mit Veracrypt-Container) sowie meine Festplatte (500GB SSD, LUKS) vom PC auf zwei 5TB HDDs spiegeln (also alle backups auf zwei identischen Festplatten). Eine davon wird außerhalb gelagert.
Die 3TB sowie den USB-Stick kann ich ganz einfach mit Gparted klonen (wie lange das dauert ist mir bei 2x im Jahr egal). Mit Gparted kann ich Luks aber nicht kopieren.
Meine Idee wäre es, auf der 5TB-Backup-HDD jeweils eine neue Luks Partition (etwas größer als 500GB) zu erstellen, die zu öffnen bei Clonezilla und mit dd die ebenfalls geöffnete LUKS-Partition auf meinem PC zu kopieren.
Im Fall der Fälle würde ich auf dem PC eine Boot-partition erstellen, den Rest der SSD mit einer LUKS-Partition versehen und die Daten von der HDD wieder per dd zurückschieben.

Nun meine Frage:
Funktioniert dieses vorgehen? (abgesehen davon, dass es länger dauert)
Die Bootpartition würde ich dabei ja nicht mitkopieren. Kriege ich im Fall der Fälle meine Partition wieder bootfähig? Bzw ist es möglich eine bootfähige LUKS-Partition leer zu erstellen und dann sozusagen zu füllen?
Ziel ist es ja, dass, wenn meine Festplatte den Geist aufgibt oder mein PC weg ist, ich einen identischen PC wieder in den Zustand vom Backup versetzen kann ohne alles neu installieren zu müssen, Einstellungen zu ändern etc.

Über bessere Vorschläge freue ich mich natürlich auch.
Ebenso über ein Urteil von Leuten, die mehr Linuxwissen haben und beurteilen können, ob mein Vorgehen überhaupt funktioniert.

Beste Grüße
Phijo

Verfasst: **07.04.2019 00:04:54**

Ich habe bis jetzt nur Gnome Disks bzw. Laufwerke dazu verwendet. Einfach öffnen, die zu sichernde Platte auswählen und oben wo die drei Längsstriche sind draufklicken und auf "Laufwerksabbild erzeugen ...". Könntest sogar das mit einem Live-Medium machen.

Das habe ich bei zwei SSDs gemacht. Und auch wiederhergestellt. Klappte einwandfrei. Auf den Platten war auch eine Windows-Partition.

Beachten muss man, dass man gleich große oder größere Datenträger verwendet. Ansonsten könntest du dir auch CloneZilla anschauen(Link zu distrowatch.com).

Verfasst: **07.04.2019 08:30:39**

Phijo hat geschrieben:
06.04.2019 23:53:47
Ziel ist es ja, dass, wenn meine Festplatte den Geist aufgibt oder mein PC weg ist, ich einen identischen PC wieder in den Zustand vom Backup versetzen kann ohne alles neu installieren zu müssen, Einstellungen zu ändern etc.

Wenn Platz und Zeit irrelevant sind, könntest du das gesamte Laufwerk des PCs mit etwa dd auf eine externe Platte schieben. Im Falle eines Laufwerksschadens kannst du dann einfach ein neues Laufwerk einbauen, ein Livesystem booten, und die Sicherung in einem Stück zurückschreiben; anschließend könntest du das System ohne weitere Nacharbeiten booten.

Es bietet sich an, System- und Nutzerdaten zu trennen (also /home auf eine eigene Partition zu legen), dann könnte man die Nutzerdaten auf herkömmliche, platz- und zeitsparende Art dateibasiert und inkrementell sichern, während man das System lediglich bei größeren Änderungen zu spiegeln braucht.

Verfasst: **07.04.2019 12:25:26**

Phijo hat geschrieben:
06.04.2019 23:53:47
Meine Idee wäre es, auf der 5TB-Backup-HDD jeweils eine neue Luks Partition (etwas größer als 500GB) zu erstellen, die zu öffnen bei Clonezilla und mit dd die ebenfalls geöffnete LUKS-Partition auf meinem PC zu kopieren.

Du hast da irgendwie einen Knoten drin. Was mir noch nicht ganz klar ist: Wie ist dein System wirklich Partitioniert? Hast du LVM mit Verschlüsselung oder nur eine verschlüsselte Partition mit unverschlüsseltem Boot? Bitte die Ausgabe von

lsblk

Wenn du per dd deine per Luks verschlüsselte Partition kopieren willst, dann muss sie nicht geöffnet sein.

Ich würde das so lösen: Backup-Festplatte Partitionieren, per Luks verschlüsseln, ext4-Dateisystem anlegen. Dann per rsync, tar etc. die Daten deiner Installation auf die geöffnete Backup-Festplatte übertragen. Zum Zurückspielen musst du dann nur die Daten von /, /home etc wieder auf das neue System spielen.

Verfasst: **07.04.2019 18:34:48**

Danke als allererstes für Eure Antworten!

OrangeJuice hat geschrieben:
07.04.2019 00:04:54
Ich habe bis jetzt nur Gnome Disks bzw. Laufwerke dazu verwendet. Einfach öffnen, die zu sichernde Platte auswählen und oben wo die drei Längsstriche sind draufklicken und auf "Laufwerksabbild erzeugen ...". Könntest sogar das mit einem Live-Medium machen.

Das habe ich bei zwei SSDs gemacht. Und auch wiederhergestellt. Klappte einwandfrei. Auf den Platten war auch eine Windows-Partition.

Beachten muss man, dass man gleich große oder größere Datenträger verwendet. Ansonsten könntest du dir auch CloneZilla anschauen(Link zu distrowatch.com).

Sicher, dass das auch mit Luks-Partitionen im verschlüsselten Zustand geht? Mit Gparted als Live-System kann ich die Luks-Partition leider nicht kopieren.
Clonezilla und die Nutzung von Cryptsetup war ja eigentlich meine Idee....

niemand hat geschrieben:
07.04.2019 08:30:39

Phijo hat geschrieben:
06.04.2019 23:53:47
Ziel ist es ja, dass, wenn meine Festplatte den Geist aufgibt oder mein PC weg ist, ich einen identischen PC wieder in den Zustand vom Backup versetzen kann ohne alles neu installieren zu müssen, Einstellungen zu ändern etc.
Wenn Platz und Zeit irrelevant sind, könntest du das gesamte Laufwerk des PCs mit etwa dd auf eine externe Platte schieben. Im Falle eines Laufwerksschadens kannst du dann einfach ein neues Laufwerk einbauen, ein Livesystem booten, und die Sicherung in einem Stück zurückschreiben; anschließend könntest du das System ohne weitere Nacharbeiten booten.

Zeit wäre in der Tat irrelevant, Platz weniger. Ich möchte ja am Ende zwei identische Backups produzieren mit einem Abbild meines Systems, meiner externen Festplatte und etwas Krams, alles sauber in Partitionen getrennt, die ich bei Bedarf wiederherstellen kann.
Dafür habe ich eine Platte mit 5TB, welche ich natürlich mit dd auf eine zweite Platte spiegeln kann.
Problem nur: Mein Luks ist 0,5TB groß und es muss noch mehr auf die Platte weshalb ich überlegt habe eine Luks-Partition auf der externen zu erstellen und dann das ext-4 Filesystem in meinem Luks von meinem PC auf das Luks auf der Platte zu kopieren. Sonst wird das zurückkopieren u.U. schwierig.

Es bietet sich an, System- und Nutzerdaten zu trennen (also /home auf eine eigene Partition zu legen), dann könnte man die Nutzerdaten auf herkömmliche, platz- und zeitsparende Art dateibasiert und inkrementell sichern, während man das System lediglich bei größeren Änderungen zu spiegeln braucht.

Ein Backup meiner wichtigsten Nutzerdaten wird bereits per Cloud, später vielleicht per Duplicati+Cloud gesichert. Es geht mir lediglich um ein Komplettbackup aller meiner Daten, also PC, Externe, Partition mit Krams etc.

debianoli hat geschrieben:
07.04.2019 12:25:26

Phijo hat geschrieben:
06.04.2019 23:53:47
Meine Idee wäre es, auf der 5TB-Backup-HDD jeweils eine neue Luks Partition (etwas größer als 500GB) zu erstellen, die zu öffnen bei Clonezilla und mit dd die ebenfalls geöffnete LUKS-Partition auf meinem PC zu kopieren.
Du hast da irgendwie einen Knoten drin. Was mir noch nicht ganz klar ist: Wie ist dein System wirklich Partitioniert? Hast du LVM mit Verschlüsselung oder nur eine verschlüsselte Partition mit unverschlüsseltem Boot? Bitte die Ausgabe von lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 465,8G 0 disk
├─sda1 8:1 0 243M 0 part /boot
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 465,5G 0 part
└─sda5_crypt 254:0 0 465,5G 0 crypt
├─Debian--vg-root 254:1 0 457,8G 0 lvm /
└─Debian--vg-swap_1 254:2 0 7,7G 0 lvm [SWAP]

Wenn du per dd deine per Luks verschlüsselte Partition kopieren willst, dann muss sie nicht geöffnet sein.

Das ist mir bewusst, ich möchte nur noch weitere Partitionen auf der Platte sichern. Am Ende möchte ich 2 5TB Platten als Spiegel aller meiner Daten haben, eine davon außer Haus gelagert.
Kann ich mit dd nicht nur die ganze Platte kopieren oder eine Partition auf eine gleiche oder größere Partition?

Jetzt wo Du es sagst:Ich könnte ja die ganze 500GB-Platte klonen, der Rest der 5TB bleibt leer, dann könnte ich da meine restlichen Partitionen hinkopieren. Anschließend kann ich die 5TB per dd ebenfalls auf eine zweite 5TB-Platte klonen und hätte meine zwei backups. Nur wie stelle ich dann bei Bedarf meine Daten wieder her?

Ich würde das so lösen: Backup-Festplatte Partitionieren, per Luks verschlüsseln, ext4-Dateisystem anlegen. Dann per rsync, tar etc. die Daten deiner Installation auf die geöffnete Backup-Festplatte übertragen. Zum Zurückspielen musst du dann nur die Daten von /, /home etc wieder auf das neue System spielen.

So ähnlich habe ich es ja vor. Die nicht verschlüsselte Boot-Partition kann ich ja sogar direkt kopieren. Ich hatte nur vor die 5Tb externe zu partitionieren, also >500GB für Luks zu reservieren, dort ein Luks Laufwerk zu erstellen und beide Luks-Partitionen zu öffnen. Anschließend kann ich per dd den Inhalt von meinem Laptop (also das komplette unverschlüsselte ext-4 Filesystem) auf Luks in der externen kopieren. Außerhalb dieses Schrittes wäre beides verschlüsselt.Die Frage nur: Funktioniert das so wie ich es mir vorstelle? Und bootet das, wenn ich es umgekerht wiederherstelle?

Beste Grüße
Phijo

Verfasst: **08.04.2019 09:34:36**

dd kann zwar nur nur ganze Devices klonen (als Quelle), kann diese Daten aber auch in eine Datei schreiben. Ziel muss nicht ein blankes Device sein.

Du kannst also mit dd mehrere Partitionen oder Platte auf ein Dateisystem klonen. Wichtig ist nur, dass das Dateisystem mit derart grossen Dateien umgehen kann.

Verfasst: **08.04.2019 09:48:56**

Glur hat geschrieben:
08.04.2019 09:34:36
dd kann zwar nur nur ganze Devices klonen (als Quelle)

dd kann ganz prima auch Dateien lesen (die Devicefiles unter /dev sind für ein Programm genau das: Dateien), man kann damit die zu lesenden Bereiche innerhalb einer Quelle bitgenau bestimmen (ist z.B. interessant, wenn man eine ganze Platte mit mehreren Partitionen als Image hat, und nur eine bestimmte Partition auslesen möchte) und einige andere lustige Dinge damit machen (siehe Manpage). Die Aussage, dass es „nur ganze Devices klonen“ könne, wird dem Programm nicht gerecht – deswegen dieser Einwurf, sorry für’s OT.

Verfasst: **08.04.2019 11:24:07**

Phijo hat geschrieben:
07.04.2019 18:34:48
So ähnlich habe ich es ja vor. Die nicht verschlüsselte Boot-Partition kann ich ja sogar direkt kopieren. Ich hatte nur vor die 5Tb externe zu partitionieren, also >500GB für Luks zu reservieren, dort ein Luks Laufwerk zu erstellen und beide Luks-Partitionen zu öffnen. Anschließend kann ich per dd den Inhalt von meinem Laptop (also das komplette unverschlüsselte ext-4 Filesystem) auf Luks in der externen kopieren. Außerhalb dieses Schrittes wäre beides verschlüsselt.Die Frage nur: Funktioniert das so wie ich es mir vorstelle? Und bootet das, wenn ich es umgekerht wiederherstelle?

Irgendwie ist das zu kompliziert für mich, was du da machen willst. Bislang verstehe ich deinen Plan so:
Du legst auf der externen HD eine mit Luks verschlüsselte Partition an. In die kopierst du per dd die komplette (!) unverschlüsselte System-Partition, vermutlich in eine Image-Datei. Für den Schritt würde ich nicht unbedingt dd nehmen, da die Datei sonst unnötig groß wird. Wenn du unbedingt dd nehmen willst, dann nur mit einer Pipe zu gzip oder einem anderen Komprimierungs-Tool. Übrigens: Das bringt dir allerdings nix, wenn du die ganze Partition sda5 per dd sichern willst, da dies eine verschlüsselte Partition ist und damit in jedem Block zufällige Werte stehen.

Noch dazu hast du ein LVM am Laufen. Bei LVM gibt es auch die Möglichkeit, Schnappschüsse der Partiton zu machen. Aber damit kenn ich mich nicht so gut aus.

Was nutzt du da überhaubt für eine Partitionierung? MBR oder GPT?

Ich würde das System so sichern, bei der Verwendung von MBR (was Sinn machen würde, da du nur eine 500 GB Harddisk im Einsatz hast):

1. Sichern des MBR per dd:

Code: Alles auswählen

dd if=/dev/sda of=MBR.file bs=512 count=1

2. Sichern der UUID-Bezeichnungen deines Systems: Rechner hochfahren und die Ausgabe von blkid in einer Datei auf deiner Sicherungs-HD speichern.
3. /boot zB per tar oder dd in ein File sichern
4. Die Metadaten des LVM sichern, damit man beim Wiederherstellen des Systems das LVM wieder so hat wie zuvor (wie das geht, muss dir jemand anderes sagen. Ich nutze kein LVM).
5. Die Daten der System-Partition Debian--vg-root auf das Backup-Tool per rsync, tar oder ähnlichem sichern.

Bei Zurückspielen des Systems auf eine neue Platte musst du dann nur noch den MBR per dd einspielen und die Datei-Systeme der Partitionen mit den gesicherten, exakt gleichen UUIDs wieder anlegen. Dann kannst du die Daten wieder ins System spielen.

Verfasst: **08.04.2019 15:34:57**

Hallo,

Ich würde einmal die relevanten System Partitionen auf eine verschlüsselte, externe Platte spiegeln per dd und dann noch ein Datenbackup vornehmen von /home, /etc, /root.
Nur für alle Fälle.

Phijo hat geschrieben:So ähnlich habe ich es ja vor. Die nicht verschlüsselte Boot-Partition kann ich ja sogar direkt kopieren. Ich hatte nur vor die 5Tb externe zu partitionieren, also >500GB für Luks zu reservieren, dort ein Luks Laufwerk zu erstellen und beide Luks-Partitionen zu öffnen. Anschließend kann ich per dd den Inhalt von meinem Laptop (also das komplette unverschlüsselte ext-4 Filesystem) auf Luks in der externen kopieren. Außerhalb dieses Schrittes wäre beides verschlüsselt.Die Frage nur: Funktioniert das so wie ich es mir vorstelle? Und bootet das, wenn ich es umgekerht wiederherstelle?

Einfach die ganze, externe Backup Platte per Luks verschlüsseln und alle Backup Daten in die verschlüsselte Platte legen. Ist vermutlich am einfachsten. Bei den Backuplösungen ist einfach immer gut

Damit musst du dann nur von einer Live CD starten, die verschlüsselte Festplatte über cryptsetup luksOpen öffnen und das vorher erstellte image über
dd if=/name-des-image.img of=/sdX bs=64M status=progress

zurückspielen. Gzip ist auch nicht verkehrt, kann aber wie bei mir grad passiert eine negative Kompression verursachen. Woran das genau lag, weiss ich leider nicht.

PS : Mach dir ebenfalls eine Kopie vom Luks Header deines Systems und kopier sie in die verschlüsselte, externe Platte, man weiss ja nie:
cryptsetup luksHeaderBackup --luks-header-file sdX.backup

LVM Header kann man über vgcfgbackup sichern. Habe darin aber keine praktischen Erfahrungen.

Bis dann!

Verfasst: **08.04.2019 15:45:11**

Wenn ich das richtig sehe ist dir Zeit und platz reichlich Wurst.
Mein dicke Empfehlung an dich:
Lass die Finger von irgend welchen intelligent-Lösungen alla gparted und ähnliches und kopiere einfach die Platte.
Boote einfach irgend eine LiveCD. (Du willst kein System kopieren während es läuft. Das macht nur Müll.) Da kannst du einfach die Datei /dev/sda bzw. /dev/sdb etc auf die externen Platten kopieren. (Ganz normal mit rechtsklick kopieren und dann halt in einen Ordner deiner Wahl einfügen.) Das kannst du dann auf jede genauso große (oder größere) Platte wieder einfügen. Und du hast eine 1:1 Kopie ohne irgend welche Veränderungen, die dir Bootfähigkeit o.ä. kaputt machen.
Selbstverständlich geht das auch auf der Kommandozeile mit cp:

Code: Alles auswählen

cp /dev/sda /media/exter1/platte1.img

und zum wiederherstellen auf die neue Platte:

Code: Alles auswählen

cp  /media/exter1/platte1.img /dev/sda

Wenn du das nochmal beschleunigen willst, kannst du mit tee auf beide externen gleichzeitig kopieren.
Annahme ist, dass backup Platten unter /media/exter1 und /media/extern2 liegen und die zu kopierende Platten sda und der USB-Stick sdd ist:

Code: Alles auswählen

cat /dev/sda | tee /media/exter1/platte1.img > /media/exter2/platte1.img
cat /dev/sdd | tee /media/exter1/stick.img > /media/exter2/stick.img

Verfasst: **08.04.2019 15:49:58**

wanne hat geschrieben:
08.04.2019 15:45:11
Wenn ich das richtig sehe ist dir Zeit und platz reichlich Wurst.
Mein dicke Empfehlung an dich:
Lass die Finger von irgend welchen intelligent-Lösungen alla gparted und ähnliches und kopiere einfach die Platte.
Boote einfach irgend eine LiveCD. (Du willst kein System kopieren während es läuft. Das macht nur Müll.) Da kannst du einfach die Datei /dev/sda bzw. /dev/sdb etc auf die externen Platten kopieren. (Ganz normal mit rechtsklick kopieren und dann halt in einen Ordner deiner Wahl einfügen.) Das kannst du dann auf jede genauso große (oder größere) Platte wieder einfügen. Und du hast eine 1:1 Kopie ohne irgend welche Veränderungen, die dir Bootfähigkeit o.ä. kaputt machen.
Selbstverständlich geht das auch auf der Kommandozeile mit cp:
Code: Alles auswählen
cp /dev/sda /media/exter1/platte1.img
und zum wiederherstellen auf die neue Platte:
Code: Alles auswählen
cp  /media/exter1/platte1.img /dev/sda
Wenn du das nochmal beschleunigen willst, kannst du mit tee auf beide externen gleichzeitig kopieren.
Annahme ist, dass backup Platten unter /media/exter1 und /media/extern2 liegen und die zu kopierende Platten sda und der USB-Stick sdd ist:
Code: Alles auswählen
cat /dev/sda | tee /media/exter1/platte1.img > /media/exter2/platte1.img
cat /dev/sdd | tee /media/exter1/stick.img > /media/exter2/stick.img

Das man eine Partition über cp kopieren kann, habe ich noch gar nie in Betracht gezogen

Ich habe immer ein image über dd erstellt.

Ich würde es auch so machen wie von wanne vorgeschlagen.
Machs nicht über Tools sondern über die CLI, damit behälst du die hunderprozentige Kontrolle.

Verfasst: **08.04.2019 15:53:57**

Gzip ist auch nicht verkehrt, kann aber wie bei mir grad passiert eine negative Kompression verursachen. Woran das genau lag, weiss ich leider nicht.

Kompression lebt davon, dass es Strukturen wiedererkennt. Sind deine Daten verschlüsselt, ist da im Optimalfall wenig wiederzuerkennen.Ist sozusagen ein guter Test für deine Verschlüsselung: Lässt sich da was komprimieren hat die Krypo einen Fehler.

Das man eine Partition über cp kopieren kann, habe ich noch gar nie in Betracht gezogen
Ich habe immer ein image über dd erstellt.

Ich verstehe das nicht so richtig, woher diese ganze dd-Zeug kommt.
dd ist ein Spezialtool aus der vor Unix-Zeit, das synchron (und damit stinke lahm) Blöck hin und her schiebt und dabei noch allerlei Spielereien alla Konvertierungen, Teilkopieen... kann.
In 99% der fälle ist man mit cat oder cp deutlich besser bedient.

Verfasst: **08.04.2019 16:04:28**

wanne hat geschrieben:
08.04.2019 15:53:57
In 99% der fälle ist man mit cat oder cp deutlich besser bedient.

Ich darf das offensichtlich unterbewertete

pv einwerfen? Hat zwar als einzigen Mehrwert nur den Fortschrittsbalken (samt ETA), aber manch einer mag das.

Verfasst: **08.04.2019 16:05:32**

wanne hat geschrieben:
08.04.2019 15:53:57

Gzip ist auch nicht verkehrt, kann aber wie bei mir grad passiert eine negative Kompression verursachen. Woran das genau lag, weiss ich leider nicht.
Kompression lebt davon, dass es Strukturen wiedererkennt. Sind deine Daten verschlüsselt, ist da im Optimalfall wenig wiederzuerkennen.Ist sozusagen ein guter Test für deine Verschlüsselung: Lässt sich da was komprimieren hat die Krypo einen Fehler.
Das man eine Partition über cp kopieren kann, habe ich noch gar nie in Betracht gezogen
Ich habe immer ein image über dd erstellt.
Ich verstehe das nicht so richtig, woher diese ganze dd-Zeug kommt.
dd ist ein Spezialtool aus der vor Unix-Zeit, das synchron (und damit stinke lahm) Blöck hin und her schiebt und dabei noch allerlei Spielereien alla Konvertierungen, Teilkopieen... kann.
In 99% der fälle ist man mit cat oder cp deutlich besser bedient.

wanne hat geschrieben:Kompression lebt davon, dass es Strukturen wiedererkennt. Sind deine Daten verschlüsselt, ist da im Optimalfall wenig wiederzuerkennen.Ist sozusagen ein guter Test für deine Verschlüsselung: Lässt sich da was komprimieren hat die Krypo einen Fehler.

In der Tat. Es handelte sich um eine mit Luks verschlüsselte Systempartition, dessen erstelltes Image ich mit gzip komprimieren wollte. Nach der Kompression war das komprimierte File gleich gross. Ein gzip -l hat jedoch eine - Kompression angegeben. Das heisst dann wohl, dass meine Verschlüsselung ganz ok ist

wanne hat geschrieben:In 99% der fälle ist man mit cat oder cp deutlich besser bedient.

Das werde ich definitiv in meine Praxisroutine implementieren

Danke!

dd hat vermutlich weiterhin seine Berechtigung, wenn man eine Partition oder ganze Platte mit Zufallszahlen überschreiben lassen will. Ich nehme an, das geht nur mit dd und nicht mit cp.

Verfasst: **08.04.2019 16:36:36**

Trollkirsche hat geschrieben:
08.04.2019 16:05:32
dd hat vermutlich weiterhin seine Berechtigung, wenn man eine Partition oder ganze Platte mit Zufallszahlen überschreiben lassen will. Ich nehme an, das geht nur mit dd und nicht mit cp.

Ich glaube, es war auch Wanne, der mal dieses Beispiel favorisiert hat.... was ich mir (wie jetzt auch) damals mal notiert habe:

Code: Alles auswählen

cat /dev/zero >/dev/sdX

Verfasst: **08.04.2019 16:39:50**

Ich darf das offensichtlich unterbewertete pv einwerfen? Hat zwar als einzigen Mehrwert nur den Fortschrittsbalken (samt ETA), aber manch einer mag das.

ICh mag das aus. Habe es mal außen vor gelassen, weil es bei vielen (Live-)Distros nicht dabei ist.

Ich glaube, es war auch Wanne, der mal dieses Beispiel favorisiert hat.... was ich mir (wie jetzt auch) damals mal notiert habe:

Ja. Das geht genauso. Wobei in dem Fall dd wenigstens nicht langsamer ist, weil /dev/zero synchron und asynchron gleich schnell ist.

Verfasst: **08.04.2019 16:41:53**

wanne hat geschrieben:
08.04.2019 15:45:11
Boote einfach irgend eine LiveCD. (Du willst kein System kopieren während es läuft. Das macht nur Müll.)

Wenn man das richtig macht, macht da nix Müll. Geht mit tar und der exclude-from Option vom laufenden System aus. Ich sichere so immer meinen Arbeitsrechner und hatte dabei noch keine Probleme.

Code: Alles auswählen

tar -cvz --exclude-from=EXCLUDE_LISTE.datei -f bkp.tar.gz /

Und in der Datei EXCLUDE_LISTE.datei steht alles, was nicht mit soll. Bei mir zB das User-Home und natürlich der Mount-Punkt der Sicherungs-Festplatte in /media

Code: Alles auswählen

/proc/*
/sys/*
/home/*
/dev/*
/run/*
/media/*

Verfasst: **08.04.2019 17:05:34**

debianoli hat geschrieben:
08.04.2019 16:41:53

wanne hat geschrieben:
08.04.2019 15:45:11
Boote einfach irgend eine LiveCD. (Du willst kein System kopieren während es läuft. Das macht nur Müll.)
Wenn man das richtig macht, macht da nix Müll. Geht mit tar und der exclude-from Option vom laufenden System aus. Ich sichere so immer meinen Arbeitsrechner und hatte dabei noch keine Probleme.
Code: Alles auswählen
tar -cvz --exclude-from=EXCLUDE_LISTE.datei -f bkp.tar.gz /

Ja. Beim erstellen vom Backup hast du auch noch keine Probleme. Erst beim wieder herstellen wirst du feststellen dass

Alle Hardlinks fehlen
Dein stage 1 (und 1.5) vom Bootloader weg ist
Die letzte paar Minuten aus jeder Datenbank fehlen, weil die gecached sind.
Praktisch jedes IO-Intensive Programm nicht mehr hochkommt, weil deine Daten inkonsistent sind.
Alle ACLs fehlen. (OK, da wirst du keine haben)
SELinux contexte kaputt sind
extendet attributes fehlen
Capabillities fehlen

Nein. Ein Backup mit tar funktioniert nur mit kalten klassischen "dummen" Daten. Mit anderem Zeug kann man das auch machen. Ist dann halt scheiße. Gibt schon gründe, warum alle Professionellen Virtualisierungsumgebungen mit "Enterprise"-Featrues alla Snapshots haben wollen.

Verfasst: **09.04.2019 02:08:46**

Was machen cp und dd eigentlich anders? Und mit dd kann ich ja auch ein Image erstellen. (das hatte ich heute Mittag recherchiert und andersherum für Live-Sticks bereits genutzt) Wie unterscheidet sich das von einem Image mit cp?
In den aller meisten Fällen ist das Ergebnis das selbe. Der grundsätzliche Unterschied ist, dass dd immer volle Blöcke ließt und dann volle Blöcke schreibt: Sprich du brauchst (bei gleicher lese und schreib-geschwindigkeit) die doppelte Zeit. Dafür kannst du dich darauf verlassen, dass in der Ausgabedatei nicht mal 517Byte sind sonder immer ganze Vielfache von bs sind. Daneben kannst du bei einem input-device, dass monitored, welche Blöcke gelesen wurden dich darauf verlassen, dass maximal einer noch nicht geschrieben wurde. Alles Sachen die du nicht brauchst.
cp (und cat) weisen Linux an schon mal "poaktiv" weiter zu lesen, während es gerade noch schreibt. Lesen und Schreiben passieren also gleichzeitig. Dafür hat dd halt noch nen Haufen Zusatzoptionen. (Die du alle nicht brauchst.)

Verfasst: **09.04.2019 08:02:21**

Phijo hat geschrieben:
09.04.2019 02:08:46
Was ist bei dd eigentlich ne sinnvolle Größe für bs?

Alles, was größer der Blockgröße, kleiner als der Cache und ein Vielfaches von 1024 ist. Die Angabe ist im Grunde für die ursprüngliche Aufgabe von dd von Bedeutung (als Größe für skip, seek, count). Ich nehme in der Regel 1M.

Phijo hat geschrieben:
09.04.2019 02:08:46
Wenn ich mit cp eine einzige Partition in ein Image verwandel: wie bekomme ich die zurückgespiegelt? Einfach eine gleich formatierte Partition mindestens gleicher Größe erstellen und das als Ausgang für den Kopiervorgang aus der imagedatei verwenden?

Genauso wie bei dd: ›cp /pfad/zur/imagedatei /dev/zielpartition‹. Die Partition müss dazu mindestens mit der gleichen Größe des Images erstellt worden sein, das Dateisystem (Formatierung) ist unerheblich.

Verfasst: **09.04.2019 09:26:21**

wanne hat geschrieben:
08.04.2019 17:05:34
Nein. Ein Backup mit tar funktioniert nur mit kalten klassischen "dummen" Daten. Mit anderem Zeug kann man das auch machen. Ist dann halt scheiße. Gibt schon gründe, warum alle Professionellen Virtualisierungsumgebungen mit "Enterprise"-Featrues alla Snapshots haben wollen.

Einiges an deinen Erläuterungen ist mir nicht ganz klar, da ich per tar schon öfters mein System umgezogen habe. Allerdings handelt es sich dabei um einen Desktop-Rechner, also keinen Server im Produktiv-Einsatz.

Alle Hardlinks fehlen

Auf welche Hardlinks bezieht sich das?

Dein stage 1 (und 1.5) vom Bootloader weg ist

Versteh ich nicht. Falls es da Probleme gibt, macht man von der Live-CD aus per chroot ein update-grub

Die letzte paar Minuten aus jeder Datenbank fehlen, weil die gecached sind.

Gut. Allerdings dürfte das für ein normales Desktop-System egal sein.

Praktisch jedes IO-Intensive Programm nicht mehr hochkommt, weil deine Daten inkonsistent sind.

Ist das für einen normalen Desktop-rechner relevant, wenn man sich aus dem DE ausloggt und von der Konsole aus per tar das System sichert?

Alle ACLs fehlen. (OK, da wirst du keine haben)

Richtig. Desktop-System mit Einzel-Nutzer

SELinux contexte kaputt sind

Was passiert da genau?

extendet attributes fehlen

tar kann extended attributes, siehe https://www.gnu.org/software/tar/manual ... butes.html
Aber ist das Fehlen von extended attributes überhaupt relevant?

Capabillities fehlen

Was meinst du damit?

Verfasst: **09.04.2019 11:31:47**

debianoli hat geschrieben:
09.04.2019 09:26:21
Alle Hardlinks fehlen
Auf welche Hardlinks bezieht sich das?

Alle die du halt so hast. tar macht aus den Links dann 2 Dateien, was zu verwirrungen führen kann sobald man dann das nächste mal die erste ändert.

debianoli hat geschrieben:
09.04.2019 09:26:21
Dein stage 1 (und 1.5) vom Bootloader weg ist
Versteh ich nicht. Falls es da Probleme gibt, macht man von der Live-CD aus per chroot ein update-grub

Nein. Ein update-grub braucht es nicht. Das passende Kommando ist grub-install /dev/sdx. Ja. Das kann man machen ist aber eben Zustzaufwand beim wiederherstellen.

debianoli hat geschrieben:
09.04.2019 09:26:21
Praktisch jedes IO-Intensive Programm nicht mehr hochkommt, weil deine Daten inkonsistent sind.
Ist das für einen normalen Desktop-rechner relevant, wenn man sich aus dem DE ausloggt und von der Konsole aus per tar das System sichert?

Die Gefahr, dass während des rsyncs ein write auftritt ist natürlich immer da sobald irgend ein Dienst Läuft und das sind ne Menge. Die Gefahr ist an der stelle zugegebener maßen eher klein. Auf desktops ist es üblicherweise hauptsächlich der Browser den es relativ häufig killt. Firefox ist bei sowas zu ca. 5% kaputt. Aber da kann man dann das profil löschen und alles ist wieder gut.
Anderer Kanidat der das eher nicht so ab konnte ist kmail. (Mit akonadi und sqlite müsste das jetzt besser sein.) Einige spiele löschen die als Cheat-Protection die Spielstände. Aber es bleibt halt immer ein Glücksspiel. Sobald ein Programm mehr als eine Datei offen hat, kann es das zerschießen. (Und das sind ne Menge: guck dir einfach mal ls -d /proc/*/fd/[3-9]* an.) Die frage ist nur wie wahrscheinlich das ist.

debianoli hat geschrieben:
09.04.2019 09:26:21
SELinux contexte kaputt sind
Was passiert da genau?

Wenn du selinux nutzt tut gar nichts mehr. (Das grob gesagt ist ein feingranulareres Rechtemanagement als klassiche UNIX-Rechte. Exploits für solche Systeme sind deutlich schwerer zu schreiben.) Ist aber eher bei RedHat/Fedora verbreitet, wo es per default an ist. Obwohl Debian kompatibel sein will kenne ich keinen, der das da nutzt.

debianoli hat geschrieben:
09.04.2019 09:26:21
Capabillities fehlen
Was meinst du damit?

Z.B. ping als unser wird auf vielen Systemen nicht mehr funktionieren. Mal am Beispiel ping: Klassisch braucht man um Netzwerkzugriff zu bekommen root rechte. Da ping kein tcp und damit keinen port verwendet muss ping als root ausgeführt werden. Das kann man entweder mit suid-Bit lösen oder halt mit der capability, dass dieses eine Programm (ping) vollen Netzwerk-Zugriff hat aber sonst keine root-rechte. Ähnliches gilt für tshark. Abhören von Netzwerkverkehr darf eigentlich nur root. Mit der Netzwerkkapability darf das auch tshark. Der überprüft dann ob der Nutzer in der passenden Gruppe ist.

Und wie gesagt: Ich würde die ganze Platte in eine Datei kopieren. nicht die einzelnen Partitionen. Dann musst du dich beim wiederherstellen nicht um Bootloader, Partitionstabelle etc. Kümmern.

Verfasst: **09.04.2019 13:39:46**

@wanne
Thx für die Infos. Jetzt weiß ich, wo die Grenzen von einem Live-Backup mit tar sind.

Wobei tar einiges mehr kann. Die Punkte xattr, acls und selinux sind bei richtiger Anwendung von tar inzwischen auch kein Problem mehr, denn tar hat auch diese Optionen:

Code: Alles auswählen

Extended file attributes
       --acls Enable POSIX ACLs support.

       --no-acls
              Disable POSIX ACLs support.

       --selinux
              Enable SELinux context support.

       --no-selinux
              Disable SELinux context support.

       --xattrs
              Enable extended attributes support.

Verfasst: **09.04.2019 14:19:06**

Wobei tar einiges mehr kann. Die Punkte xattr, acls und selinux sind bei richtiger Anwendung von tar inzwischen auch kein Problem mehr, denn tar hat auch diese Optionen:

Es ist wohl etwas trickier als man denkt: Es gibt wohl ein paar ".tar" formate. GNU in drei Varianten, BSD... Man muss beim packen eines wählen, das alles unterstützt und vor allem beim Entpacken wieder ein passendes Format nehmen, dass das dann auch versteht. Ich meine da mal auf die Nase gefallen zu sein.

Verfasst: **18.04.2019 16:58:10**

wanne hat geschrieben:
08.04.2019 15:45:11
Wenn ich das richtig sehe ist dir Zeit und platz reichlich Wurst.
Mein dicke Empfehlung an dich:
Lass die Finger von irgend welchen intelligent-Lösungen alla gparted und ähnliches und kopiere einfach die Platte.
Boote einfach irgend eine LiveCD. (Du willst kein System kopieren während es läuft. Das macht nur Müll.) Da kannst du einfach die Datei /dev/sda bzw. /dev/sdb etc auf die externen Platten kopieren. (Ganz normal mit rechtsklick kopieren und dann halt in einen Ordner deiner Wahl einfügen.) Das kannst du dann auf jede genauso große (oder größere) Platte wieder einfügen. Und du hast eine 1:1 Kopie ohne irgend welche Veränderungen, die dir Bootfähigkeit o.ä. kaputt machen.
Selbstverständlich geht das auch auf der Kommandozeile mit cp:
Code: Alles auswählen
cp /dev/sda /media/exter1/platte1.img
und zum wiederherstellen auf die neue Platte:
Code: Alles auswählen
cp  /media/exter1/platte1.img /dev/sda
Wenn du das nochmal beschleunigen willst, kannst du mit tee auf beide externen gleichzeitig kopieren.
Annahme ist, dass backup Platten unter /media/exter1 und /media/extern2 liegen und die zu kopierende Platten sda und der USB-Stick sdd ist:
Code: Alles auswählen
cat /dev/sda | tee /media/exter1/platte1.img > /media/exter2/platte1.img
cat /dev/sdd | tee /media/exter1/stick.img > /media/exter2/stick.img

Hi zusammen, nach einiger Zeit, Urlaub und Testen möchte ich mich hier mal wieder melden.
Die Idee mit CP und der ERstellungs eines Images von der ganzen platte war richtig gut.
Ich hab das beim PC meiner Eltern (die haben jetzt auch Debian) mal ausprobiert und auch bei meinen beiden anderen PCs versucht (Debian 9 und ein "Bastelthinkpad" mit QubesOS).
Das funktioniert auf jeden Fall auch mit verschlüsselten Dateien und ich habe ein (sehr großes) Image, das ich beliebig hin und her schieben kann. Will ich nicht, aber das Handling funktioniert.

Mein Workflow fürs Backup also nun:
-live Backup von wichtigen Daten auf dem PC fürs Studium und Daten, die nicht privacy-relevant sind, auf eine Cloud mit deutschen Servern. Wenn ich Google-Drive oder so etwas hätte, wäre das verschlüsselt.
Das Cloud-Backup hat einerseits Sicherungszwecke, dient aber auch dazu, Daten über mehrere Geräte synchron zu halten.
Bei nem Keylogger wäre das schlecht, aber da ich jetzt mindestens 2-3 Kopie habe, die durch die Cloud synchronisiert werden, könnte ich selbst dann einfach eine Kopie offline sichern.

-Meine Externe ist mit Veracrypt verschlüsselt. Diese Daten landen auf einem gleich großen Veracrypt-Volume auf der 5TB-ExternenBackupplatte.
-Meine Festplatten im PC werde ich jetzt halbjährlich oder bei wichtigen Änderungen per cp in ein Image verwandeln, das landet dann auch auf der Externen. Da die Partitionen verschlüsselt sind, muss ich das Image nicht verschlüsseln.
-Wenn ich auf der 5TB-Externen etwas ändere spiegel ich diese per dd einfach komplett auf eine gleich große Platte. Die wird dann außer Haus gelagert.

Einzige verbleibende Frage: Wenn ich eine komplette Partition kopiere mit dd bzw. cp: Wo liegt da der Unterschied? Gibt es einen?
Also macht es für ne Spiegelung einen unterschied ob ich cp /dev/sdb /dev/sdc oder dd if=/dev/sdb of=/dev/sdc bs=1M nehme? Beide Platten sind gleich groß und ich will einfach eine Kopie, sodass ich zwei identische Platten habe und eine irgendwo lagern kann.

Nebenbei hatte ich das Problem, dass ich leider fürs Studium Windows brauche. Ich habe jetzt für mein "Bastelthinkpad" eine Lösung gefunden. Beim T430 kann man die Festplatte sehr einfach tauschen. Eine übrig gebliebene SSD wird jetzt dafür verwendet, Windows zu beherbergen, wenn ich das brauche (verschlüsselt mit Veracrypt). Das geht dann nur online, wenn ich das für nötig halte (T430 hat einen Hardwareschalter) und mein Hauptlaptop hat Debian.

Also danke nochmal für Eure Hilfe!
Grüße
Phijo

debianforum.de

LUKS-Partitionen komplett spiegeln/kopieren als Backup

LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup

Re: LUKS-Partitionen komplett spiegeln/kopieren als Backup