Déplacement d'une installation Linux complète vers un autre lecteur


56

J'ai Ubuntu 14.04 avec beaucoup de paquets et de choses liées au travail dont je suis très content. Il est installé sur mon disque principal SSD qui est de 120 Go (j'avais choisi "/" quand j'ai installé Ubuntu, donc je crois que tout devrait être sur ce disque). Il apparaît comme / dev / sda

Maintenant, j'ai ajouté un autre SSD à mon ordinateur qui est un 240Gb. Je n'ai aucun autre support de stockage sous la main pour l'instant (par exemple, un disque dur externe).

Comme le nouveau disque de 240 Go a évidemment plus de capacité et est plus rapide (une génération plus récente que celle de 120 Go), je souhaite déplacer mon système Linux sur ce nouveau disque. Ce nouveau disque apparaît sous le nom / dev / sdb et, pour le moment, il n’est pas formaté ni quoi que ce soit (j’ai littéralement déballé et inséré dans mon PC: P)

Comment puis-je déplacer en toute sécurité mon installation Linux sur le nouveau disque?

Je peux changer le câble SATA pour que le nouveau lecteur affiche / dev / sda si nécessaire.

Voici le résultat de "fdisk -l" si cela aide:

Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00076d7a

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048   226064383   113031168   83  Linux
/dev/sda2       226066430   234440703     4187137    5  Extended
Partition 2 does not start on physical sector boundary.
/dev/sda5       226066432   234440703     4187136   82  Linux swap / Solaris

Disk /dev/sdb: 240.1 GB, 240057409536 bytes
255 heads, 63 sectors/track, 29185 cylinders, total 468862128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/sdb doesn't contain a valid partition table

4
On dirait que vous envisagez d'utiliser les deux maintenant. Si tel est le cas, vous devriez envisager d’utiliser simplement le plus récent, le plus grand, /homeplutôt que l’ensemble du système. Cela devrait être un changement plus facile (il suffit de tout déplacer et d’ajouter une seule ligne à / etcs / fstab), et la plupart des fichiers volumineux vont probablement aller dans votre répertoire personnel (et donc sur le disque plus grand).
Kevin

Réponses:


36

Vous pouvez utiliser CLONEZILLA à cette fin.

Clonezilla est un outil de partitionnement et de clonage de disque libre qui peut être utilisé pour sauvegarder toutes vos données (disques entiers ou partitions) de manière hautement compressée. Vous pourrez ensuite les cloner sur votre disque dur pour les mettre exactement dans les mêmes conditions. C'est plus rapide que d'installer le système d'exploitation la plupart du temps.

  • Télécharger Clonezilla stable ISO ou Télécharger directement clonezilla-live-2.4.6-25-amd64.iso

  • Créez une clé USB amorçable (Live) à l’aide de Tuxboot 7.0 .

  • Démarrez à partir du média Clonezilla créé.

  • Maintenant, vous avez beaucoup d'options:

    1. Créez une image composée uniquement de '/' (saveparts) et clonez-la sur n'importe quelle partition de votre autre SDD.
    2. Créez une image du disque complet (Savedisk) et clonez-la sur votre nouveau SSD.

entrez la description de l'image ici

Dans votre cas, vous pouvez également utiliser l'option "device-device", mais je ne la connais pas bien.

Vous pouvez trouver un guide détaillé sur Clonezilla ici: http://clonezilla.org


1
Je vous suggère de regarder ces deux vidéos avant: youtube.com/watch?v=41tTudaQb0I et youtube.com/watch?v=LS6VhLDw-io
Severus Tux

1
C'est aussi une bonne option. Mais je suis trop paresseux pour créer le bâton de clonezille ;-)
Pilot6 3/03/16

J'ai trouvé que clonezilla n'avait pas copié sur le membre, donc une image de disque entière et un peu de travail avec gparted devraient faire l'affaire
adampski

1
Hou la la! content de l'entendre ;-), l'heure de démarrage, c'est à cause des UUID modifiés, c'est-à-dire que les nouveaux UUID et les anciens de vos partitions importantes (home, Swap) ont été modifiés. Pour corriger cela, veuillez suivre les instructions données ici avec les modifications appropriées : askubuntu.com/a/737340/497359 Si vous rencontrez un problème, veuillez le commenter.
Severus Tux

1
@adampski: Cela semble être un bug dans Clonezilla 2.4.5. Pour résoudre ce problème, vous pouvez utiliser Clonezilla 2.4.2 ou Clonezilla 2.4.2 Server Edition (DRBL) jusqu'à ce que le problème soit résolu. :)
cl-netbox

42

Cela peut être fait de plusieurs manières. Mais le plus simple est de copier tous les fichiers de l’ancien disque vers le nouveau.

  1. Créez une partition ext4 et une partition de swap sur le nouveau lecteur.

  2. Démarrez à partir de LiveUSB.

  3. Montez l'ancienne partition Ubuntu sur un répertoire, montez la nouvelle sur un autre répertoire.

  4. Copiez tous les fichiers de l'ancien dans le nouveau à l'aide de la cp -acommande.

  5. Installez grub sur le nouveau lecteur .

  6. Mise /etc/fstabà jour avec les nouveaux UUID.

Si quelque chose n'est pas clair, je peux ajouter quelques explications.


1
+1 - Il est également possible d'éviter de démarrer à partir d'un LiveUSB et de tout faire pendant le démarrage à partir du lecteur d'origine, d'effectuer tous les changements, de redémarrer, voilà.
Sergey

1
@ Étienne: Ne copiez pas ces répertoires (également /dev), créez simplement des répertoires vides sur le lecteur de destination et définissez le même propriétaire / les mêmes autorisations que sur le lecteur source.
Sergey

10
J'ai fini par utiliser: sudo rsync -a / /mnt/linux/ --exclude sys --exclude proc --exclude dev --exclude tmp --exclude media --exclude mnt --exclude run then sudo mkdir sys proc dev tmp media mnt run
Étienne

1
@ Étienne pourriez-vous s'il vous plaît éditer votre --exclude-comment? Si vous le faites comme vous l'avez écrit, / var / tmp est également exclu (il me semble), après le clone, il est omis par systemd-resol.service, ce qui entraîne un problème de résolution de nom ... Je pense que cela devrait be --exclude / tmp --exclude / proc etc. Merci
swe

1
@swe je ne devrais pas maintenir un commentaire, proposez plutôt une modification de la réponse d'origine.
Étienne le

22

Si vous avez un peu de temps et que vous voulez aller en toute sécurité:

$ dd if=/dev/sda of=/dev/sdb bs=64K conv=noerror,sync

Explication de la commande:

  • ifest l'entrée, ofla destination
  • bsdéfinit la taille du bloc. C'est la taille des morceaux que dd lira et écrira. Des tailles plus élevées de morceaux signifient généralement de meilleures performances, mais également une plus grande corruption des données si le disque d'entrée comporte des erreurs, voir ici: archwiki on dd
  • noerror continue dans les erreurs r / w.
  • sync synchronise les décalages en cas d'erreur.

Cela va fondamentalement créer une image de votre disque sda ​​et l’écrire sur sdb (même disposition de partition, etc.) Bien sûr, cela écrira l’ensemble des 120 Go car il est indépendant du fichier. Donc très sûr, mais pas le plus rapide, si vous utilisez seulement de petites parties du disque. Cependant, si le disque d'entrée est plutôt plein, il est même possible qu'il soit plus rapide.

MAIS:

  • Après cela, vous voudrez probablement redimensionner les partitions, sinon vous ne pourrez pas tirer parti de l'espace supplémentaire.
  • Dans tous les cas, il peut être nécessaire d’éditer le fichier / etc / fstab.
    C'est le cas si les ID de matériel sont utilisés pour reconnaître les disques.

2
Votre ddcommande sera exécutée pour toujours. Pensez à ajouter bs=1Mà ce
Dmitry Grigoriev

Afaik blocksize n'a pas besoin d'être 1M sur les SSD mais je vais regarder ça et le mettre à jour
larkey

La limitation ne réside pas dans la technologie SSD, mais dans la bsvaleur par défaut qui est 512 octets.
Dmitry Grigoryev

1
réponse étendue avec bs, merci pour le heads-up
larkey

1
Merci pour la réponse détaillée ... J'ai appris des trucs! mais j'ai décidé d'aller avec clonezilla et de redimensionner les partitions après.
Saeid87

6

Contrairement aux autres réponses, cela vous permet de cloner l’installation Linux et de l’ajouter au menu Grub avec vos installations actuelles intactes. En outre, il modifie automatiquement /etc/fstabpour vous et met à jour gruble menu de démarrage.

Un menu est fourni pour vous aider à sélectionner la partition à copier. Le clone de partition est votre partition actuellement démarrée.

rsyncest utilisé pour une vitesse optimale si vous choisissez de recloner la partition. Cela est utile si la mise à niveau échoue, vous attendez la correction du bogue et souhaitez exécuter la mise à niveau à nouveau. De même, vous avez peut-être choisi de mauvaises options lors de la mise à niveau et vous souhaitez le refaire.

Le script complet peut être trouvé ici: Script Bash pour cloner Ubuntu sur une nouvelle partition pour tester la mise à niveau de 18.04 LTS et voici à quoi l'écran ressemble:

clone-ubuntu.png


6

Voici comment je le fais lorsque je commute sur un nouveau disque dur:

  • créer la disposition de partition que je veux sur le nouveau lecteur
  • démarrer à partir de Live CD / USB ou installer, récupérer, etc.
  • montez les anciennes partitions du disque dur à copier, par exemple, /mnt/a
  • montez la ou les nouvelles partitions du disque dur pour recevoir les fichiers, par exemple /mnt/b
  • cp -aou utiliser tar pour copier les fichiers à partir /mnt/ade/mnt/b
  • installez le chargeur de démarrage (lilo ou grub) sur un nouveau disque ¹
  • mettre à jour le /etc/fstab(vous pouvez utiliser blkidpour identifier les nouveaux UUID)
  • redémarrez et testez si tout va bien

Note¹:

Vérifiez tous les disques durs et partitions à l'aide de la commande suivante:

sudo fdisk -l 

Prenez maintenant une note de la partition sur laquelle Ubuntu est installé et qui ressemblera à ceci: /dev/sda1

Montez la partition sur laquelle vous devez installer GRUB 2 (partition de disque dur) et le système de fichiers apparaît dans Nautilus. Nous devons maintenant monter la partition de disque dur appropriée pour apporter des modifications au MBR de disque dur actuel. Pour cela, nous devons:

sudo mount /dev/sda1 /mnt
mount

Maintenant montez la partition sur un autre emplacement

sudo mount /dev/sda1 /mnt/boot

Créez un lien incassable à partir du /devdossier de l'image en direct que vous avez démarrée vers le /devdossier de la partition sur laquelle vous êtes monté/mnt

sudo mount --bind /dev /mnt/dev/

Maintenant, nous devons changer la racine de Live CD root (/) en racine de la partition montée.

sudo chroot /mnt

Vous vous trouvez maintenant dans un nouveau shell racine, dans lequel la partition montée est la nouvelle racine. Vous pouvez vérifier cette saisie ls. Puisque nous sommes dans la partition montée, nous pouvons aller de l'avant et installer GRUB 2:

sudo grub-install /dev/sda 

Les installations devraient se terminer maintenant, sans erreurs

Quittez votre shell CHROOT en tapant exitou en appuyant sur Ctrl+, D ce qui vous ramène au Live CD / USB Shell.

Démontez les partitions que nous avons montées auparavant pour un redémarrage propre:

sudo umount /mnt/dev
sudo umount /mnt/boot
sudo umount /mnt

et redémarrez après avoir retiré le Live CD ou la clé USB pour démarrer à partir du disque dur:

sudo reboot

La source


@ baobab33: Vous êtes autorisé à copier-coller des instructions ici sur ce site, puis à les attribuer. Vous n'êtes pas autorisé à simplement vous connecter à la source externe. Veuillez également mettre à jour la source avec les corrections ci-dessus.
Fabby

0

J'ai décidé de faire une expérience liée à ce post.

J'ai acquis un Lenovo ThinkCentre. Il possédait un disque SSD de 256 Go et un disque dur de 1 To (type spinner - rapide, mais pas aussi rapide qu'un SSD).

Lorsque j'ai installé Linux Mint 19.2 (LM19.2), il l’a installé sur le lecteur 1 To. Le SSD était irrécupérable et j'ai acheté un nouveau SSD Kingston de 240 Go.

J'étais sur le point d'installer le LM19.2 sur le nouveau SSD, mais il me semblait qu'il devait y avoir un moyen de transférer mon image LM19.2 bien développée du disque 1 To sur le nouveau SSD.

J'ai trouvé ce post, et bien qu'il y ait quelques conseils solides ci-dessus, j'étais dans un mode d'expérimentation. Vous trouverez ci-dessous un compte rendu de ce que j'ai fait et cela a TRÈS bien fonctionné.

  1. J'ai utilisé GParted pour créer une table de partition et une partition sur le SSD du même type que celles du disque dur de 1 To.
  2. J'ai effectué un instantané TimeShift (nouvel outil dans Ubuntu / Linux Mint) de TOUT sur le disque dur LM19.2 1 To.
  3. J'ai restauré cet instantané sur le SSD.
  4. Une fois les étapes ci-dessus terminées (vous pouvez même faire 1 en parallèle avec 2 et 3), j'ai redémarré, en m'assurant qu'il choisirait le SSD.
  5. La seule chose qui était étrange lors du redémarrage était que l'écran INITIAL grub me demandait si je voulais démarrer sur Ubuntu. J'ai supposé que cela était propre à la restauration TimeShift, et c'était le cas.
  6. Les démarrages suivants démarrés comme LM19.2 le font normalement.
  7. J'éditerai cette réponse une fois que j'aurai vérifié que je peux le faire avec un nouveau lecteur suspendu à l'extérieur du PC (et il semble évident que cela fonctionnera), car cela signifierait que je pourrais rapidement reproduire n'importe laquelle de mes machines LM. au nouveau matériel.

La vitesse de démarrage à elle seule a rendu ces étapes simples qui en valent la peine. Même Dropbox a bien été transféré - il voulait juste que je me reconnecte, et il a fallu tout le temps nécessaire pour indexer les fichiers, mais cela a très bien fonctionné.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.