Grüße an die Runde,
ich wollte eine verwindowste Festplatte mittels Live-System ganz auf eine externe Festplatte (forro) kopieren.
dabei entstand folgender Terminaldialog:
mint@mint:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 1.7G 1 loop /rofs sda 8:0 0 298.1G 0 disk ├─sda1 8:1 0 750M 0 part └─sda2 8:2 0 297.4G 0 part sdb 8:16 1 114.6G 0 disk ├─sdb1 8:17 1 1.8G 0 part /cdrom ├─sdb2 8:18 1 3.9M 0 part └─sdb3 8:19 1 112.8G 0 part /var/log sdc 8:32 0 931.5G 0 disk └─sdc1 8:33 0 931.5G 0 part /media/mint/forro-20-12 mint@mint:~$ dd/if=dev/sda1 bs =1M | gzip > /media/mint/forro-20-12/imange-RechnerA-sda1.gz bash: dd/if=dev/sda1: No such file or directory
Wie kann ich den if adressieren, dass mein Vorhaben gelingt?
bash: dd/if=dev/sda1: No such file or directory
Wie kann ich den if adressieren, dass mein Vorhaben gelingt?
Leerzeichen statt "/" hinter dd und den "/2 dafür an die richtige Stelle.
mint@mint:~$ dd if=/dev/sda1 bs =1M | gzip >/media/mint/forro-20-12/imange-RechnerA-sda1.gz
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Moin, ich auch noch mal, die alle vorgeschlagenen Lösungen den einen oder anderen Fipptehler enthielten:
bp bfi.philipp@web.de (Mo 14 Dez 2020 10:21:34 CET):
…
…
sdc 8:32 0 931.5G 0 disk └─sdc1 8:33 0 931.5G 0 part /media/mint/forro-20-12
dd if=/dev/sda1 bs=1M | gzip > /media/mint/forro-20-12/image-RechnerA-sda1.gz
alternativ würde ich:
gzip -v </dev/sda1 >/media/mint/forro-20-12/image-RechnerA-sda1.gz
verwenden. Warum man dort immer DD verwenden möchte, erschließt sich mir nicht.
Hallo Philipp,
ich sehe da auf die schnelle zwei Moeglichkeiten:
a) eine andere Festplatte mit einem Dateisystem, das groessre Dateien akzeptiert oder
b) split , damit kannst du angeben, dass die Datei in Stuecken der groesse x aufgespalten werden soll. (split -b 1G foo.gzip "foo.gzip.part")
viel Erfolg Robert
Am 14.12.20 um 11:49 schrieb bp:
Robert Drechsel djrf@gmx.de (Mo 14 Dez 2020 11:58:53 CET):
Dafür muss er aber erstmal die Datei irgendwo hingelegt haben. Alternativ:
cd /mnt/… </dev/sda2 gzip | split --size 1G - image.gz.
Hallo,
On Mon, Dec 14, 2020 at 10:33:18PM +0100, Bernd Müller wrote:
Na ja, das lässt sich schon recht einfach mit -oloop mounten. Ist quick and dirty aber ich mach das auch hin und wieder wenn Bandbreite zum und Storage auf dem "Backup Medium" kein Problem ist. Ich hab allerdings auch keine FAT Medien für sowas ;-)
Wobei ich hinzufügen muss, ich mach das dann auf dem gleichen (aka block) Interface aber nicht auf Partitionen, denn da liegt bei mir dann noch lvm, crypt und raid (in der Reihenfolge) dazwischen.
Ich muss allerdings zugeben, ich habe das noch nie ausgemessen, ob der Overhead der durch den "Walk" auf dem Filesystem grösser ist als der, der durch Übertragen und ggf. Komprimieren von "leerem Plattenplatz" entsteht. Das war immer mehr son auf nen groben Klotz gehört ein grober Keil Ansatz unter der Annahme, dass Gigabit Ethernet und schnelle Platten ökonomischer sind als dort all die Layer bis zum Filesystem durch die CPU zu jagen.
Grüsse Andreas
Hallo,
On Mon, Dec 14, 2020 at 11:06:18PM +0100, Andreas Fett wrote:
Ich möchte natürlich noch drauf hinweisen, dass das im Sinne eines "konsistenten" Backups nur mit Readonly oder noch besser garnicht gemounteten Blockdevices erfolgen sollte... Aber ich sagte ja schon, das ist quick & dirty.
Das auf nem RW Filesystem unter voller Last mit LVM, RAID und Crypt auf Partitionsebene zu machen geht mit an Sicherheit grenzender Warscheinlichkeit (beim Restore) in die Hose.
Grüsse Andreas
Andreas Fett a.fett@gmx.de (Mo 14 Dez 2020 23:23:04 CET):
+1
Wir machen da gerne (auch unter voller Last) einen LVM Snapshot, und sichern den dann. Das ist wenigstens konsistent im Sinne der Zeit, beim Restore dann, als hätte man ein Filesystem nach dem Stromausfall, was alle modernen Filesysteme überleben sollten.
Hallo,
On Mon, Dec 14, 2020 at 11:28:26PM +0100, Heiko Schlittermann wrote:
mein Hinweis war mehr so gemeint, man soll sich drüber Gedanken machen welche Garantien auf Vollständigkeit der Layer gibt auf dem man das Backup macht - das Beispiel war vll. schlecht.
Anders formuliert, wenn man mim dd hantiert und dabei seinen Thunderbird mit POP3 laufen hat, dann kann ne Mail auch verloren gehen von der man dachte sie sei im Backup. Die daraus folgenden Konsequenzen für kompliziertere Installationen möge sich jeder selbst ableiten :-)
Grüsse Andreas
Andreas Fett a.fett@gmx.de (Di 15 Dez 2020 00:19:34 CET):
Nicht nur das, so lange man ein lebendes Filesystem sichert, während es lebt, das sich also zwischen dem Beginn der Sicherung und dem Ende der Sicherung noch ändert, wird die Sicherung *nie* einem beliebigen Zustand des Filesystems entsprechen, sondern die ersten gesicherten Blöcke dem Zustand zu Beginn, während die letzten gesicherten Blöcke dem Zustand zum Ende der Sicherung entsprechen. Und diese werden nie zusammenpassen.
Meine Versuche, *lebende* Filesysteme zu sichern endeten mit überwältigender Mehrheit bei einem anschließenden fsck in der Zerstörung des Filesystems. (Ich meine jetzt nicht „dump“ oder „tar“. Wie „dump“ damit umgeht, weiss ich nicht, bei „tar“ trifft das beschriebene natürlich auf Files zu, die sich während der Sicherung ändern, bzw. auch auf Fälle, mehr als ein File zusammengehören.)
Komplett anders sieht es aus, wenn das Filesystem während der Sicherung „stillhält“, also z.B. der Snapshot eines lebenden Filesystems ist.
Auch dieser Snapshot hat dann das „unclean“ Flag (oder nicht das „clean“ Flag, weiss jetzt nicht, ob welches Flag das ist), und muss ggf. mit fsck behandelt werden. Aber es vom ersten bis zum letzten Block zusammengehörig.
Best regards from Dresden/Germany Viele Grüße aus Dresden Heiko Schlittermann -- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE -
Bernd Müller be-mueller@gmx.de (Mo 14 Dez 2020 22:33:18 CET):
Um das Image zu mounten, braucht es keine Partitionstabelle. Und die Info zum Filesystem steht ausschließlich im Image. Das, was die Partitionstabelle vielleicht auch noch als FS Typ drin hat, ist Schall und Rauch.
Ich würde einfach CloneZilla nehmen. Damit kann man alles "menü"-geführt auswählen.
Ich habe angeborenes Misstrauen in Menüführungen.
Das war ja vom OP offenbar so gewollt. Und im ersten Ansatz hat er sogar verucht, es zu komprimieren. (Das komprimierte Image kann er dann allerdings nicht mounten, das muss erst wieder irgendwo hingelegt werden, das unkomprimierte kann er sogar per Loop-Mount direkt mounten.)
Wenn er *vor* dem Koperen Zwischenräume noch mit Nullen füllt, kann er *beim* Kopieren sogar ohne Kompression eine Menge sparen, wenn er es als Sparse-File kopiert (cp --sparse=always, und ich denke, auch DD hat da eine Option).
Als Zielplatte FAT32 ist keine gute Idee, die maximale Dateigröße ist 4 GB.
Da hast du Recht, das hat er wohl schon gemerkt.
Wenn, dann würde ich immer das ganze Device, also /dev/sda clonen.
Warum?
Aber auch da würde ich anders vorgehen und ein komprimiertes forensisches Image (e01) erzeugen. Die Werkzeuge sind alle frei verfügbar. Mounten kann man das
EWF meinst Du. e01, e02, … sind wohl nur die Dateieindungen. Wenn ich den Artikel dazu richtig verstanden haben. Beim Überfliegen des Artikels beschlich mich der Verdacht, dass hier auch nur Grundwissen zusammengefasst wird, angereichert um einige interessante Werkzeuge, die aber auch nur Grundwissen anwenden. Aber dieser Eindruck mag verfliegen, wenn man das genauer liest.
Einen Filesystem-Dump in kleine Files zu schreiben, und dies dann zu r/w zu mounten (wobei die Änderungen getrennt vom Original gespeichert werden), das ist zwar keine Fingerübung für einen Nachmittag, aber geht in einem 2…4 wöcheigen Projekt auch mit Fuse und Perl zu bewerkstelligen (https://git.schlittermann.de/imager/) (hier incl. Deduplikation, die sicher besser gemacht werden könnte)
Hört sich spannend an. Ob die von mir o.g. Lösung im Produktivbetrieb mit FF, Adobe usw. performant genug wäre, weiss ich nicht. Ich nutze es für endlose Backups und gelegentliche Restores.
lug-dd@mailman.schlittermann.de