Montera SSD på /home

Kan du inte bara montera din nya ssd som /hometmp och sen kopiera din nuvarande /home dit? Sen avmontera /home och montera /hometmp som /home?

Innan ni sätter igång och kopierar allt och inget. Se till att destinationen har ett propert filsystem först.
Filsystemet ext4 är "de facto standard" i de flesta distributioner, så jag rekommenderar det.

Steg för steg:

1. Partitionera och formatera den nya disken. Se till att partitionstypen är av typen 0x83. Formatera med filsystemet ext4.

2. Montera den nya disken på en temporär monteringspunkt.

3. Synka din nuvarande /home till den nya disken. rsync är ett utmärkt verktyg för detta, då den klarar att synka filsystem "live". Glöm inte att exkludera icke kopieringsbara mappar och filer, om sådana existerar.
   Exempel: rsync -aAXv /home/* /path/to/new/disk --exclude={/home/lost+found}
   (Ersätt "path/to/new/disk" med den aktuella sökvägen till er nya disks monteringspunkt)
   (Försök att hålla så få program som möjligt öppna. Annars kan rsync missa vissa ändringar)

4. Undvik att använda datorn alltför mycket under tiden som rsync arbetar, eftersom man kopierar ett monterat filsystem under användning här.

5. Ta en fika.

6. Inte klart?... ta en fika till.

7. Klart? Bra!. Avmontera den nya disken, och uppdatera /etc/fstab om så behövs. Speciellt om /home monteras med hjälp av UUID. Kommentera ut den gamla /home raden, kopeira den och byt ut UUID-strängen mot den nya diskens UUID-sträng.
   Starta om datorn. Eller logga ut, avmontera /home, och montera den igen. Logga in igen.

Det är där rsync kommer in i bilden. Den synkroniserar allt innehåll mellan två sökvägar, vare sig det är separata filsystem, eller inom samma filsystem.
Enligt traditioner hade man kunna klona partitionen rakt av med diskkloningsverktyg, såsom dd och liknande, men det hade krävt att allt det sker utan att användaren är påloggad, och helst utanför X-miljön.
rsync är mycket enklare till just den här typen av uppgifter.

Du kommer få ett visst bekymmer i att du behöver ha en tom `/home`-katalog för att kunna montera en annan disk där. Det löses i teorin genom att exempelvis döpa om den gamla: `sudo mv /home /home-backup`, skapa en ny katalog: `sudo mkdir /home`, fylla i `/etc/fstab` för att framöver montera din nya SSD på `/home`, och testa med `sudo mount /home`.

Så länge dina "vanliga" användare är utloggade och du inte kör några bakgrundstjänster som någon av dessa användare (detta ska egentligen bara kunna hända om du medvetet konfigurerat en sådan tjänst) så ska det vara riskfritt att logga ut och lösa det i exempelvis en virtuell terminal: logga ut till inloggningshanteraren, Ctrl+Alt+F1, logga in som `root`, genomför ändringen, logga ut `root`, Ctrl+Alt+F7 för att komma tillbaka till inloggningshanteraren och logga in som vanlig användare igen.

Om du tycker det är olustigt att göra "live" så skulle du exempelvis kunna boota med en livedistribution på ett USB-minne och göra ändringen genom den. Jag vet inte om den automatiskt monterar dina "vanliga" partitioner som upptäcks eller om du får hitta dem själv, dock; det kan bero på distribution. Troligen så kan du bara "klicka" på partitionerna i en grafisk filhanterare för att montera dem, och du lär känna igen vilken som är vilken. Ett alternativ är att starta systemet i räddningsläge, varpå du får ett minimalt `root`-skal, men en livedistribution är nog enklare att hantera om du inte känner dig helt säker vid terminalen.

Vill du återställa migrationen så tar du bort raden i `/etc/fstab`, avmonterar: `sudo umount /home` och flyttar tillbaka den gamla hemkatalogen: `sudo rmdir /home && mv /home-backup /home`.

Notera också att du troligen vill kopiera över din hemkatalog som `sudo` för att behålla ägare och grupper. Om du kopierar som din "vanliga" användare så kommer du inte kunna skapa filer som ägs av någon annan, och du skulle till och med kunna missa filer som du inte har läsrättigheter till. Om ditt system bara har en enstaka användare är det troligen inga egentliga problem, men om du har mer än en användare så är det ett krav för att det ska bli bra.

Som sista notis kan det nämnas att om du ändå tänker använda en livedist så skulle du kunna göra hela processen där. Om du inte tvunget vill testa en livemigration så behöver du inte.

Valmöjligheter överallt!

Hela grejen med växlarna till rsync, i det här fallet "-aAXv", är att alla rättigheter och ägare bibehålls. Samtidigt som rsync utan problem kan arbeta på ett monterat filsystem. Det värsta som kan hända är att vissa av de allra senaste ändringar för de användare som är påloggade för tillfället inte följer med. Men så länge man inte utför något kritiskt (såsom att hålla viktiga dokument öppna och osparade) är det ingen fara.

Tänk också på att exekvera rsync-kommandot som root (t.ex med sudo), så att allt följer med. Även sådant som den aktuella användaren inte har rättigheter att läsa/kopiera.

Kanske också vore bra att tillägga att det enda du behöver göra efter synkning med rsync, är att lägga till en ny rad i fstab.
Här är ett exempel att använda er av. Ändra bara ett par värden enligt ert system, och anpassad för just SSD.

UUID=uuid_sträng_här  /home  ext4  noatime,discard  0  1

Ersätt "uuid_sträng_här" med den aktuella UUID-strängen. För att ta reda på vilken UUID den aktuella partitionen har:

ls -l /dev/disk/by-uuid

I mitt fall är det /dev/sdb1 som är min /home partition, och kommandot ovan ger mig då följande svar:

lrwxrwxrwx 1 root root 10 Jul 31 14:26 44de6c05-87c1-4c2f-9de5-eb4b0e9604c0 -> ../../sdb1

...vilket betyder att "44de6c05-87c1-4c2f-9de5-eb4b0e9604c0" är min UUID-sträng, vilket resulterar i att raden för /hom i min fstab ser ut enligt följande:

UUID=44de6c05-87c1-4c2f-9de5-eb4b0e9604c0  /home  ext4  noatime,discard  0  1

Tillägg:
tillvalen "noatime" och "discard" är lämpliga att använda för just en SSD. Speciellt "discard", som då aktiverar TRIM-funktionen. noatime, är en förkorting av "No Access Time", vilket betyder att filsystemets filtabell inte uppdateras varje gång en fil läses. Detta sparar en hel del på SSD-enhetens livslängd då många skrivcykler undviks. Och i de flesta vardagliga fallen behövs inte access-tiderna i alla fall.

dewpo skriver att hans nuvarande `/home` inte är en separat partition utan bara en katalog i monteringspunkten `/` som innehåller användarkatalogerna i sig, så det kommer inte gå att montera en ny partition på `/home` utan att flytta undan den gamla (eller tja, det går vad jag vet, men det skuggar ju informationen som redan ligger där, vilket är lite märkligt och troligen inte önskat).

Då tillkommer problemet med att vara inloggad samtidigt som man temporärt flyttar `/home` innan den ersätts med den nya monteringspunkten: i praktiken bör det åtminstone inte kollapsa då öppna filer kommer fortsätta peka på den "gamla" katalogens inodes och nya kommer använda den nya monteringspunkten, men för att "rensa" gamla file descriptors är det nog bäst att åtminstone starta om. För att helt undvika den märkliga situationen kan man som sagt sköta det på alternativa sätt.