ubuntuusers.de

Hallo zusammen,

im Anhang habe ich mal ein Abbild von gparted von meiner ersten SSD geposted. Es ist ein Dual-Boot-System von meinem LG "gram" Notebook, Baujahr 2021 der mit Windows pro ausgeliefert wurde. Ich habe seinerzeit dem armen Windows etwa die Hälfte des Platzes mit gparted weggenommen und in den freien Platz Ubuntu 22.04 installiert. Funktioniert seit Monaten problemlos. Nun war vor einigen Tagen der grub weg (die Gründe sollen hier mal nicht interessieren, ist halt passiert) und der Notebook hat sofort Windows gebootet. Uff, Schreck! Ich habe gelesen und gelesen was ich zur Rettung tun könnte, aber ich war mir nicht sicher wo überhaupt der grub liegt (auf *1p1 oder *1p5 im Anhang) ... ich habe beschlossen, Ubuntu einfach nochmal auf der Maschine zu installieren. Hat funktioniert, der grub ist wieder da und nur 4 Stunden 😀 😀 später hatte ich meine gewohnte Arbeitsumgebung in Ubuntu wieder eingerichtet.

Aber ich habe angefangen zu überlegen, wie ich meine SSD sichern sollte. Die Konstellation ist ja relativ komplex. Im Moment tendiere ich dazu, etwa 120,- Euro anzufassen und eine 2TB NVMe M.2 SSD zu kaufen, die auf einen USB-Träger zu stecken und an einen Slot an meinem USB-Hub zu stecken und einfach ein "dd if=*p1 of=ext.SSD" zu fahren (also die ganze Platte von vorne bis hinten) hin- und wieder zu sichern. Wenn das nächste Mal irgendwas passiert, kopiere ich das einfach zurück, ebenfalls mit dd.

Zum weiteren Verständnis: Meine "wirklichen" Daten (Texte, Tabellen, ...) sind alle auf der zweiten SSD in dem Notebook und alle diese Daten befinden sich in der Dropbox, die brauche ich nicht weiter sichern.

Die Datensicherung, die ich hier hier versucht habe zu beschreiben würde also nur dazu dienen, die Arbeitsfähigkeit der beiden Beriebssysteme samt der gewohnten, eingerichteten Umgebung zu sichern und im Bedarfsfall zurück zu kopieren. Diese Umgebungen ändere ich nicht jeden Tag, es würde m.E. reichen, dass vielleicht einmal im Monat zu sichern.

Was meint Ihr, wie würdet Ihr das in dieser Konstellation machen?

Danke, VG Rainer

blackbottom schrieb:

Im Moment tendiere ich dazu, etwa 120,- Euro anzufassen und eine 2TB NVMe M.2 SSD zu kaufen, die auf einen USB-Träger zu stecken und an einen Slot an meinem USB-Hub zu stecken

wenn du den USB-Träger schon hast, dann ist 120€ gerade so okay, wenn nicht, dann ist vllt eine externe in eine Gehäuse genauso teuer und deutsch unempfindlicher.

SAMSUNG Portable SSD T7 Festplatte, 2 TB SSD, extern, Titan grey 139,90€

Ich bin mir nicht sicher, ob ich hier Händler schreiben darf, aber du kann ja mal mit dem Zitat eine Suchmaschine benutzen 😇

blackbottom schrieb:

es würde m.E. reichen, dass vielleicht einmal im Monat zu sichern.

Dann könnte es auch eine einfache HDD tun.

Es ist schon mal gut, das Du die "wichtigen Daten" anders sicherst. ☺ Was aber ist bei Deiner Methode der Bedarfsfall? Wenn ich das richtig sehe wohl eine defekte SSD. Dann brauchst Du eine neue SSD mit anderer UUID. Wenn Du darauf Dein Backup aufspielst, wirst Du Dich wundern, das Dein Betriebssystem nicht bootet - wegen der unterschiedlichen UUID. Es gibt hier im Wiki einen Artikel "Ubuntu umziehen". Der könnte Dir in so einem Falle weiterhelfen. Aber das dauert dann. Nicht das es nicht geht, oder ich Dich davon abbringen will; nöh ich will nur darauf hinweisen, das es im Falle des Restore nicht ganz so einfach ist. Gruß Christian

homer65 schrieb:

Dann brauchst Du eine neue SSD mit anderer UUID.

Zumindest für Ubuntu sind die UUIDs der Partitionen relevant. Die kann man beim Klonieren der ganzen Platte "mitnehmen" oder beim Klonieren der Partitionen neu setzen.

An Euch erstmal vielen Dank.

Im Eingangspost habe ich einen Anhang erwähnt, der aber anscheinend nicht sichtbar ist (obwohl nur 75KB groß, hmm). Hier mal ein Auszug von fdisk -l der ersten Platte, um die es hier gehen soll:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

Festplatte /dev/nvme0n1: 953,87 GiB, 1024209543168 Bytes, 2000409264 Sektoren
Festplattenmodell: HFS001TD9TNG-L2A0A                      
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: 40CA6A80-635D-42AB-A964-AA7975758534

Gerät              Anfang       Ende   Sektoren  Größe Typ
/dev/nvme0n1p1       2048     534527     532480   260M EFI-System
/dev/nvme0n1p2     534528     567295      32768    16M Microsoft reserviert
/dev/nvme0n1p3     567296 1178367999 1177800704 561,6G Microsoft Basisdaten
/dev/nvme0n1p4 1178368000 1180882943    2514944   1,2G Windows-Wiederherstellung
/dev/nvme0n1p5 1180882944 1963325439  782442496 373,1G Linux-Dateisystem
/dev/nvme0n1p6 1963325440 1998974975   35649536    17G Windows-Wiederherstellung
/dev/nvme0n1p7 1998974976 2000408575    1433600   700M unbekannt

Der Bedarfsfall war dass ich den Ein-Ausschalter heftig betätigt hatte (Hintergrund: Monitorerkennung hat gesponnen an meiner Dockingstation). Was da auch immer passiert sein mag: Am Ende war der grub verschunden, genauer das Boot-Menü, stattdessen hat sofort Windwos einwandfrei gebootet. Also nicht nicht eine defekte SSD. Ich wusste nicht, wo der grub/das Bootmenü in so einem System eigentlich zu finden ist. Auch war ich mir unsicher, ob nicht eher die EFI-Partion *1p1 defekt war (sowas hat jedenfalls gparted angezeigt, was ich per USB-Stick gebootet hatte). Da dachte ich mir, ehe ich Stunden fummle und am Ende der Notebook noch mehr vermurkst ist versuche ich Ubuntu neu zu installieren. Das hat ja auch funktioniert, aber ich musste einige Stunden meine Arbeitsumgebung wieder herstellen. Und da fing ich an zu überlegen, ob man das nicht besser hinkriegt, in dem man ein Backup einspielt.

Aber in der angebenen Konfiguration: wie sollte ich vorgehen? Ich denke, wie im Startpost schon beschrieben würde das mit "dd" schon funktionieren, aber vielleicht schieße ich da mit Kanonen auf Spatzen. Vielleicht wisst Ihr elegantere Lösungen. Nochmal Merci.

Auszug von fdisk -l der ersten Platte

Der Bedarfsfall war dass ich den Ein-Ausschalter heftig betätigt hatte

Ah! Ich muss aus dienstlichen Gründen auch ein Windows auf dem Notebook und dem PC haben. Folge: Sowas hatte ich kürzlich auch. Da war es aber das „UEFI-BIOS“, welches „vergessen“ hatte, was es denn bitteschön booten soll, und einfach mal den Grub ignorierte. Nach kurzem Gefummel (man sollte endlich mal normen, welche Taste das Setup aufruft: <F1>, <F2>, ..., <F12>, <DEL> ist eine verdammt lange Liste) und dem manuellen Wiedereinstellen der der Boot-Reihenfolge ging es dann klaglos...

Hilfreich ist stets ein Blick in /etc/fstab:

Da steht dann natürlich bei Dir etwa wie „/ was on /dev/nvme0n1p2 during installation“ - ich habe das komplette System mit dd nicht nur auf eine weitaus größere nvme, sondern auch auf einen anderen Rechner umgezogen:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sdb2 during installation

# Root:
UUID=bce1df07-5b06-4297-ad1f-a68de484d364 /               ext4    errors=remount-ro 0       1

# /boot/efi was on /dev/sdb1 during installation
UUID=0BF3-7BD6  /boot/efi       vfat    umask=0077      0       1

blackbottom schrieb:

aber ich war mir nicht sicher wo überhaupt der grub liegt (auf *1p1 oder *1p5 im Anhang)

Naja. Da, wo Du den grub selbst installiert hast. (Beim Setup kommt da eine Auswahl.) Standardvorgehen ist dabei, den grub nicht in einer Partition sondern vor der Partitionstabelle in den Bootsektor zu schreiben. Also etwas wie /dev/nvme0n1:

Der Ein Teil liegt in der Boot-Partition.

Auch stets hilfreich(¹):

1
2

alias mlsblk='/usr/bin/lsblk -o NAME,SIZE,TYPE,UUID,LABEL,FSTYPE,MOUNTPOINTS'
mlsblk

zeigt etwas wie:

nvme0n1       1,8T disk                                                                            
├─nvme0n1p1   512M part  0BF3-7BD6                                               vfat              /boot/efi
├─nvme0n1p2 118,7G part  bce1df07-5b06-4297-ad1f-a68de484d364                    ext4              /
└─nvme0n1p3   1,7T part  978f5022-e644-41b3-9772-19b02dfe5f92                    ext4              /media/nvme0n1p3

Hier wäre der Installationsort beim Standardvorgehen (grub im Bootsektor) /dev/nvme0n1.

Manche wählen da aber - um z.B. das einstige Problem mit dem Windows7-Servicepack zu vermeiden(²), die Root-Partition des Linux. (Das wäre in meinem Beispiel /dev/nvme0n1p2)

¹) Tip: Den Alias in ~/.bashrc und /root/.bashrc eintragen...

²) Das damalige Windows-7-ServicePack hatte den Setup abgebrochen, wenn es den grub (oder anderes Zeug) statt 444 NUL-Bytes im MBR vorfand...

blackbottom schrieb:

Im Eingangspost habe ich einen Anhang erwähnt, der aber anscheinend nicht sichtbar ist (obwohl nur 75KB groß, hmm).

Das könnte daran liegen, dass du abschließend nicht auf "Anhang hochladen" geklickt hast. Nachdem man sein Verzeichnis durchsucht und den Anhang ausgewählt hat, sieht es ja so aus, als wäre er im Beitrag schon enthalten (rote Umrandung in meinem Anhang). Aber erst nach anschließendem Klick auf den erwähnten Button ist er wirklich hochgeladen.

Der Fehler ist mir anfangs auch des Öfteren unterlaufen. Aber wenn man es erst einmal weiß ...

etwa 120,- Euro anzufassen und eine 2TB NVMe M.2 SSD zu kaufen,

für ein Datengrab, wo nur ein SSD Image drauf gelagert werden soll ist das rausgeworfenes Geld. Eine fertige 2 TB HDD im Gehäuse ist billiger.

Vielleicht wisst Ihr elegantere Lösungen. Nochmal Merci.

Hallo blackbottom Ich verwende Clonezilla schon seit Jahren, siehs dir mal an

Gruss Tjure