Forum Linux.général DD à chaud?

Posté par  . Licence CC By‑SA.
Étiquettes :
0
5
fév.
2019

Bonjour à tous.

Est il possible de faire un dd à chaud?

Je vous explique sinon ma question peut être obscure.

J'ai un Laptop avec un SSD qui tourne sous ubuntu 14.

Je souhaiterais le passer en ubuntu18 cependant je pense partir sur une installation vierge.
Mais à fin de ne rien perdre, de garder un poste fonctionnel, et surtout garder le système en ssd. Je ferais comme d'hab.

1- Démarrage en live
2- clonage via dd du ssd --> dd
3- remplacement des disque
4- installation de la nouvelle distrib
5- en cas de besoin nouvelle inversion de disque

Le soucis c'est qu'un “dd” de 500Go ca prend beaucoup de temps.
Donc la nuit obligatoirement, et encore de souvenir ca passe pas en une nuit.
Et le soir, j'ai souvent pas le courage de me lancer dans l'opération.
Du coup, est il possible de faire un “dd” à chaud?

  • # Je ne comprends pas trop la manip

    Posté par  (Mastodon) . Évalué à 3.

    Tu parles de "remplacement des disques" et "inversion des disques", donc tu as un nouveau SSD ? Du coup pourquoi veux-tu faire un backup de l'ancien, puisque tu l'enlèves ?

    Pourquoi ne peux-tu pas faire :
    1- remplacement des disque
    2- Démarrage en live
    3- installation de la nouvelle distrib
    4- en cas de besoin nouvelle inversion de disque

    Sinon pour te répondre directement, je ferais un "mount -o remount,ro" sur toutes les partitions pour avoir un système en "read only", et ensuite oui tu peux dd sans soucis (attention : je ne l'ai jamais fait, je ne sais pas si ça marche, c'est juste que je tenterais ça). L'idée c'est déviter que ton disque bouge pendant le temps du dump (tu parles d'une nuit, t'auras au moins des logs qui vont changer) et du coup ton image sera incohérente au final.

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Je ne comprends pas trop la manip

      Posté par  . Évalué à 0.

      Non justement, j'ai un ssd et un hdd, c'est pour ca que je passe par un clonage.

      Et si je passe par avoir un read-only, autant le faire la nuit, en passant par un live-usb.

      • [^] # Re: Je ne comprends pas trop la manip

        Posté par  . Évalué à 3.

        Un dd sur un système online, j'oserai jamais perso. Je sais que le résultat sera foireux… D'ailleurs, techniquement, ça ne sera même pas un vrai clone vu qu'il y aura forcément des divergences.

        Un clonage via dd en offline est le plus approprié. Si ton HDD a un débit pas trop naze, en 2 heures c'est fait.
        C'est la méthode la plus simple (une commande à lancer) et la plus fiable pour cloner.

  • # pas comprendre l'interet ?

    Posté par  . Évalué à 3.

    si l'interet c'est d'avoir le nouveau systeme sur le SSD,

    tu sembles avoir 2 disques durs, que tu veux permuter,

    1°) permutes tes disques
    2°) installes ton nouvelle OS sur le nouveau disque

    3°) recuperes les données de l'ancien SSD.

    si tu ne veux/peux pas permuter les disques, mais que tu as un disque externe

    tu sauvegardes tes données en les copiant simplement d'un disque à l'autre
    (ou ton systeme complet, avec le liveCD/liveUSB du type clonezilla)
    du SSD vers le HDD externe, au pire tu pourras restaurer les anciennes données voire l'ancien systeme tel qu'il etait.

  • # rsync plutot

    Posté par  (site web personnel) . Évalué à 2.

    Que va t il se passer quand dd aura copié la table d'allocation des fichiers et que ces mêmes fichiers seront supprimés et d'autres ajoutés …
    Plutôt que dd, fais des rsync, le 1er dans la nuit pour tout copier, le 2eme juste avant de faire la permutation des disques.
    Dans le cas d'un disque bootable, ne pas oublier de faire un grub install en chroot sur le nouveau disque

    • [^] # Re: rsync plutot

      Posté par  . Évalué à 1.

      Justement c'est un boootable j'ai donc besoin d'un copie fidèle

  • # Process bien inutile ...

    Posté par  . Évalué à 7.

    Ton process est plutôt inutile…

    Pour rappel, les seules données qu'il faille réellement sauvegarder sont:

    • Ton répertoire /home
    • Ton répertoire /etc si et seulement si tu y as des configs un peu sioux.
    • Ton répertoire /var/spool si tu héberges un serveur de mail (le chemin peut varier en fonction de l'install)
    • Ton répertoire /var/www si tu héberges du site web
    • …

    Faire un dd sur l'intégralité du disque, c'est passer beaucoup de temps à copier des données parfaitement inutiles:

    • Tout les binaires, lib, header et autres statiques qui sont sur des dizaines de FTP et miroir HTTP à travers le monde.
    • Toutes les configurations par défaut qui sont aussi partout sur internet.
    • Et, le pire: du random. En effet, dd fait une copie secteur par secteur, y compris pour les secteurs qui ne sont pas utilisés par ton FS.

    Tu t'apprêtes donc à passer une nuit de copie pour rien.

    Les distributions modernes ont tendance à s'installer sur des volumes LVM2.
    Si tel est le cas de ta distribution, la migration se fait très simplement:

    • Sur le nouveau disque:

      • Création d'un pv (physical volume)
      • Ajout du pv nouvellement crée au vg (volume group) en cours d'utilisation sur ta machine.

    • Suppresion de l'ancien disque du vg.

    Et hop, LVM va mouliner un temps et migrer tes données tout seul.

    Sans LVM, perso, je lancerai mon install sur le disque vierge puis je recopierai à coup de rsync mes données depuis l'ancien …

    • [^] # Re: Process bien inutile ...

      Posté par  . Évalué à 1. Dernière modification le 05 février 2019 à 22:32.

      Bravo, en procédant ainsi, la machine ne bootera plus lorsque l'ancien disque sera enlevé

      • [^] # Re: Process bien inutile ...

        Posté par  . Évalué à 4.

        Comme dit plus haut, il vaut mieux enlever l'ancien disque, faire une réinstallation from scratch sur le nouveau, puis ensuite faire un rsync des données (/home) de l'ancien disque vers le nouveau.

        Sinon, le dd à chaud peut se faire si tu booot en mode rescue et que tu ouvres un shell (les volumes sont montés en read-only). J'ai fait ça il y a pas longtemps pour remplacer un SSD de 250 Gb par un SSD de 1 Tb. Le disque source avait une partition UEFI et une partition LVM:

        • boot en mode rescue + ouverture d'un shelll
        • dd du disque source vers le disque destination: Attention, avec le DD, le block size utilisé peut fortement accélérer ou ralentir le processus de copie. Dans mon cas, la copie a mis moins de 4 heures.
        • faire un gparted sur le disque cible pour corriger la table de partition (sauvegarder les modifs)
        • supprimer (je l'ai fait avec fdisk il me semble) la partition LVM
        • recréer la partition LVM sur la totalité de l'espace libre d disque: ne pas oublier de tagguer ette partition comme partition LVM
        • faire un pvresize sur la partition LVM du nouveau disque
        • étendre les partitions que l'on veut agrandir à l'aide de lvextend (+ resize2fs si besoin), ou en recrer d'autres.

        • [^] # Re: Process bien inutile ...

          Posté par  . Évalué à 4.

          Attention, avec le DD, le block size utilisé peut fortement accélérer ou ralentir le processus de copie

          +1
          C'est même carrément déterminant.

          Le block size (bs) par défaut est de 512 octets. Il faut au minimum le mettre à bs=1M pour avoir des bonnes performances de copies.

          Perso, à chaque fois que je fais un dd d'un HDD, je mets en bs=4M.
          Entre 2M, 4M, 8M ou plus, je n'ai jamais vraiment constaté de grosses différences.

      • [^] # Re: Process bien inutile ...

        Posté par  . Évalué à 2.

        totof2000: pourquoi ça ne booterait plus ?
        J'aimerai savoir … j'ai migré récemment d'un SSD 128Go vers un 500Go selon cette méthode.
        J'ai eu quelques petits soucis du à une mauvaise manip', mais ça a rebooté sans problème…

        D'ailleurs, ci-dessous un extrait d'une conversation sur #lvm sur freenode:

        17/12/2018 21:20 -!- Irssi: Join to #lvm was synced in 0 secs
17/12/2018 21:21 < binarym> hi all. I want to move my data from one disk to another. The original disk is already using LVM. I was planning to 1/ add new disk to VG 2/ remove old disk from VG 3/ wait for LVM to do the migration job. Will this work ?
17/12/2018 21:42 < Blacker47> binarym, pvcreate <new disk>; vgextend <VGname> <new disk>; pvmove <old disk>; vgreduce <VGname> <old disk>
17/12/2018 21:43 < binarym> Blacker47: ok thx. LVM is ultimate for disk migrations :)
17/12/2018 21:44 < binarym> Blacker47: what if i have a powercut during processus ? Does the vgreduce wait for action completion before really erasing data from old disk ?
17/12/2018 21:45 < Blacker47> vgreduce won't start if you have extents on drive you want to remove. you have to wait pvmove is completed. it can be restarted even after a powercut.
17/12/2018 21:45 < binarym> so, in theory, no data loss is possible ?
17/12/2018 21:46 < Blacker47> binarym, there is some info in "man pvmove"
17/12/2018 21:46 < binarym> ok...
17/12/2018 21:46 < binarym> let's try this then

  • # Beaucoup de temps

    Posté par  . Évalué à 6.

    Le soucis c'est qu'un “dd” de 500Go ca prend beaucoup de temps.

    500GB = 512 000MB

    A 10MB/s => 512 000 / 10 = 51 200s = 14h12m
    A 20MB/s => 14h12m / 2 = 07h06
    A 50MB/s => 14h12m / 5 = 02h50m
    A 80MB/s => 14h12m / 8 = 01h46m

    Juste comme ça, au feeling, si tu as un débit un minimum correct, tu y passeras moins d'une nuit.

  • # J'ai réussit merci à tous

    Posté par  . Évalué à 1.

    Merci à tous pour votre aide
    J'ai Fait un DD avec une liveUSB, et copié via Esata et ca pas prit plus de ~2H

    Je pense que mon message était pas assez clair pour que tous le monde comprenne mon soucis.

    Ayant 1 disque
    - Disque numéro 1 (SSD) avec système fonctionnel
    - Disque numéro 2 (HDD) vide

    à Terme mon but est d'avoir une nouvelle distrib from scratch sur le SSD.

    Ma Problématique:
    Je dois à tout moment avoir un sytème fonctionnel
    Config qui va prendre du temps.

    1. Je travaille sur l'ancien Système sur le SSD
    2. Je travaille sur l'ancien Système sur le HDD 2b. J'intalle et config le nouveau Système sur le SSD
    3. Je copie la data du hdd > SDD
    4. Je test le SSD
    5. Je bascule et travaille sur le nouveau Système sur le SSD

  • # Commentaire supprimé

    Posté par  . Évalué à 0. Dernière modification le 10 février 2019 à 10:12.

    Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.