Ubuntu systeem SSD klonen naar grotere SSD

[linuxlover]

De systeemdisk van mijn host is een samsung 860 pro 256 GB schijf met 2 partities voor “root” (100 GB) en voor “home” (150 GB).
De “home” partitie is bijna vol en daarom wil ik de huidige 256 GB ssd vervangen door een samsung pro 512 GB ssd. De “root” partitie (100GB) wil ik behouden en de “home” partitie wil ik vergroten t/m de gehele ssd.

Procedure alsvolgt:
    1. nieuwe ssd met usb – sata kabel aansluiten op usb port
    2. opstarten van externe usb stick met ubuntu 20.04 lts live systeem
    3. met “disk” menu de schijfnamen bepalen (/dev/sda, /dev/sdb, /dev/sdc)
    4. nieuwe ssd schijf partitioneren met sudo fdisk /dev/sdc, 1 partitie over de gehele schijf
    5. nieuwe partitie formatteren met sudo mkfs -t ext4 /dev/sdc1
    6. met dd if=/dev/sda of=/dev/sdc bs=64M conv=noerror,sync status=progress  huidige systeemschijf /dev/sda klonen naar /dev/sdc
    7. met “disk” menu de “home” partitie van de nieuwe ssd vergroten t/m de gehele disk
    8. ubuntu 20.04 lts live systeem afsluiten, nieuwe 512 GB ssd inbouwen en booten

Kan iemand mij adviseren of deze procedure correct is of dat het klonen en vergroten van de partitie op een andere betere manier moet worden gedaan ?
Bij voorbaat dank voor de hulp.

[peer]

stap 4 en 5 zijn niet nodig. Dat gebeurt automatisch met het dd-commando.
Nadien wel de partitie vergroten. Jij doet dit met disks. Heb ik geen ervaring mee. Daar gebruik ik altijd gparted voor.

[vanadium]

Mogelijk gaat dat wel goed, maar het zal volgens mij veiliger en sneller zijn om de nieuwe SSD te installeren, dan Ubuntu te installeren en je data, inclusief je configuratiebestanden, in je oude /home partitie terug te kopiëren. Mogelijk moet je dan enkel nog wat toepassingen erbij installeren, en je systeem zal aanvoelen als vanouds.

Tenzij je ook andere dingen doet in je / partitie zou ik die beperken tot 20, hoogstens 25 GB. Dat is meer dan genoeg voor de systeembestanden.

[DeBaas]

Mijn insteek:
1. nieuwe ssd met usb-sata kabel aansluiten op usb3.0 port
2. opstarten van externe usb stick met ubuntu 20.04 lts live systeem
3. met Terminal -- sudo fdisk -l --
 # de schijfnamen bepalen (/dev/sda, /dev/sdb, /dev/sdc)

6. met Terminal -- dd bs=4M if=/dev/sda of=/dev/sdc status=progress && sync --
 # huidige systeemschijf /dev/sda klonen naar /dev/sdc

7. met “gparted” de “home” partitie van de nieuwe ssd vergroten t/m de gehele disk
 # laat de hele ruimte min 1M aan het eind gebruiken om foutmeldingen te voorkomen

8. ubuntu 20.04 lts live systeem afsluiten, nieuwe 512 GB ssd inbouwen en booten

[linuxlover]

@peer : bedankt voor de tip en goed om te weten. gparted heb ik ook aan gedacht maar omdat ik dan toch ben ingelogd met het ubuntu live systeem en dan niet hoef om te schakelen naar gparted-live vandaar.

@vanadium : ook bedankt, dat is misschien inderdaad ook wel veiliger. Even bekijken wat ik in dat geval extra moet installeren. Goed om te weten dat / in ieder geval kleiner kan.

@DeBaas : bedankt voor deze optimalisatie ! Is de 4Mb. blocksize "veiliger" met dd ? De "vrije" 1Mb. aan het einde heb ik inderdaad al eens vaker gezien. Kunt u mij vertellen waarom dit het beste kan worden vrijgehouden ?

[DeBaas]

De blocksize word naar het geheugen geschreven, vandaaruit naar de disk.
Bij een USB2 heb je bij grote transporten al snel een paar minuten vertraging.
Met grotere blocksize kan dit oplopen tot tientallen minuten.
Aan het eind van de dd kopieslag lijkt het systeem te bevriezen maar staat het geheugen zich leeg te schrijven.
Dat hoeft geen probleem te zijn, maar tijdens het lange wachten mag je de USB niet lostrekken.
Als je een grote blocksize kiest maak je ook eerder fouten met bovenstaande.
De sync opdracht (&& sync) forceert het leegschrijven van de buffer, anders moet je nog langer wachten.
Met snelle USB3.0 en SSD is de wachttijd uiteraard een stuk korter.
 
De vrije 1M aan het einde: soms is de opslag niet exact een aantal MiB's groot maar is de laatste een fractie kleiner.
Als daarnaartoe geschreven wordt geeft dat een foutmelding en breekt het lopende proces af.
Resultaat opnieuw beginnen of mogelijk beschadigde disk inhoud.

[Paul Matthijsse]

Tenzij je ook andere dingen doet in je / partitie zou ik die beperken tot 20, hoogstens 25 MB. Dat is meer dan genoeg voor de systeembestanden.

U bedoelt vast GB.

[linuxlover]

@DeBaas
Zeer bedankt voor deze toelichting.
Het "bevriezen en lostrekken" is mij al een paar keer overkomen, evenals het "ontbreken van de vrije ruimte en de beschadigde disk".

Vanaf nu dus niet meer (hoop ik  ).

Weer veel geleerd vandaag, met dank !

[vanadium]

@Paul, zeker, ik heb dat rechtgezet.

@linuxlover, je kan die aanpak met dd zeker eens proberen. Interessant experiment. Mocht het mislukken, dan kan je nog altijd vers installeren. Ik verwacht echter dat die aanpak met dd niet alleen wat complexer is, maar ook beduidend langer zal duren dan formatteren en installeren.

[linuxlover]

@linuxlover, je kan die aanpak met dd zeker eens proberen. Interessant experiment. Mocht het mislukken, dan kan je nog altijd vers installeren. Ik verwacht echter dat die aanpak met dd niet alleen wat complexer is, maar ook beduidend langer zal duren dan formatteren en installeren.

@vanadium : inderdaad leek het mij ook een interessant experiment met dd (“disk destroyer”), dus heb ik hier vandaag de hele middag voor gereserveerd met als “fall-back” strategie de verse installatie.

Maar de hele dd actie is (mede dankzij de optimalisaties van DeBaas) uitstekend verlopen ; geen enkele foutmelding en meteen goed opgestart ! De gehele operatie heeft 43 min. geduurd dus ook dat viel erg mee  . En het voordeel is dat er verder niets meer hoeft te worden geïnstalleerd !

[aartje]

Naar mijn mening is "dd" niet echt een goed clone-commando. Je kan de grootte van de partitie
namelijk niet veranderen. De "nieuwe" partitie moet minstens net zo groot zijn als de oude en is
de nieuwe partitie groter gemaakt en doe je dan een dd vanaf een kleinere partitie, dan verlies
je gewoon  diskruimte.
Wat ik gebruik om te clonen zijn de commando's "dump" en "restore", daarmee kan je een root-partitie
clonen naar zowel een grotere als een kleinere (de data moet wel passen natuurlijk) partitie. Je moet
daarna natuurlijk wel je /etc/fstab aanpassen mbt tot de UUID van je nieuwe root-partitie.

[nahjo]

.

[aartje]

Met klonen wil je toch weer hetzelfde krijgen van wat je al hebt toch? 
Dan is dd zo gek nog niet.

Ja, dat is natuurlijk wel zo. Maar ik geef een methode aan waarbij je je root-partitie
eventueel zou kunnen veranderen van grootte. Bij "clonen" is de nieuwe partitie
byte-for-byte hetzelfde.

[vanadium]

@vanadium : inderdaad leek het mij ook een interessant experiment met dd (“disk destroyer”), dus heb ik hier vandaag de hele middag voor gereserveerd met als “fall-back” strategie de verse installatie.

Maar de hele dd actie is (mede dankzij de optimalisaties van DeBaas) uitstekend verlopen ; geen enkele foutmelding en meteen goed opgestart ! De gehele operatie heeft 43 min. geduurd dus ook dat viel erg mee  . En het voordeel is dat er verder niets meer hoeft te worden geïnstalleerd !

Bedankt voor deze terugkoppeling! Inderdaad, dit lijkt vlekkeloos te zijn verlopen, en valt ook qua tijd bijzonder goed mee! Een verse installatie waarbij je moet herconfigureren en data terugplaatsen zal al vlug langer duren, en zeker als je zeer veel data terug te plaatsen hebt.

[DeBaas]

Je zou met de installatieUSB eventueel via gparted de partities nog kunnen verkleinen, aansluitend verschuiven en vergroten.
Dat gaat (meestal) goed, als je maar niets doet met het begin van de / partitie, daar verwijst MBR grub naar.

[JorisC]

Ieder zijn manier . Ik kloon altijd een volledige schijf als de doelschijf groter is dan de bronschijf met Clonezilla .

[DeBaas]

Over de grootte van de / partitie, die hoeft inderdaad maar 20-25G groot te zijn,
MAAR als je vergeet overtollige kernels te verwijderen, of lange tijd niet hebt updated, kan het zomaar zijn dat je tijdens de update heel veel moet binnenhalen. Dan krijg je die inhoud 1x op schijf als binnengehaald, 1x op schijf als uitgepakt en 1x als geïnstalleerd. Daarna worden pas de oude versie ,  de binnengehaalde en uitgepakte bestanden verwijderd. Daarbij opgeteld de mogelijkheid van wat overtollige (te) grote log-files.
Zelf ga ik meestal voor een / van 30-40G maar dat is met kleine SSD niet aanbevelingswaardig.
Voor  kleine SSD's  (24-32G ) in sommige machines kies ik niet voor een aparte /home of swap omdat daar de ruimte niet voor aanwezig is.
Bovenstaande is niet waterdicht u/men zou een andere mening kunnen hebben 

@JorisC
Aangezien ik toch al Acronis True Image in bezit heb, misbruik ik deze ook wel eens voor een clone opdracht