Cloner un disque dur sous Ubuntu

aryliin

04 novembre 2019

Que ce soit suite à l’achat d’un nouveau disque, pour faire une sauvegarde, ou toute autre raison, vous souhaitez copier, à l’identique, le contenu d’un disque dur ou d’une clef USB. Mais, comme on n’est jamais trop prudent, le mieux est de s’assurer de ne rien toucher à l’original. On vous montre comment faire avec Ubuntu.

Lors d’une expertise, lorsque nous devons mener une investigation sur une pièce d’un dossier, il est important de la conserver intacte.

Imaginez-vous… Vous ouvrez votre scellé, vous branchez le disque dur qu’il contenait. Une fausse manipulation, et hop ! Des pièces à conviction disparaissent…

Avant toute action, il est donc indispensable de copier les disques durs et autres clés USB, afin de pouvoir travailler sur ces copies l’esprit tranquille.

Nous allons donc vous montrer comment vous y prendre en utilisant Ubuntu.

Disque dur

Désactiver montage automatique

⚠️ Ne branchez pas votre disque tout de suite !

Comme le but est de toucher le moins possible à l’original, la première chose à faire est de désactiver le montage automatique. Cela évitera de modifier quoique ce soit sur le support. Pour cela, on a besoin d’installer le paquet dconf-editor

sudo apt-get install dconf-editor

Lancer ensuite dconf-editor. Naviguez jusqu’à org.gnome.desktop.media-handling. De là, vous pouvez désactiver le montage automatique des media amovibles, en passant automount de I à O.

configuration via dconf-editor

Repérer son disque

Vous êtes à présent sûr que votre disque ne va pas se monter tout seul, et qu’une mauvaise manipulation ne pourra pas modifier quoique ce soit. Vous pouvez donc brancher votre disque.

Éteignez votre PC, branchez votre disque, redémarrez.

Vous allez devoir repérer à quel périphérique correspond votre disque. Pour cela, on utilise fdisk.

sudo fdisk -l

Les disques dur SATA et SSD sont dans dev/sd…, les disques IDE /dev/hd…. Servez-vous de vos connaissances sur votre disque dur pour le retrouver (en utilisant sa taille, l’OS installé…).

Par exemple : je cherche à repérer une clef USB de 32Go contenant mes données à investiguer…

Après avoir faire un fdisk, je repère deux périphériques intéressants, l’un dans /dev/sda et l’autre dans dev/sdb. En observant les détails, je peux me rendre compte que le disque dur SSD de 240Go sur lequel tourne mon linux se trouve dans /dev/sda et que ma clef USB qui fait 32Gb se trouve dans /dev/sdb. L’affichage utilisant des GiB, soit des Gibibytes, les valeurs sont légèrement inférieures à celles en Go.

Disque /dev/sda : 223,6 GiB, 240057409536 octets, 468862128 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : ----

Périphérique Amorçage Début       Fin  Secteurs Taille Id Type
/dev/sda1    *         2048 468860927 468858880 223,6G 83 Linux

Disque /dev/sdb : 29,3 GiB, 31457280000 octets, 61440000 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : ----

Périphérique Amorçage Début      Fin Secteurs Taille Id Type
/dev/sdb1    *           64 61439999 61439936  29,3G  b W95 FAT32

Calculer la somme de contrôle

Afin de pouvoir vérifier si des données ont été modifiée, on va en calculer la somme de contrôle. En comparant le résultat avant et après la manipulation, on contrôlera qu’aucune donnée n’a été altérée.

De base, dans le Référentiel Général de Sécurité, on nous dit que les fonctions de hachage doivent générer des empreintes de 200bits (avant 2020). Mais comme chez les arsouyes, on est en avance sur notre temps, on utilise la recommandations durcie pour après 2020, c’est à dire 256 bits[^anssi].

Toujours dans le RGS, SHA-256 est recommandée… Ce qui tombe bien, car sur Ubuntu, sha256sum est installé par défaut. On peut l’utiliser pour faire l’empreinte d’un périphérique en le couplant à dd.

En mettant en entrée (if) votre périphérique et en envoyant la sortie sur sha256sum, on obtient l’empreinte SHA-256 du périphérique.

time sudo dd if=/dev/sdb |sha256sum 
61440000+0 enregistrements lus
61440000+0 enregistrements écrits
31457280000 bytes (31 GB, 29 GiB) copied, 1773,13 s, 17,7 MB/s
e3375bb22d59233757cbcb24d7f4ffa7b25eaff40e60e40f42f3a22435bf2655  -

real    29m33,203s
user    12m44,728s
sys 4m15,840s

En utilisant time, on peut se rendre compte que pour calculer l’empreinte de ma clef de 32Go, il a fallu 30 minutes environ. Bon à savoir lorsque l’on aura un disque de 1To.

Copier le disque

On a branché le périphérique, en s’assurant qu’on ne pouvait pas faire de bêtises, on a fait une empreinte, il ne nous reste plus qu’à le cloner. Pour cela, on utilise encore une fois dd avec la commande suivante :

sudo dd if=device of=fichier.iso conv=notrunc,noerror status=progress

Où les paramètres ont le sens suivant :

time sudo  dd if=/dev/sdb of=clef.iso conv=notrunc,noerror status=progress
31444406272 bytes (31 GB, 29 GiB) copied, 1981 s, 15,9 MB/s
61440000+0 enregistrements lus
61440000+0 enregistrements écrits
31457280000 bytes (31 GB, 29 GiB) copied, 1981,74 s, 15,9 MB/s

real    33m4,898s
user    1m36,367s
sys 11m27,615s

Notez que ça m’a pris encore une demie heure…

Vérifier l’intégrité

Notre copie est faite, nous allons calculer une nouvelle empreinte du périphérique, afin de vérifier que celui-ci n’a pas été altéré pendant la copie. Profitons-en également pour vérifier que la copie est bien conforme à l’originale.

On refait l’empreinte du périphérique. Même commande que tout à l’heure :

time sudo dd if=/dev/sdb |sha256sum 
[sudo] Mot de passe de arsouyes : 
61440000+0 enregistrements lus
61440000+0 enregistrements écrits
31457280000 bytes (31 GB, 29 GiB) copied, 1755,58 s, 17,9 MB/s
e3375bb22d59233757cbcb24d7f4ffa7b25eaff40e60e40f42f3a22435bf2655  -

real    29m18,712s
user    10m34,172s
sys 3m37,959s

Puis, on fait le SHA 256 de l‘iso (pour vérifier que la copie est bien conforme à l’original) :

time sudo dd if=clef.iso |sha256sum
[sudo] Mot de passe de arsouyes : 
61440000+0 enregistrements lus
61440000+0 enregistrements écrits
31457280000 bytes (31 GB, 29 GiB) copied, 1111,31 s, 28,3 MB/s
e3375bb22d59233757cbcb24d7f4ffa7b25eaff40e60e40f42f3a22435bf2655  -

real    18m34,487s
user    10m2,526s
sys 3m56,255s

Et enfin on compare les empreintes. Ici, bingo, elles sont bien identiques.

Une donnée altérée serait détectée par un sha256 différent :

Vous pouvez aussi mettre l’empreinte initiale dans un fichier (par exemple Initial_CHECKSUM) et calculer l’empreinte avec l’option -c comme suit :

sudo dd if=device | sha256sum -c Initial_CHECKSUM

Où device est soit votre fichier iso, soit votre périphérique (en fonction de ce que vous voulez faire).

Si l’empreinte est la même, vous aurez un joli petit OK en sortie, mais si l’empreinte diffère, vous obtiendrez un FAILED suivit de sha256sum: WARNING: 1 computed checksum did NOT match.

Et après

Maintenant que vous avez une copie toute belle de votre périphérique, vous allez pouvoir replacer votre original dans son petit sachet et refermer votre scellé.

Si vous n’êtes pas expert judiciaire et que vous n’avez pas à gérer de scellés, vous pouvez quand même être fier de ne rien avoir modifié sur votre disque original.

Backup de données chez OVH avec duplicity

11 février 2019 Il serait dommage de perdre nos données personnelles. Grâce aux serveurs de OVH et à duplicity, il est facile de mettre en place un système de sauvegarde automatique.

Récupération des données sauvegardées chez OVH avec duplicity

18 mars 2019 Les commandes utiles pour lister et récupérer ses fichers une fois que l’on a sauvegardé ses données dans le Public Cloud OVH avec duplicity.

Backup de dépôt gitlab

4 mars 2019 Afin de sauvegarder ses dépôts gitlab, il peut être utile de faire un miroir de son dépôt afin de conserver sur un serveur distant ses fichiers, mais également toutes les modifications