J'ai sauvegardé tout mon disque dur avec dd
dans un file image. Le disque dur contenait certaines partitions primaires formatées avec ntfs, swap et ext4. Je l'ai fait de cette façon:
dd if=/dev/sda | ssh user@fastmachine "cat - > diskimage.img"
Ensuite, j'ai écrasé les premiers 5 à 6 Go de mon disque dur à des fins de test avec un nouveau système:
Après avoir testé le système de test, je veux récupérer mon ancien système. Mais mon disque dur local est très lent lors de l'écriture. Pour gagner du time et de l'énergie, je veux seulement restaurer environ 6 Go de l'image. Est-ce suffisant et sécuritaire? Cela fonctionnerait-il? Je le ferais de cette façon:
ssh user@fastmachine "dd if=diskimage.img bs=1M count=6000" | dd of=/dev/sda
Il a travaillé à restaurer partiellement le disque dur.
Je viens de tester la vitesse d'écriture avec
dd if=/dev/zero of=blub count=1000 bs=1M
Et
ssh user@fastmachine "dd if=/dev/zero count=1000 bs=1M" | dd of=blub
Mais: ssh sur WLAN (sans fil) seulement était 1,3 MByte / s! C'était le problème.
ssh a pris 68% de charge CPU lors de la copy sur ethernet, et seulement 20% lors de la copy sur WLAN (sans fil).
Conclusion: Si j'avais un réseau plus rapide et un disque dur / lecteur flash, j'utiliserais netcat (nc) pour copyr datatables.
Théoriquement, cela peut fonctionner, il y a cependant une mise en garde: vous ne devez pas changer la disposition du disque en dehors de la zone que vous avez l'intention de rebuild. L'important est de savoir quel schéma de partitionnement a été utilisé sur le disque. Pour MBR c'est facile, puisque datatables sont contenues dans le premier secteur (et dans les en-têtes des partitions logiques). Pour GPT c'est un peu plus compliqué – il y a deux copys des données de partition et elles devraient correspondre. D'une manière générale, si votre logiciel de partition le prend en charge (par exemple, gdisk
), utilisez-le pour save datatables de schéma dans un file et les restaurer en plus des données.
Alternativement, si c'est une option, envisagez de placer les deux lecteurs sur le même ordinateur, à less que vous n'ayez une configuration assez inhabituelle *), ssh
sera le goulot d'étranglement dans le transfert de données.
*) un processeur récent couplé à un disque dur extrêmement lent comme un disque dur ATA très ancien ou mal configuré, un périphérique flash bas de gamme (carte memory ou disque flash) ou tout ce qui est connecté via USB, fonctionnant uniquement en v1.1 ou version spécialement patché d'OpenSSH.
Si les partitions écrasées / modifiées étaient complètement dans la première partie du disque, et si rien ne changeait dans le disque restant, cela serait sans danger. C'est risqué en tout cas. Pourquoi ne pas laisser la restauration s'exécuter du jour au lendemain?