[résolu] cloner un SSD chiffré

raleur · 25-03-2022 22:45:11

willy64 a écrit :

il faut éviter de connecter le disque et son clone en même temps sur le même ordinateur car l'utilisation simultané a tendance à perturber le système qui ne sait pas lequel prendre des deux

C'est précisément le but ici, donc clonage simple inapplicable.

willy64 a écrit :

Si on veut un clonage en simultané, le mieux est de se tourner vers une solution de raid matériel ou logiciel

Très mauvaise idée. Le RAID réplique les erreurs de manipulation, effacements accidentels et corruptions de données sur tous les disques.
Le RAID, c'est pour la tolérance de panne ou la performance et c'est tout, pas pour le clonage et encore moins la sauvegarde.

willy64 · 25-03-2022 23:27:27

raleur a écrit :

Très mauvaise idée. Le RAID réplique les erreurs de manipulation, effacements accidentels et corruptions de données sur tous les disques.
Le RAID, c'est pour la tolérance de panne ou la performance et c'est tout, pas pour le clonage et encore moins la sauvegarde.

Oui je connais le principe du Raid mais d'après ce que j'ai compris de la demande, totoZero7 veut avoir un ssd de secours afin de prendre le relais si son ssd principal plante. Donc, soit il fait régulièrement un clone de son SSD afin d'avoir un ssd le plus à jour possible en effectuant une sauvegarde de ses données personnelles à intervalle régulier (toutes les 30 minutes, 2 h, 6 h, etc. soit il met en place un système raid. Bien évidemment, le raid ne protège pas des erreurs de manipulations humaines, là dessus je suis d'accord. Et je n'ai pas dit que le Raid était une sauvegarde, j'ai utilisé le mot "clonage" simplement car en Raid 1, les données sont copiées sur les deux disques, donc au niveau des données, il y a clonage, dédoublement, copie, bref, les données sont écrites sur les deux disques et en cas de défaillance de l'un ou de l'autre, le système peut continuer à fonctionner.

J'ai posté simplement parce que je trouve que c'est bien plus compliqué de changer l'UUID, pour un système destiné au "secours" en cas de plantage du premier, tout en assurant une copie des données les plus récentes. C'est un peu usine à gaz alors que des solutions simples pourraient être envisagées et si c'est un soucis de continuité de fonctionnement, opter pour le Raid 1

totoZero7 · 27-03-2022 14:42:48

Je reformule pour désactiver spécifiquement de SSD

Voici ce que j'ai à l'écran quand j'ai une clé usb branchée que je viens de démonter (avec l'utilitaire Disques ou avec le terminal).

lsblk -f

sdc                                                                                                         

└─sdc1                  vfat        FAT32    tosh16Go B351-D30E 

Avec l'utilitaire Disques (gnome-disk-utility), il y a une case pour "éjecter ce disque"
Si je clique dessus et qu'ensuite je fais un lsblk -f, je ne vois plus la clé USB avec la commande lsblk -f

lsblk -f

vide

Maintenant, si je veux faire pareil avec le SSD et que tout est démonté, ça affiche ceci:

sdd                                                                                                         

├─sdd1                  ext2        1.0               1ad1838b-a329-45f9-9be8-0610fea0e30f                  

├─sdd2                                                                                                      

└─sdd5                  crypto_LUKS 2                 4b40da24-1506-4705-80b8-66d072b9c9ad

Mais l'utilitaire ne me propose pas "d’éjecter le disque".

C'est pour cela que je cherche la solution avec le terminal
Comment éjecter avec le terminal ?

J'ai une autre question
Est-ce que "démonté" est suffisant pour retirer le disque SSD d'un port USB (ou autre) en toute sécurité ou faut-il absolument que le disque soit démonté ET éjécté avant de le retirer ?

totoZero7 · 27-03-2022 16:32:34

J'ai rencontré un changement - Le NOM de volume se renomme tout seul
Après l'étape "Renommer [sda5_crypt]" qui a été réussi, j'ai arreté et éteint le disque.

Quand j'ai ouvert de nouveau le volume chiffré, le NOM avait changé.
J'avais initialement changé pour "sdclone_crypt" avec cette commande:

sudo dmsetup rename luks-4b40da24-1506-4705-80b8-66d072b9c9ad sdclone_crypt

Et là ça m'affiche "crypto_LUKS" comme NOM quand je l'ouvre.
Cela dit, j'ai ouvert en mettant ce nom (enfin, je pensais que crypto_LUKS était le système de fichier et non le NOM)
# j'ai ouvert le volume chiffré ainsi

sudo cryptsetup open --type luks /dev/sdd5 crypto_LUKS

lsblk -f

sdd                                                                                                           

├─sdd1                    ext2        1.0               1ad1838b-a329-45f9-9be8-0610fea0e30f                  

├─sdd2                                                                                                        

└─sdd5                    crypto_LUKS 2                 4b40da24-1506-4705-80b8-66d072b9c9ad                  

  └─crypto_LUKS         LVM2_member LVM2 001          yIJgYh-oT4j-BkqR-7qe4-4weR-eGDI-b8WZ2f                

    ├─debM11SSDclo-root   ext4        1.0               0c670bab-560f-4b24-8854-5f6026f8e1d7                  

    └─debM11SSDclo-swap_1 swap        1                 c602329f-c370-4d7f-83cb-505fc13b33be

Maintenant, si j'ouvre avec l'utilitaire de disque, il me remets "luks-4b40da24-1506-4705-80b8-66d072b9c9ad" comme NOM.

J'en déduis qu'on peut ouvrir en métant le NOM de son choix.

Question
------------
Si je veux faire une manipulation avec le nom "crypto_LUKS" mis lors de l'ouverture du volume chiffré et que le nom dans /etc/crypttab soit "sdclone_crypt",
Est-ce que ça craint ?

Comment ça se fait que le volume ne s'ouvre pas avec le bon NOM même avec l'utilitaire ?
Comment savoir le nom d'ailleurs, vue de l'extérieur ? Et-il possible d'ouvrir avec le vrai NOM sans le savoir avant ?

raleur · 27-03-2022 17:26:14

totoZero7 a écrit :

C'est pour cela que je cherche la solution avec le terminal
Comment éjecter avec le terminal ?

Démonter les systèmes de fichiers, désactiver les volumes logiques, fermer les volumes chiffrés suffit. Il est inutile d'éjecter. Si tu "éjectes" le support, tu ne pourras plus l'utiliser sans le débrancher et le rebrancher.

totoZero7 a écrit :

Si je veux faire une manipulation avec le nom "crypto_LUKS" mis lors de l'ouverture du volume chiffré et que le nom dans /etc/crypttab soit "sdclone_crypt",
Est-ce que ça craint ?

Oui, cela peut perturber update-initramfs pour générer l'initramfs. update-initramfs doit déterminer quels volumes chiffrés dans /etc/crypttab doivent être ouverts par l'initramfs, et pour cela il compare les noms des volumes dans /etc/crypttab et les noms des volumes chiffrés ouverts. Un moyen de forcer l'ouverture d'un volume chiffré par l'initramfs consiste à ajouter l'option "initramfs" pour ce volume chiffré dans /etc/crypttab.

totoZero7 a écrit :

Comment ça se fait que le volume ne s'ouvre pas avec le bon NOM même avec l'utilitaire ?
Comment savoir le nom d'ailleurs, vue de l'extérieur ? Et-il possible d'ouvrir avec le vrai NOM sans le savoir avant ?

Un volume chiffré LUKS n'a pas de nom intrinsèquement. Il n'a que le nom qu'on lui donne arbitrairement lors de son ouverture.

totoZero7 · 28-03-2022 10:52:10

Je rencontre un problème avec crypttab

- J'ai démarré sur mon SSD1 (et non sur le Live).
- J'ai branché le SSD2 et l'ai déverrouillé en lui donnant le NOM "sdclone_crypt" Le même nom que celui qui est dans le fichier /etc/crypttab

sudo cryptsetup open --type luks /dev/sdd5 sdclone_crypt

- Activé les volumes logiques

sudo vgchange -ay debM11SSDclo

- Puis monté la partition système dans ce répertoire :

sudo mount /dev/mapper/debM11SSDclo-root /mnt/plouf/

- Puis monté ces périphériques et lancé chroot

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

sudo mount --bind /sys/ /mnt/plouf/sys

sudo mount -t proc /proc /mnt/plouf/proc

sudo chroot /mnt/plouf /bin/bash

sudo mount -a

- Je lance la reconstruction de l'initramfs et j'obtiens un avertissement

update-initramfs -u

cryptsetup: WARNING: target 'sda5_crypt' not found in /etc/crypttab

Là je ne comprends pas car j'ai biens suivi la procédure.
Pourquoi il me demande "sda5_crypt" ?
Note: je suis sur mon SSD1 et lui s'appelle 'sda5_crypt' mais bon. Si je suis sur l'autre système grâce à chroot, ça ne devrait pas se mélanger... si ?

raleur · 28-03-2022 12:33:45

update-initramfs ne devrait se préoccuper que des volumes chiffrés supportant la racine ou le swap sélectionné pour l'hibernation.
Toujours dans le chroot, regarde dans /etc/initramfs-tools/conf.d/resume si le swap indiqué dans la variable RESUME n'est pas encore celui du système originel ou "auto". Dans ce cas modifie-le comme dans /etc/fstab, et update-initramfs ne devrait plus afficher l'avertissement.

totoZero7 · 28-03-2022 12:57:11

Il était mis sur l'ancien. Je l'ai changé et c'est passé

Pour update-grub, ça a changé le grub de SSD1 et non de SS2 on dirait (debM11SSD2 = SSD1) (debM11SSDclo = SSD2)

root@debM:/# sudo update-grub

Generating grub configuration file ...

Found background image: /usr/share/images/desktop-base/desktop-grub.png

Found linux image: /boot/vmlinuz-5.10.0-11-amd64

Found initrd image: /boot/initrd.img-5.10.0-11-amd64

Found linux image: /boot/vmlinuz-5.10.0-10-amd64

Found initrd image: /boot/initrd.img-5.10.0-10-amd64

Found Debian GNU/Linux 11 (bullseye) on /dev/mapper/debM11SSD2-root

done

C'est pas le grub de SSD1 qui devrait changer ?

totoZero7 · 28-03-2022 13:10:04

autre chose, quand j'ouvre un autre terminal, je m'aperçois que mon disque secondaire "disk3" est monté sur "/mnt/plouf" alors qu'il devrait être monté sur /disk3

toto@debM:~$ lsblk -f

NAME                      FSTYPE      FSVER    LABEL    UUID                                   FSAVAIL FSUSE% MOUNTPOINT

sdb                                                                                                           

└─sdb1                    crypto_LUKS 1                 5b8a3dc3-3fdd-4045-a5a2-11fc067fdfd6                  

  └─sdb1                  ext4        1.0      other    7e9ee5ca-dc94-4ca7-b4a6-d8f9202e7bcf    289,2G    63% /mnt/plouf/disk3

je n'ose pas fermer l'ordi de peur d'avoir fait une erreur

raleur · 28-03-2022 13:14:20

os-prober a détecté le système installé dans debM11SSD2, donc update-grub a mis à jour la configuration de debM11SSDclo (os-prober ne détecte pas le système depuis lequel il est exécuté). Tu peux vérifier dans /boot/grub/grub.cfg.

raleur · 28-03-2022 13:17:57

totoZero7 a écrit :

quand j'ouvre un autre terminal, je m'aperçois que mon disque secondaire "disk3" est monté sur "/mnt/plouf" alors qu'il devrait être monté sur /disk3

Si ce montage est défini dans /etc/fstab, il a été effectué lors de l'exécution de mount -a dans le chroot. Il est peut-être monté deux fois, vérifie dans /proc/mounts.

totoZero7 · 28-03-2022 13:27:35

En effet, il figure aussi dans le fstab
Il a été monté 2 fois

toto@debM:~$ cat /proc/mounts |grep disk3

/dev/mapper/sdb1 /disk3 ext4 rw,relatime 0 0

/dev/mapper/sdb1 /mnt/plouf/disk3 ext4 rw,relatime 0 0

Mais du coup, ça fait quoi concrètement ? ça peut faire des erreurs ?
est-ce que je dois, lors d'une future manipulation, débrancher le disk3 ? ou tout autre support qui serait enregistré dans le fstab ?

raleur · 28-03-2022 13:35:48

totoZero7 a écrit :

Mais du coup, ça fait quoi concrètement ? ça peut faire des erreurs ?

Ça monte le système de fichiers et le rend accessible à deux endroits différents. Tu as déjà fait la même chose avec /dev et /sys (bind mount) pour préparer le chroot. C'est parfaitement prévu et géré.

totoZero7 a écrit :

est-ce que je dois, lors d'une future manipulation, débrancher le disk3 ? ou tout autre support qui serait enregistré dans le fstab ?

Non. Plutôt, à ta place j'éviterais d'exécuter mount -a dans un chroot et je monterais seulement ce qui est nécessaire, ici /boot. Mais a priori tu ne devrais plus avoir besoin de refaire un chroot si le clone modifié boote bien tout seul.

Dernière modification par raleur (28-03-2022 13:36:20)

totoZero7 · 28-03-2022 13:45:57

Je n'ai pas encore fait le test de démarrer le SSD2, je ferai ça plus tard.
Mais avant, j'ai 2 observations

1. Lors des modifications, il n'a pas eu de changement sur les PARTUUID
SSD1 (/boot)

sudo blkid /dev/sda1 

/dev/sda1: UUID="755370b5-d296-4af0-942e-1b8e3dd51628" BLOCK_SIZE="1024" TYPE="ext2" PARTUUID="077bd2db-01"

SSD2 (/boot)

sudo blkid /dev/sdd1

/dev/sdd1: UUID="1ad1838b-a329-45f9-9be8-0610fea0e30f" BLOCK_SIZE="1024" TYPE="ext2" PARTUUID="077bd2db-01"

Question
-------------
Faut il les changer ?
Comment changer le partuuid ?

2. Pendant la modification du Contenu des volumes logiques UUID de [/root], j'ai eu une rencontre étrange
En voulant nettoyer l'uuid de root ou même en voulant le modifer directement j'obtiens ce message:

sudo tune2fs -U clear /dev/debM11SSD2/root

tune2fs 1.46.2 (28-Feb-2021)

This operation requires a freshly checked filesystem.

Please run e2fsck -f on the filesystem.

Du coup, j'exécute la commande est ça me demande si je dois optimiser ou pas

sudo e2fsck -f /dev/debM11SSD2/root

e2fsck 1.46.2 (28-Feb-2021)

Pass 1: Checking inodes, blocks, and sizes

Inode 1838784 extent tree (at level 1) could be narrower.  Optimize<y>? no

Inode 3146607 extent tree (at level 1) could be shorter.  Optimize<y>? no

Inode 3146609 extent tree (at level 1) could be shorter.  Optimize<y>? no

Inode 3146610 extent tree (at level 1) could be shorter.  Optimize<y>? no

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

/dev/debM11SSD2/root: 245253/59981824 files (0.7% non-contiguous), 64234906/239910912 blocks

J'ai mis de "no" à la demande.
J'ai refait cet exercice, un autre jour, en méttant des "yes" pour voir la difference

sudo e2fsck -f /dev/debM11SSDclo/root

e2fsck 1.46.2 (28-Feb-2021)

Pass 1: Checking inodes, blocks, and sizes

Inode 1838784 extent tree (at level 1) could be narrower.  Optimize<y>? yes

Inode 3146607 extent tree (at level 1) could be shorter.  Optimize<y>? yes

Inode 3146609 extent tree (at level 1) could be shorter.  Optimize<y>? yes

Inode 3146610 extent tree (at level 1) could be shorter.  Optimize<y>? yes

Pass 1E: Optimizing extent trees

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

/dev/debM11SSDclo/root: ***** FILE SYSTEM WAS MODIFIED *****

/dev/debM11SSDclo/root: 245253/59981824 files (0.7% non-contiguous), 64234902/239910912 blocks

Question: Mettre "yes" ou des "no" pour optimize, ça fait quoi au juste ? qu'est-ce que cela a modifié ?
Est-il préférable de mettre des yes ou des no ?

raleur · 28-03-2022 14:02:58

totoZero7 a écrit :

Faut il les changer ?
Comment changer le partuuid ?

Primo, ce ne sont pas de vrais PARTUUID car la table de partition DOS/MBR ne supporte pas les PARTUUID (contrairement à GPT). Ce sont des PARTUUID synthétiques générés par le noyau (depuis une certaine version) à partir de l'identifiant disque du MBR et du numéro de partition.
Secundo, comme ils ne sont pas utilisés dans ton installation tu n'as pas vraiment besoin de les changer (ou plutôt l'identifiant du disque).
Pour changer l'identifiant du disque, tu peux utiliser fdisk en mode expert (x puis i). Il faudra soit entrer un nombre décimal, soit un nombre hexadécimal préfixé par 0x.

totoZero7 a écrit :

sudo e2fsck -f /dev/debM11SSDclo/root

Je ne pense pas que mettre un UUID à zéro soit une bonne idée. Un UUID est censé être unique, zéro est tout saut unique. Si tu as besoin de changer un UUID, spécifie plutôt random ou time.

totoZero7 a écrit :

Mettre "yes" ou des "no" pour optimize, ça fait quoi au juste ? qu'est-ce que cela a modifié ?

Je suppose que ça fait gagner un peu d'espace disque. Vu le taux d'occupation actuel, ce n'est pas une priorité.

totoZero7 · 28-03-2022 17:07:56

Je vais mettre PARTUUID de côté donc.

Par-contre je n'ai pas compris cette histoire de zéro avec e2fsck.
Je vais détailler mon procédé et tu me dis là où c'est pas bon et où zéro intervient

4. Contenu des volumes logiques UUID de [/root] -

------------------------------------------------

# 4.1 - Affiche l'uuid actuel

sudo tune2fs -l /dev/debM11SSD2/root |grep UUID

# 4.2 - Générer aléatoirement un UUID

cat /proc/sys/kernel/random/uuid

# 4.3 - Ensuite, mettre le paramètre "clear" qui va nettoyer l'uuid

sudo tune2fs -U clear /dev/debM11SSD2/root

  4.3.1 - Ce message apparait (This operation requires a freshly checked filesystem) Faire donc la commande:

sudo e2fsck -f /dev/debM11SSD2/root

  4.3.2 - Refaire 4.3 et passer à 4.5

# 4.5 - Faire la modification (remplacer l'uuid ci dessous par le random):

sudo tune2fs -U 0c670bab-560f-4b24-8854-5f6026f8e1d7 /dev/debM11SSD2/root     //(exemple)

# 4.4 - Vérifier si le changement d'uuid à fonctionné

sudo blkid /dev/debM11SSD2/root

J'ai été contraint d'utiliser "e2fsck -f" d'après le message après avoir exécuté tune2fs -U clear.
et il me semble que ça a fait la même chose quand j'ai zapé la commande clear et suis passé direct a un UUID nouveau, sur un autre essai.

raleur · 28-03-2022 17:40:12

En fait "tune2fs -U clear" ne met pas l'UUID à 0 mais l'efface, le système de fichiers n'a donc plus d'UUID. C'est inutile, on peut changer l'UUID directement avec "tune2fs -U random" sans l'effacer d'abord.

totoZero7 · 28-03-2022 17:57:51

Donc le zéro c'est "tune2fs -U clear" et pas "e2fsck -f"
ok pour ça

Mais il y a toujours un message (je viens de refaire 2 tests) sans passer par clear

sudo tune2fs -U 91e30d07-3a0f-45cc-a24d-4ecce12a4928 /dev/debM11SSDclo/root

tune2fs 1.46.2 (28-Feb-2021)

This operation requires a freshly checked filesystem.

Please run e2fsck -f on the filesystem

.

sudo tune2fs -U random /dev/debM11SSDclo/root

tune2fs 1.46.2 (28-Feb-2021)

This operation requires a freshly checked filesystem.

Please run e2fsck -f on the filesystem.

Que ce soit l'une ou l'autre, j'ai quand même le message alors que je n'ai pas utilisé "clear"
Pourquoi j'ai ce message ?

raleur · 28-03-2022 21:30:59

Je l'ignore. En tout cas ça n'a rien à voir avec "clear", c'est lié à tune2fs -U.

totoZero7 · 28-03-2022 21:37:26

Vocabulaire
debM11SSDclo-root et debM11SSDclo-swap sont des volumes ou des partitions ?
je capte mal la différence avec les volumes chiffrés

Bon, j'ai booté dessus et ça fonctionne.
Note: lors de l'allumage, au moment de mettre la passphrase, il y avait une phrase juste au dessus (que je n'ai pas mémorisé bien sûr), qui disait attendre un UUID (celui du root)
ça n'a rien bloqué. Mais est-ce normal cet affichage alors que je n'ai pas ça avec l'autre SSD ?

Merci raleur !
3 semaines dessus avec un tuto de + de 300lignes (oué tout le monde n'est pas geek).
Je suis content, j'ai été au bout de la procédure qui m'a retourné la tête, mais c'est quand même pas rapide à faire ni à comprendre. C'est pas n'importe-qui qui peut s'y aventurer.
Cela dit, j'ai approché de plus près ce satané cryptsetup qui m'était vraiment obscur alors que je l'utilise au quotidien que ce soit avec le système ou en container à part et je peux même chrooter (Nom nouveau pour moi) le SSD cloné pour le mettre à jour depuis mon SSD1 ! ; et rien que pour ça, ça vaut la tarte que je me suis prise.
(à la base, j'avais juste changé le HDD pour un SSD et je me suis retrouvé dans une aventure...)
Je marque en résolu

Du coup, si on peut faire autrement, et surtout plus facilement, je veux bien avoir des avis comme willy64 en a fait une proposition

Dernière modification par totoZero7 (28-03-2022 21:39:16)

raleur · 29-03-2022 13:52:10

totoZero7 a écrit :

debM11SSDclo-root et debM11SSDclo-swap sont des volumes ou des partitions ?
je capte mal la différence avec les volumes chiffrés

Ce sont des volumes logiques LVM, pas des partitions. Les volumes chiffrés sont aussi gérés par le "device-mapper", c'est pourquoi on les voit aussi dans /dev/mapper/, mais créés par cryptsetup et non LVM. Les deux peuvent s'utiliser comme des partitions.

totoZero7 a écrit :

Note: lors de l'allumage, au moment de mettre la passphrase, il y avait une phrase juste au dessus (que je n'ai pas mémorisé bien sûr), qui disait attendre un UUID (celui du root)

L'UUID du système de fichiers ext4 du volume logique root ou l'UUID du volume chiffré LUKS ?

totoZero7 a écrit :

Du coup, si on peut faire autrement, et surtout plus facilement, je veux bien avoir des avis

Si le but est d'obtenir une copie opérationnelle du système qui puisse cohabiter avec le système originel, j'ai déjà donné mon avis plus haut : au lieu de cloner le disque, il aurait fallu créer le partitionnement et les volumes à la main puis y copier le contenu des systèmes de fichiers. Cela aurait évité de devoir changer tous les UUID et les noms du VG et du volume chiffré, mais il aurait quand même fallu modifier les fichiers de configuration et regénérer l'initramfs et grub.cfg.

Dernière modification par raleur (29-03-2022 14:35:24)

totoZero7 · 29-03-2022 14:05:59

erreur de lecture.
En effet c'est l'UUID du volume chiffré LUKS et non le root qui s'affiche

cryptsetup: waiting for encrypted source device UUID=4b40da24-1506-4705-80b8-66d072b9c9ad

raleur · 29-03-2022 14:35:55

Donc ça me paraît un peu normal.

totoZero7 · 29-03-2022 14:44:14

raleur a écrit :

il aurait fallu créer le partitionnement et les volumes à la main puis y copier le contenu des systèmes de fichiers.

ça sera le sujet de mon prochain post XD car je plane déjà à installer Debian avec l'assistant, alors en manuel... il va me falloir obligatoirement de l'aide.

L'idée actuelle est de pouvoir faire un rsync (manuellement) de SSD1 vers SSD2 sur des sections choisies pour que le système du SSD2 soit le plus à jour possible (1 fois tous les 3 mois c'est bien, vu que mes dossiers perso sont, eux, sauvegardés en plus sur un autre support) en prenant les changement de configurations de logiciels/Bureau/VM qui se passe dans le temps et aussi les dossiers perso qui grossissent au fur à mesure.
Je ne sais pas si mon idée est correct, mais c'est ainsi que je vois la chose et qui me parait assez simple à faire tout en maîtrisant ce que je fais.

La question est: est-ce que c'est jouable ? ou est-ce farfelu ?
car comme les UUID et les NOMS de VG sont différents, je ne peux pas faire une syncho complète ! Peut-être qu'il y a d'autres éléments à ne pas inclure.

Admettons que cela soit jouable, quels seraient les dossiers à ne surtout pas transférer pour ne pas péter le système bis ?

raleur · 31-03-2022 22:56:48

Pour que je sois sûr de bien comprendre, tu voudrais synchroniser seulement les données et configurations des utilisateurs ou bien aussi le système et les paquets au lieu de le mettre à jour normalement avec apt en chrootant ou en bootant sur le SSD2 ?

Debian-facile

#26 25-03-2022 22:45:11

Re : [résolu] cloner un SSD chiffré

#27 25-03-2022 23:27:27

Re : [résolu] cloner un SSD chiffré

#28 27-03-2022 14:42:48

Re : [résolu] cloner un SSD chiffré

#29 27-03-2022 16:32:34

Re : [résolu] cloner un SSD chiffré

#30 27-03-2022 17:26:14

Re : [résolu] cloner un SSD chiffré

#31 28-03-2022 10:52:10

Re : [résolu] cloner un SSD chiffré

#32 28-03-2022 12:33:45

Re : [résolu] cloner un SSD chiffré

#33 28-03-2022 12:57:11

Re : [résolu] cloner un SSD chiffré

#34 28-03-2022 13:10:04

Re : [résolu] cloner un SSD chiffré

#35 28-03-2022 13:14:20

Re : [résolu] cloner un SSD chiffré

#36 28-03-2022 13:17:57

Re : [résolu] cloner un SSD chiffré

#37 28-03-2022 13:27:35

Re : [résolu] cloner un SSD chiffré

#38 28-03-2022 13:35:48

Re : [résolu] cloner un SSD chiffré

#39 28-03-2022 13:45:57

Re : [résolu] cloner un SSD chiffré

#40 28-03-2022 14:02:58

Re : [résolu] cloner un SSD chiffré

#41 28-03-2022 17:07:56

Re : [résolu] cloner un SSD chiffré

#42 28-03-2022 17:40:12

Re : [résolu] cloner un SSD chiffré

#43 28-03-2022 17:57:51

Re : [résolu] cloner un SSD chiffré

#44 28-03-2022 21:30:59

Re : [résolu] cloner un SSD chiffré

#45 28-03-2022 21:37:26

Re : [résolu] cloner un SSD chiffré

#46 29-03-2022 13:52:10

Re : [résolu] cloner un SSD chiffré

#47 29-03-2022 14:05:59

Re : [résolu] cloner un SSD chiffré

#48 29-03-2022 14:35:55

Re : [résolu] cloner un SSD chiffré

#49 29-03-2022 14:44:14

Re : [résolu] cloner un SSD chiffré

#50 31-03-2022 22:56:48

Re : [résolu] cloner un SSD chiffré

Pied de page des forums