Sebbene all'inizio la "sfida" proposta possa sembrare difficile, non fattibile o sembrare ingenua come alcuni hanno commentato, non lo è. L'idea principale alla base dell'utilizzo di dd per migrare da un disco più grande a uno più piccolo è perfettamente soddisfacente e offre vantaggi per la migrazione dei dati. Naturalmente, è necessario disporre di spazio libero sufficiente affinché i dati occupati si inseriscano nel disco di destinazione.
L'idea è quella di pensare nel trovare ogni partizione individualmente e non l'intero disco contemporaneamente come inizialmente proposto. È possibile ottenere ancora di più: le partizioni che verrebbero troncate possono anche essere migrate in sicurezza con un piccolo aiuto degli strumenti di ridimensionamento del filesystem. In effetti, questo tipo di migrazione è interessante per preservare i matadata del file system e gli attributi di file estesi che non possono essere facilmente copiati con strumenti come cp, rsync, pax, che operano nel livello del file system e non bloccano il livello del dispositivo. L'uso di dd elimina la necessità di reinstallare il sistema operativo o di dover rietichettare l'FS per evitare problemi con SELinux.
Di seguito è quello che faccio di solito per svolgere attività simili:
1) Innanzitutto è necessario ridurre i file system all'interno delle partizioni interessate che verrebbero troncate. Per questo, usa lo strumento resize2fs (supponendo che stiamo parlando di un ext2 / ext3 / ext4 fs - anche altri FS moderni hanno strumenti di ridimensionamento per lo stesso scopo). Nota che sebbene - per ovvi motivi - un filesystem non possa essere più grande della partizione in cui risiede, può tranquillamente essere più piccolo. Il trucco di sicurezza qui è quello di ridurre "più del necessario". Ad esempio: immagina di avere un filesystem da 1 TB che desideri migrare su un'unità da 500 Gig. In questo caso, suggerisco di ridurre la fs, diciamo, a 450 Gig (devi avere abbastanza spazio libero per questo, ovviamente, cioè lo spazio attualmente occupato in questo filesystem non può superare i 450 Gig). Lo spreco apparente di 50 Gig di spazio verrà corretto dopo la migrazione dei dati.
2) Partizionare il disco di destinazione con la geometria appropriata considerando i suoi vincoli di spazio;
3) dd i dati usando il / i dispositivo / i di partizione e non il dispositivo disco (ovvero, utilizzare dd if=/dev/sda# of=/dev/sdb#per ogni partizione anziché utilizzare if=/dev/sda of=/dev/sdb). NOTA: sda e sdb qui sono solo esempi; NOTA IMPORTANTE: quando si passa da un dispositivo di partizione più grande a uno più piccolo, dd si lamenterà del tentativo di scrivere post alla fine del dispositivo a blocchi, va bene poiché i dati del filesystem sarebbero stati copiati completamente prima di raggiungere quel punto. Per evitare tale messaggio di errore, è possibile specificare la dimensione della copia utilizzando bs=e i count=parametri in modo che corrispondano alla dimensione del filesystem ridotta, ma ciò richiederà alcuni (semplici) calcoli, ma se fatto in modo errato può rischiare i dati.
4) Dopo aver inserito i dati, ridimensionare nuovamente i rispettivi filesystem all'interno delle partizioni di destinazione usando resize2fs. Questa volta non specificare la nuova dimensione del filesystem. Se eseguito senza una specifica di dimensione, resize2fs espande il filesystem in modo che occupi la dimensione massima consentita, quindi, in questo caso, il filesystem da 450 Gig crescerà di nuovo per occupare l'intera partizione da 500 Gig e nessun byte verrà sprecato. (L'approccio "Riduci più del necessario" ti evita di specificare erroneamente dimensioni errate e di rischiare i tuoi dati. Nota che le unità GB vs GiB possono essere complicate).
Nota per operazioni più complesse: se si dispone di un boot manager che si intende copiare, il che è molto probabile che sia il caso, è possibile utilizzare i primi KB del disco utilizzando il dispositivo del disco anziché i dispositivi di partizione (come dd if=/dev/sda of=/dev/sdb bs=4096 count=5), quindi riconfigurare la geometria in / dev / sdb (che conterrà temporaneamente una geometria non valida per la nuova unità ma un gestore di avvio intatto e valido). Procedere infine utilizzando i dispositivi di partizione come descritto sopra per eseguire il dd di una partizione alla volta. Ho fatto operazioni come questa molte volte. Molto recentemente, ho eseguito con successo una migrazione complessa durante l'aggiornamento da un HDD contenente una combinazione di installazioni MacOSX e Linux a un SDD più piccolo nel mio MacMini6,2. In questo caso, ho dovuto avviare Linux da un disco esterno, ho creato il bootmanager, ho eseguito gdisk per riparare il GPT nel nuovo disco e infine ho scaricato ogni partizione contenente i filesystes appena ridotti. (Si noti che lo schema di partizione GPT mantiene due copie della tabella delle partizioni, una all'inizio e un'altra alla fine del disco. gdisk si lamenta molto perché non riesce a trovare la seconda copia del PT e perché le partizioni superano le dimensioni del disco, ma risolve correttamente il problema della copia del PT dopo aver ridefinito la geometria del disco). Questo è stato un caso molto più complesso, ma vale la pena menzionarlo perché illustra che questo tipo di operazione è anche perfettamente fattibile.
In bocca al lupo! ... e, soprattutto, ricordare di eseguire il backup di tutti i dati importanti prima di questo tipo di operazione. Un errore e puoi sicuramente danneggiare i tuoi dati in modo irrecuperabile.
E nel caso non avessi enfatizzato abbastanza: eseguire il backup dei dati prima della migrazione! :)
ddcalcolo della dimensione ottimale del blocco