Sauvegarde et Restauration HDD > SSD --Mon plan?

Pause Café
#1

j’ai dans l’idee de transferer mon instalation linux de son disque dur actuel vers un disque SSD.
Je compte proceder de cette facon :

  1. reformater le disque SSD ;
  2. faire un “fresh install” ;
  3. restaurer.

Je compte utiliser la meme systeme de fichier sur le SSD que celui du HDD soit ext4.

Mais, je me demande si en fesant ca, la restauration va pas tout niquer la nouvelle installation?
Qu’est-ce qui va etre restaurer au juste, quel sera l’impact sur la nouvelle installation?
Est-ce que ca aura servit a quelque choses de faire un “fresh install” ?

#2

Hello

Qu’est-ce que tu entends par “restaurer” ?

#3

Restaurer a partir de l’image du systeme actuellement sur le HDD.

#4

Donc ton linux est installé sur ton HDD, et tu voudrais faire ensuite une copie bit-à-bit de ton HDD vers ton SSD ?
C’est ça que tu entends par “restaurer” ?

#5

Si c’est bien ça, oui la restauration va effacer ta fresh install.
Du coup tu peux directement faire étape 1, puis étape 3. Ça marchera pareil au bout du compte

Pour ce qui est de

Ça dépend de la méthode de restauration. Dans notre cas, le bit-à-bit, tout est restauré, système de fichiers ext4 présent sur HDD inclus.

#6

Merci, c’est ce que je pensais, mais j’etais pas sure.

Si j’utilise la commande dd pour cloner /dev/sda sur /dev/sdb mais qu’ensuite je les intervertie physiquement est-ce que /dev/sdb va devenir /dev/sda ? ou est-ce que je vais etre incapable de “booter”?
ou … je fais un image de l’installation sur le HDD en /dev/sda, et je change physiquement par la suite et installe l’image sur le SSD en /dev/sda?

[edit]
Finalement dd c’est pas trop une bonne idee, le fichier .img qui va en resulter sera trop gros, meme avec compression.

#7

Je croyais que tu voulais faire ton clone en mode off-line (live)
C’est la bonne manière ama.

Si tu intervertis physiquement les disques après le clonage, le clone /dev/sdb sera reconnu comme /dev/sda ; Si l’ordre d’amorçage des contrôleurs / des disques n’est pas changé.
Il n’y a pas de raison.

Et puis s’il s’agit d’informer le BIOS du nouveau disque d’amorçage, ce n’est pas grand chose.

Par contre, si le disque sda original (en sdb) est branché en même temps que son clone sdb (en sda), tu peux avoir des soucis avec les LABELs et UUIDs identiques de disques et de partitions.
Il faut probablement éviter. Je ne le ferais pas.

Je préfère m’en tenir là et que d’autres personnes te conseillent.

#8

Si je fais un clone je sais pas ce qui va arriver quand je vais vouloir changer les disques de position.
Une image ce serait plus simple, je fais l’image, je change les disques de place et je restaure.

#9

je suis pas si sur de ca. j’ai deja eu des probleme de boot en intervertissant des disque sans aller jouer dans le fastab ou quoi que ce soit d’autre.

#10

Bonjour theokaz

Afin d’avoir quelques informations concernant les caractéristiques de ces disques
et concernant le partitionnement du disque source,
il te faudrait nous transmettre le retour des lignes de commande suivantes,
(avec les deux disques connectés sur la machine)

udisksctl status
lsblk -o TYPE,SIZE,NAME,FSTYPE,MOUNTPOINT,LABEL,UUID
#11

Totalement d’accord.
-> On est d’accord, tu démarres bien sur clé USB et lances tes commandes dd depuis un linux temporaire (live-cd) ? Wikihow

Comme le dit @anon61356901, t’inquiète pas pour après le clonage dd, il y a juste à aller bidouiller un paramètre dans le BIOS au pire.

Après, est-ce que tu comptes formater le HDD une fois que tu seras sûr que ton linux a été transféré en SSD ?

Ça prend plus de temps, ça nécessite de la place pour stocker l’image, mais oui c’est valide. Le plus optimal reste de lancer dd directement du HDD vers SSD. T’auras exactement le même résultat en moins de temps

PS: Est-ce que Pause Café est l’endroit optimal pour ce sujet du coup ?
À l’origine c’est vrai que ça parlait d’un “plan”, mais là je le mettrais plus dans la section Support, ça peut être utile à d’autres. Qu’est-ce que vous en pensez ?

#12

La ligne est floue en ce moment entre le Support Debian et la Pause Café
Perso, je trouve ça bien :slight_smile:

Merci pour ton apport @TheJeje20

#13

C’est bien ca, c’est ce que je pensais. Il s’agit de deux disque dur interne connecter directement au motherboard. Ensuite oui, je fais tous depuis le live cd, bien sur. J’ai pas poster dans support pour la raison que je sais pas mal ou je vais, mais je desirais avoir l’opinion d’autres personne. j’ai opter pour l’image non seulement j’ai un back up, plus de jeux dans les manipulation et ca permet de faire la meme chose qu’un clone direct. Oui le HDD sera reformater apres. J’ai utiliser clonezila pour faire l’img. dd etant pas l’ideal pour ce genre de tache (sauvegarder 1tb) peut etre plus pour des petit stockage ou du bootable. Ou alors je sais pas utiliser dd correctement.

1 J'aime
#14

Je n’ai toujours pas le retour des lignes de commandes que j’avais proposé d’entrer
afin d’avoir quelques informations de base concernant les caractéristiques de ces disques et la façon dont ils sont partitionnés.
C’est assez frustrant, d’autant que si une copie par dd du disque HDD vers le disque SSD est faite, j’espère que ces deux disques ont exactement le même espace disque,
sinon, la copie risque d’être inutilisable étant donné que les informations du MBR copié ne correspondront pas aux caractéristiques du disque SSD.

#15

Oui les deux disque ont la meme espace, jetais au courrant de ces details a propos de l’espace. Ceci dit le transfere est fait. La restauration d’img. c’est bien derouler et l’OS est maintenant sur SDD. il me reste plus qu’a faire la meme choses avec Windows.

[Edit]

c’est fait j’avais deja sauver Windows en img.

j’dit ca pour les autres, mais en restaurant il faut pas que le disque sur le quel on veut restaure soit partitionne, il doit juste etre wiper et c’est tout.
Aussi le disque dur externe qui contient l’image de sauvegarde ne doit pas etre brancher lors du demarage de la clef de Windows recovery, seulement lorsque vous etes rendu a choisir l’image dans le menu restaurer a partir d’une image. Au prealable il faut verifier en Cmd avec Diskpart si le disque sur lequel on veut restaurer est le disque selectionne avec la commande select disk = system mais puisque vous avez enlever tout les disque avant, exepte la clef usb, ce devrait bien etres lui.
Aussi s’assurer que le disque est physiquement le disk 0 et le premier a booter dans le bios.

#16

Merci @TheJeje20 @anon61356901 et @MicP pour la contribution.

#17

De rien, ce fut un plaisir :wink:

Juste :

Du coup pas besoin de s’inquiéter du fait que les disques aient le même UUID. dd ne voit pas ce détail.
@anon61356901 disait ça par rapport à si tu essaies de démarrer ton linux

  • après que le transfert ait réussi
  • en ayant ton SSD et HDD branchés en même temps

-> Si les deux disques ont les mêmes identifiants dans leurs partitions, tu as de bonnes chances que Linux SSD monte à côté de sa partition principale la partition #2 de ton Linux HDD au lieu de la #2 du SSD quand t’essaies de boot sur Linux SSD.

Je pense que tu n’as pas assez de connaissance de la ligne de commande dd ^^.
Ça m’est arrivé comme toi de penser que dd était affreusement lent.
En fait, par défaut (c’est bête mais c’est comme ça…), dd copie 512 octets par 512 octets.
Il s’avère que les disques durs ont des regroupements d’octets appelés cylindres, et que copier 1 cylindre dans 1 cylindre est beauuucoup plus efficace.

C’est ce qui explique qu’on ajoute souvent l’argument -bs=4M (block size) pour speeder la copie. Le block size se calcule quand on dd sur HDD, et comme un cylindre ça ne correspond à rien de physique pour un SSD/clé USB/etc., on peut mettre une grande valeur au pif.

En faisant ça, ton dd est aussi rapide que ton Clonezilla :innocent:

dd - expliqué par debian-fr.xyz

#18

Pour la commande dd a moins d’avoir mieux que ca pour faire une image d’un disque de 930gb :

sudo dd if=/dev/sda conv=sync,noerror bs=64K | gzip -c  > /PATH/TO/DRIVE/backup_image.img.gz

C’est la commande que j’ai utilisé en premier car ne voulant pas me casser la tête avec un programme alors qu’une simple ligne dans la console aurait suffit mais trop beau pour être vrai, après une heure ou deux j’avais un fichier partielle de 15 gb déjà et quand j’ai fait la manip en console pour savoir le progrès ça aurait pris encore des jours et je me serais sûrment ramasser avec une image compressée de 500gb au mieux non au pire.
Clonezilla porte bien sont nom (l’exécution fut assez surprenante a un moment j’ai cru que ma machine allait s’envoler) il a fait le tout en moins de 15 minute et le fichier total fait plus ou moins 9gb.
D’ailleurs si dd cette relique était si approprié pourquoi les japonais aurait t’il eu besoin de créer clonezilla.

Donc ici dsl mais l’expérience semble contredire la théorie.

#19

Je vois sur leur site :

Clonezilla saves and restores only used blocks in the hard disk

Donc oui tu as raison, Clonezilla est plus intelligent (et plus rapide) que dd

#20

et en plus clonezilla est capable facilement de sauveagrder un disque ou certaines partitions, pour ensuite les restaurer sur des disques d’une taille différente (mais supérieur).
j’ai testé et ca marche très bien (avec un disque aillant deux systèmes, un windows 10 et une debian en dual boot, avec une sauvegarde / restauration disque entier).