Utilisateur mac historique, je suis en recherche de solutions de
migration, point par point, pour les aspects et fonctions qui me sont
importants et je bloque sur le chiffrage à la volée de gros volumes
que permet, sous MacOS, FileVault 2.
L'essai que je viens de faire de Veracrypt ne soutient absolument pas
la comparaison, en particulier pour la mise en œuvre. Du moins
jusqu'à plus ample informé, raison de ce post.
S'agissant du chiffrage d'un volume de 3 To, ai-je raison de
constater que cela prend une trentaine d'heures ? Et pas en
arrière-plan ni avec possibilité d'interruption puis de reprise en
cours que permet Filevault ?
Je ne cherche pas à valoriser quoi que ce soit par rapport à quoi que
ce soit. Juste à trouver des solutions viables et inter-plateformes,
de préférence en open-source (sans obligation).
Peut-être suis-je parti sur une mauvaise piste ? Y a-t-il d'autres
solutions concurrentes ? On est d'accord que pour des dossiers
chiffrés de volume plus faible, VC fonctionne bien (même si on n'a
pas la fluidité d'une solution intégrée au système). J'ai ainsi créé
un dossier de 10 Go sur une clé USB en 6 minutes. Mais évidemment la
règle de trois est ensuite implacable... pour 100 Go -> 60 minutes etc.
Info additionnelle : après reformatage du disque (toujours en ExFAT, vérification par les outils systèmes, reprise du chiffrement à partir d'un autre ordi, et alors que le premier quart semblait s'être déroulé convenablement en 1h30, désormais (30% du processus) c'est revenu au même délire : lenteur incroyable de l'ordi, roue de la mort multicolore à chaque action (appel de menu ou autre), swap de 2 Go...
Tu peux tout de même préciser: - le disque n'est pas une clé USB mais un vrai disque - avec quel OS cela rame ?
Le 28/09/2020 à 16:01, Gerald a écrit :
Info additionnelle : après reformatage du disque (toujours en ExFAT,
vérification par les outils systèmes, reprise du chiffrement à partir
d'un autre ordi, et alors que le premier quart semblait s'être
déroulé convenablement en 1h30, désormais (30% du processus) c'est
revenu au même délire : lenteur incroyable de l'ordi, roue de la mort
multicolore à chaque action (appel de menu ou autre), swap de 2 Go...
Tu peux tout de même préciser:
- le disque n'est pas une clé USB mais un vrai disque
- avec quel OS cela rame ?
Info additionnelle : après reformatage du disque (toujours en ExFAT, vérification par les outils systèmes, reprise du chiffrement à partir d'un autre ordi, et alors que le premier quart semblait s'être déroulé convenablement en 1h30, désormais (30% du processus) c'est revenu au même délire : lenteur incroyable de l'ordi, roue de la mort multicolore à chaque action (appel de menu ou autre), swap de 2 Go...
Tu peux tout de même préciser: - le disque n'est pas une clé USB mais un vrai disque - avec quel OS cela rame ?
pehache
Le 28/09/2020 à 16:01, Gerald a écrit :
Par ailleurs, pourquoi crées-tu une image chiffrée plutôt que de chiffrer directement le disque ? Non seulement ça permettrait d'utiliser l'option "Quick format", mais tu éviterais l'empilement de 2 accès exFAT (potentiellement pénalisants sous Linux suivant les cas).
Là, c'est consécutif à 1/ d'une part *leur conseil* (quand on crée la partition chiffrée, le message est explicite) de préférer cette option si on est un utilisateur novice. Ils disent que le chiffrage du volume entier est possible mais pourrait le rendre définitivement inaccessible en cas de fausse manip.
mmhhh, pas vu ça. Et la seule fausse manipe que je vois serait de répondre "OK" quand Windows ou macOS dit que le disque qu'on vient de brancher est illisible (forcément) et demande si on veut le formater.
Donc pour l'instant : "UN BILAN MITIGÉ" :-) (je pique à Alexandre Astier avec son sketch sur la physique quantique). - déjà l'interopérabilité des formats de disques est loin d'être "velours" - de même que l'interopérabilité logicielle, qui semble se résumer, dans ce domaine, à un seul, (Veracrypt), qui, en gros, ne répond pas à mes besoins (on s'éloigne très largement de la transparence dont j'ai l'habitude) - pour finir par le constat que cette pratique, qui me semblait naturelle, raisonnable et évidente, ne le serait pas tant que ça et en particulier pas pour vous (présents sur ce forum). Il semble que quand elle est mise en œuvre (en entreprise), ce n'est que dans le contexte d'un système, d'un parc homogène, sans interopérabilité.
C'est à dire qu'en entreprise on peut avoir des parcs hétérogènes, mais on ne passe pas son temps à déplacer les disques d'une machine à l'autre :-), donc l'interopérabilité du chiffrement n'est pas un critère. Les services IT fournissent en général des solutions de clé USB chiffrées, mais effectivement pour le coup c'est monoplateforme (Windows en général).
Le 28/09/2020 à 16:01, Gerald a écrit :
Par ailleurs, pourquoi crées-tu une image chiffrée plutôt que de
chiffrer directement le disque ? Non seulement ça permettrait d'utiliser
l'option "Quick format", mais tu éviterais l'empilement de 2 accès exFAT
(potentiellement pénalisants sous Linux suivant les cas).
Là, c'est consécutif à 1/ d'une part *leur conseil* (quand on crée la
partition chiffrée, le message est explicite) de préférer cette
option si on est un utilisateur novice. Ils disent que le chiffrage
du volume entier est possible mais pourrait le rendre définitivement
inaccessible en cas de fausse manip.
mmhhh, pas vu ça. Et la seule fausse manipe que je vois serait de
répondre "OK" quand Windows ou macOS dit que le disque qu'on vient de
brancher est illisible (forcément) et demande si on veut le formater.
Donc pour l'instant : "UN BILAN MITIGÉ" :-) (je pique à Alexandre
Astier avec son sketch sur la physique quantique).
- déjà l'interopérabilité des formats de disques est loin d'être
"velours"
- de même que l'interopérabilité logicielle, qui semble se résumer,
dans ce domaine, à un seul, (Veracrypt), qui, en gros, ne répond pas
à mes besoins (on s'éloigne très largement de la transparence dont
j'ai l'habitude)
- pour finir par le constat que cette pratique, qui me semblait
naturelle, raisonnable et évidente, ne le serait pas tant que ça et
en particulier pas pour vous (présents sur ce forum). Il semble que
quand elle est mise en œuvre (en entreprise), ce n'est que dans le
contexte d'un système, d'un parc homogène, sans interopérabilité.
C'est à dire qu'en entreprise on peut avoir des parcs hétérogènes,
mais on ne passe pas son temps à déplacer les disques d'une machine à
l'autre :-), donc l'interopérabilité du chiffrement n'est pas un
critère. Les services IT fournissent en général des solutions de clé
USB chiffrées, mais effectivement pour le coup c'est monoplateforme
(Windows en général).
Par ailleurs, pourquoi crées-tu une image chiffrée plutôt que de chiffrer directement le disque ? Non seulement ça permettrait d'utiliser l'option "Quick format", mais tu éviterais l'empilement de 2 accès exFAT (potentiellement pénalisants sous Linux suivant les cas).
Là, c'est consécutif à 1/ d'une part *leur conseil* (quand on crée la partition chiffrée, le message est explicite) de préférer cette option si on est un utilisateur novice. Ils disent que le chiffrage du volume entier est possible mais pourrait le rendre définitivement inaccessible en cas de fausse manip.
mmhhh, pas vu ça. Et la seule fausse manipe que je vois serait de répondre "OK" quand Windows ou macOS dit que le disque qu'on vient de brancher est illisible (forcément) et demande si on veut le formater.
Donc pour l'instant : "UN BILAN MITIGÉ" :-) (je pique à Alexandre Astier avec son sketch sur la physique quantique). - déjà l'interopérabilité des formats de disques est loin d'être "velours" - de même que l'interopérabilité logicielle, qui semble se résumer, dans ce domaine, à un seul, (Veracrypt), qui, en gros, ne répond pas à mes besoins (on s'éloigne très largement de la transparence dont j'ai l'habitude) - pour finir par le constat que cette pratique, qui me semblait naturelle, raisonnable et évidente, ne le serait pas tant que ça et en particulier pas pour vous (présents sur ce forum). Il semble que quand elle est mise en œuvre (en entreprise), ce n'est que dans le contexte d'un système, d'un parc homogène, sans interopérabilité.
C'est à dire qu'en entreprise on peut avoir des parcs hétérogènes, mais on ne passe pas son temps à déplacer les disques d'une machine à l'autre :-), donc l'interopérabilité du chiffrement n'est pas un critère. Les services IT fournissent en général des solutions de clé USB chiffrées, mais effectivement pour le coup c'est monoplateforme (Windows en général).
pehache
Le 28/09/2020 à 16:01, Gerald a écrit :
Le 28 septembre 2020 à 13:54, Pascal Hambourg a écrit :
Le 28/09/2020 à 13:41, pehache a écrit :
Le 28/09/2020 à 11:24, Pascal Hambourg a écrit :
Précisément. Donc quand tu as écris "le chiffrement prend une trentaine d'heures" dans ton message initial, de quelle opération parlais-tu exactement ?
Il parle de la création du volume VeraCrypt
Je confirme
En quoi cela consiste-t-il pour prendre autant de temps ? Avec cryptsetup, l'initialisation d'un conteneur chiffré se résume à écrire le superbloc LUKS. Ce qui prend le plus de temps, ce sont les calculs liés à la protection de la clé maîtresse et c'est indépendant de la taille du volume.
Ce que tu dis est plein de bon sens, mais dans le monde réel ce n'est pas le cas, ni pour moi ni pour pehache d'ailleurs, au prorata temporis (apparemment). Info additionnelle : après reformatage du disque (toujours en ExFAT, vérification par les outils systèmes, reprise du chiffrement à partir d'un autre ordi, et alors que le premier quart semblait s'être déroulé convenablement en 1h30, désormais (30% du processus) c'est revenu au même délire : lenteur incroyable de l'ordi, roue de la mort multicolore à chaque action (appel de menu ou autre), swap de 2 Go...
Ca ressemble bien à un bug de "fuite mémoire" dans VeraCrypt...
Il reste à attendre la livraison d'un nouveau disque de grande capacité pour mettre le disque lui-même hors de cause, mais je ne suis pas très optimiste. Ça ne semble pas prévu pour gérer des volumes de grande capacité.
Peut-être. Mais sur les forums VeraCrypt je vois quand même des utilisateurs chiffrer des gros volumes (plusieurs To) apparemment sans souci particulier.
Le 28/09/2020 à 16:01, Gerald a écrit :
Le 28 septembre 2020 à 13:54, Pascal Hambourg a écrit :
Le 28/09/2020 à 13:41, pehache a écrit :
Le 28/09/2020 à 11:24, Pascal Hambourg a écrit :
Précisément. Donc quand tu as écris "le chiffrement prend une
trentaine d'heures" dans ton message initial, de quelle opération
parlais-tu exactement ?
Il parle de la création du volume VeraCrypt
Je confirme
En quoi cela consiste-t-il pour prendre autant de temps ?
Avec cryptsetup, l'initialisation d'un conteneur chiffré se résume à
écrire le superbloc LUKS. Ce qui prend le plus de temps, ce sont les
calculs liés à la protection de la clé maîtresse et c'est indépendant de
la taille du volume.
Ce que tu dis est plein de bon sens, mais dans le monde réel ce n'est
pas le cas, ni pour moi ni pour pehache d'ailleurs, au prorata
temporis (apparemment).
Info additionnelle : après reformatage du disque (toujours en ExFAT,
vérification par les outils systèmes, reprise du chiffrement à partir
d'un autre ordi, et alors que le premier quart semblait s'être
déroulé convenablement en 1h30, désormais (30% du processus) c'est
revenu au même délire : lenteur incroyable de l'ordi, roue de la mort
multicolore à chaque action (appel de menu ou autre), swap de 2 Go...
Ca ressemble bien à un bug de "fuite mémoire" dans VeraCrypt...
Il reste à attendre la livraison d'un nouveau disque de grande
capacité pour mettre le disque lui-même hors de cause, mais je ne
suis pas très optimiste. Ça ne semble pas prévu pour gérer des
volumes de grande capacité.
Peut-être. Mais sur les forums VeraCrypt je vois quand même des
utilisateurs chiffrer des gros volumes (plusieurs To) apparemment sans
souci particulier.
Le 28 septembre 2020 à 13:54, Pascal Hambourg a écrit :
Le 28/09/2020 à 13:41, pehache a écrit :
Le 28/09/2020 à 11:24, Pascal Hambourg a écrit :
Précisément. Donc quand tu as écris "le chiffrement prend une trentaine d'heures" dans ton message initial, de quelle opération parlais-tu exactement ?
Il parle de la création du volume VeraCrypt
Je confirme
En quoi cela consiste-t-il pour prendre autant de temps ? Avec cryptsetup, l'initialisation d'un conteneur chiffré se résume à écrire le superbloc LUKS. Ce qui prend le plus de temps, ce sont les calculs liés à la protection de la clé maîtresse et c'est indépendant de la taille du volume.
Ce que tu dis est plein de bon sens, mais dans le monde réel ce n'est pas le cas, ni pour moi ni pour pehache d'ailleurs, au prorata temporis (apparemment). Info additionnelle : après reformatage du disque (toujours en ExFAT, vérification par les outils systèmes, reprise du chiffrement à partir d'un autre ordi, et alors que le premier quart semblait s'être déroulé convenablement en 1h30, désormais (30% du processus) c'est revenu au même délire : lenteur incroyable de l'ordi, roue de la mort multicolore à chaque action (appel de menu ou autre), swap de 2 Go...
Ca ressemble bien à un bug de "fuite mémoire" dans VeraCrypt...
Il reste à attendre la livraison d'un nouveau disque de grande capacité pour mettre le disque lui-même hors de cause, mais je ne suis pas très optimiste. Ça ne semble pas prévu pour gérer des volumes de grande capacité.
Peut-être. Mais sur les forums VeraCrypt je vois quand même des utilisateurs chiffrer des gros volumes (plusieurs To) apparemment sans souci particulier.
Pascal Hambourg
Le 28/09/2020 à 18:21, pehache a écrit :
Il parle de la création du volume VeraCrypt
En quoi cela consiste-t-il pour prendre autant de temps ? Avec cryptsetup, l'initialisation d'un conteneur chiffré se résume à écrire le superbloc LUKS. Ce qui prend le plus de temps, ce sont les calculs liés à la protection de la clé maîtresse et c'est indépendant de la taille du volume.
Ce que tu dis est plein de bon sens, mais dans le monde réel ce n'est pas le cas, ni pour moi ni pour pehache d'ailleurs, au prorata temporis (apparemment).
En quoi le monde de Veracrypt sous MacOS est-il plus réel que le monde de cryptsetup sous Linux ?
Info additionnelle : après reformatage du disque (toujours en ExFAT, vérification par les outils systèmes, reprise du chiffrement à partir d'un autre ordi,
D'après pehache c'est du remplissage, pas du chiffrement.
et alors que le premier quart semblait s'être
déroulé convenablement en 1h30, désormais (30% du processus) c'est revenu au même délire : lenteur incroyable de l'ordi, roue de la mort multicolore à chaque action (appel de menu ou autre), swap de 2 Go...
Ca ressemble bien à un bug de "fuite mémoire" dans VeraCrypt...
Pas forcément. Ça peut être la gestion de la mémoire et du cache disque du système lui-même qui réagit de façon non optimale à l'écriture continue d'un énorme fichier. J'ai déjà vu ça dans des situations n'ayant rien à voir avec Veracrypt. Il faudrait vérifier l'occupation mémoire de Veracrypt.
Le 28/09/2020 à 18:21, pehache a écrit :
Il parle de la création du volume VeraCrypt
En quoi cela consiste-t-il pour prendre autant de temps ?
Avec cryptsetup, l'initialisation d'un conteneur chiffré se résume à
écrire le superbloc LUKS. Ce qui prend le plus de temps, ce sont les
calculs liés à la protection de la clé maîtresse et c'est indépendant
de la taille du volume.
Ce que tu dis est plein de bon sens, mais dans le monde réel ce n'est
pas le cas, ni pour moi ni pour pehache d'ailleurs, au prorata
temporis (apparemment).
En quoi le monde de Veracrypt sous MacOS est-il plus réel que le monde
de cryptsetup sous Linux ?
Info additionnelle : après reformatage du disque (toujours en ExFAT,
vérification par les outils systèmes, reprise du chiffrement à partir
d'un autre ordi,
D'après pehache c'est du remplissage, pas du chiffrement.
et alors que le premier quart semblait s'être
déroulé convenablement en 1h30, désormais (30% du processus) c'est
revenu au même délire : lenteur incroyable de l'ordi, roue de la mort
multicolore à chaque action (appel de menu ou autre), swap de 2 Go...
Ca ressemble bien à un bug de "fuite mémoire" dans VeraCrypt...
Pas forcément. Ça peut être la gestion de la mémoire et du cache disque
du système lui-même qui réagit de façon non optimale à l'écriture
continue d'un énorme fichier. J'ai déjà vu ça dans des situations
n'ayant rien à voir avec Veracrypt. Il faudrait vérifier l'occupation
mémoire de Veracrypt.
En quoi cela consiste-t-il pour prendre autant de temps ? Avec cryptsetup, l'initialisation d'un conteneur chiffré se résume à écrire le superbloc LUKS. Ce qui prend le plus de temps, ce sont les calculs liés à la protection de la clé maîtresse et c'est indépendant de la taille du volume.
Ce que tu dis est plein de bon sens, mais dans le monde réel ce n'est pas le cas, ni pour moi ni pour pehache d'ailleurs, au prorata temporis (apparemment).
En quoi le monde de Veracrypt sous MacOS est-il plus réel que le monde de cryptsetup sous Linux ?
Info additionnelle : après reformatage du disque (toujours en ExFAT, vérification par les outils systèmes, reprise du chiffrement à partir d'un autre ordi,
D'après pehache c'est du remplissage, pas du chiffrement.
et alors que le premier quart semblait s'être
déroulé convenablement en 1h30, désormais (30% du processus) c'est revenu au même délire : lenteur incroyable de l'ordi, roue de la mort multicolore à chaque action (appel de menu ou autre), swap de 2 Go...
Ca ressemble bien à un bug de "fuite mémoire" dans VeraCrypt...
Pas forcément. Ça peut être la gestion de la mémoire et du cache disque du système lui-même qui réagit de façon non optimale à l'écriture continue d'un énorme fichier. J'ai déjà vu ça dans des situations n'ayant rien à voir avec Veracrypt. Il faudrait vérifier l'occupation mémoire de Veracrypt.
Pascal Hambourg
Le 28/09/2020 à 16:29, denis.paris a écrit :
Le 28/09/2020 à 11:38, Pascal Hambourg a écrit :
Le pilote NTFS natif du noyau Linux prend en charge la lecture, ainsi que l'écriture de façon très limitée (modification du contenu d'un fichier existant sans changer sa taille) depuis longtemps. Mais Debian a désactivé l'écriture dans le noyau 4.9 de Stretch/9 et désactivé complètement le pilote dans le noyau 4.19 de Buster/10.
OK, mais pourtant j'ai un noyau 4.15 (xubuntu 18.04) [...] Et je n'ai strictement rien rajouté comme package pour accéder à la partition NTFS, qui est accessible parfaitement en écriture.
Parce que ta distribution a installé ntfs-3g qui prend le pas sur le pilote natif du noyau et gère complètement l'écriture.
Le 28/09/2020 à 16:29, denis.paris a écrit :
Le 28/09/2020 à 11:38, Pascal Hambourg a écrit :
Le pilote NTFS natif du noyau Linux prend en charge la lecture, ainsi
que l'écriture de façon très limitée (modification du contenu d'un
fichier existant sans changer sa taille) depuis longtemps. Mais Debian
a désactivé l'écriture dans le noyau 4.9 de Stretch/9 et désactivé
complètement le pilote dans le noyau 4.19 de Buster/10.
OK, mais pourtant j'ai un noyau 4.15 (xubuntu 18.04) [...]
Et je n'ai strictement rien rajouté comme package pour accéder à la
partition NTFS, qui est accessible parfaitement en écriture.
Parce que ta distribution a installé ntfs-3g qui prend le pas sur le
pilote natif du noyau et gère complètement l'écriture.
Le pilote NTFS natif du noyau Linux prend en charge la lecture, ainsi que l'écriture de façon très limitée (modification du contenu d'un fichier existant sans changer sa taille) depuis longtemps. Mais Debian a désactivé l'écriture dans le noyau 4.9 de Stretch/9 et désactivé complètement le pilote dans le noyau 4.19 de Buster/10.
OK, mais pourtant j'ai un noyau 4.15 (xubuntu 18.04) [...] Et je n'ai strictement rien rajouté comme package pour accéder à la partition NTFS, qui est accessible parfaitement en écriture.
Parce que ta distribution a installé ntfs-3g qui prend le pas sur le pilote natif du noyau et gère complètement l'écriture.
pehache
Le 28/09/2020 à 18:55, Pascal Hambourg a écrit :
et alors que le premier quart semblait s'être
déroulé convenablement en 1h30, désormais (30% du processus) c'est revenu au même délire : lenteur incroyable de l'ordi, roue de la mort multicolore à chaque action (appel de menu ou autre), swap de 2 Go...
Ca ressemble bien à un bug de "fuite mémoire" dans VeraCrypt...
Pas forcément. Ça peut être la gestion de la mémoire et du cache disque du système lui-même qui réagit de façon non optimale à l'écriture continue d'un énorme fichier. J'ai déjà vu ça dans des situations n'ayant rien à voir avec Veracrypt. Il faudrait vérifier l'occupation mémoire de Veracrypt.
Oui oui, là ce n'est pas "de façon non optimale", c'est "n'importe comment". Si l'OS met en cache d'écriture un volume de données qui le conduit à swapper, c'est de l'ordre du défaut de conception ou du bug. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes." (ST sur fr.bio.medecine) "Je suis ATARIste, et j'ai bien l'intention que l'on me respecte ici." (FLC sur fr.comp.sys.atari)
Le 28/09/2020 à 18:55, Pascal Hambourg a écrit :
et alors que le premier quart semblait s'être
déroulé convenablement en 1h30, désormais (30% du processus) c'est
revenu au même délire : lenteur incroyable de l'ordi, roue de la mort
multicolore à chaque action (appel de menu ou autre), swap de 2 Go...
Ca ressemble bien à un bug de "fuite mémoire" dans VeraCrypt...
Pas forcément. Ça peut être la gestion de la mémoire et du cache disque
du système lui-même qui réagit de façon non optimale à l'écriture
continue d'un énorme fichier. J'ai déjà vu ça dans des situations
n'ayant rien à voir avec Veracrypt. Il faudrait vérifier l'occupation
mémoire de Veracrypt.
Oui oui, là ce n'est pas "de façon non optimale", c'est "n'importe
comment". Si l'OS met en cache d'écriture un volume de données qui le
conduit à swapper, c'est de l'ordre du défaut de conception ou du bug.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes." (ST sur fr.bio.medecine)
"Je suis ATARIste, et j'ai bien l'intention que l'on me respecte ici."
(FLC sur fr.comp.sys.atari)
déroulé convenablement en 1h30, désormais (30% du processus) c'est revenu au même délire : lenteur incroyable de l'ordi, roue de la mort multicolore à chaque action (appel de menu ou autre), swap de 2 Go...
Ca ressemble bien à un bug de "fuite mémoire" dans VeraCrypt...
Pas forcément. Ça peut être la gestion de la mémoire et du cache disque du système lui-même qui réagit de façon non optimale à l'écriture continue d'un énorme fichier. J'ai déjà vu ça dans des situations n'ayant rien à voir avec Veracrypt. Il faudrait vérifier l'occupation mémoire de Veracrypt.
Oui oui, là ce n'est pas "de façon non optimale", c'est "n'importe comment". Si l'OS met en cache d'écriture un volume de données qui le conduit à swapper, c'est de l'ordre du défaut de conception ou du bug. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes." (ST sur fr.bio.medecine) "Je suis ATARIste, et j'ai bien l'intention que l'on me respecte ici." (FLC sur fr.comp.sys.atari)
Gerald
Le 28 septembre 2020 à 16:37, denis.paris a écrit :
Je suggère l'acquisition d'un socle pouvant accueillir 2 DD, cela simplifiera les sauvegardes par duplication disque à disque, d'une manière autonome sans avoir besoin d’allumer un ordi (la nuit par exemple).
Carbon Copy Cloner est "dressé" à lancer les sauvegardes au rebranchement du disque de destination, et fait sa petite salade en arrière-plan de manière tout à fait indolore, puis démonte le disque quand il a fini. Je vérifie juste, par principe que CCC UserAgent a bien signalé "sauvegarde réussie" et je remise dans le sac. Tiens, je le croyais multi-plateforme CCC. Dommage, il fait bien son boulot. D'autres le font aussi, évidemment. De toute manière, je ne suis pas sûr que ta suggestion pourrait être fonctionnelle sur des volumes cryptés mac et formatés mac. Il faut un système MacOS actif pour qu'ils soient lisibles (c'est même le principe !). AFAIK, évidememnt.. -- Gerald
Le 28 septembre 2020 à 16:37, denis.paris a écrit :
Je suggère l'acquisition d'un socle pouvant accueillir 2 DD, cela
simplifiera les sauvegardes par duplication disque à disque, d'une
manière autonome sans avoir besoin d’allumer un ordi (la nuit par exemple).
Carbon Copy Cloner est "dressé" à lancer les sauvegardes au
rebranchement du disque de destination, et fait sa petite salade en
arrière-plan de manière tout à fait indolore, puis démonte le disque
quand il a fini. Je vérifie juste, par principe que CCC UserAgent a
bien signalé "sauvegarde réussie" et je remise dans le sac.
Tiens, je le croyais multi-plateforme CCC. Dommage, il fait bien son
boulot. D'autres le font aussi, évidemment.
De toute manière, je ne suis pas sûr que ta suggestion pourrait être
fonctionnelle sur des volumes cryptés mac et formatés mac. Il faut un
système MacOS actif pour qu'ils soient lisibles (c'est même le
principe !). AFAIK, évidememnt..
Le 28 septembre 2020 à 16:37, denis.paris a écrit :
Je suggère l'acquisition d'un socle pouvant accueillir 2 DD, cela simplifiera les sauvegardes par duplication disque à disque, d'une manière autonome sans avoir besoin d’allumer un ordi (la nuit par exemple).
Carbon Copy Cloner est "dressé" à lancer les sauvegardes au rebranchement du disque de destination, et fait sa petite salade en arrière-plan de manière tout à fait indolore, puis démonte le disque quand il a fini. Je vérifie juste, par principe que CCC UserAgent a bien signalé "sauvegarde réussie" et je remise dans le sac. Tiens, je le croyais multi-plateforme CCC. Dommage, il fait bien son boulot. D'autres le font aussi, évidemment. De toute manière, je ne suis pas sûr que ta suggestion pourrait être fonctionnelle sur des volumes cryptés mac et formatés mac. Il faut un système MacOS actif pour qu'ils soient lisibles (c'est même le principe !). AFAIK, évidememnt.. -- Gerald
Gerald
Le 28 septembre 2020 à 16:43, denis.paris a écrit :
Tu peux tout de même préciser: - le disque n'est pas une clé USB mais un vrai disque
WD "My Book" de 3 To. Pas très jeune (volumineux) mais fonctionne bien, vérifié OK avec les outils proposés par le système (SOS disque dans MacOS), actuellement en train de "manger" une copie *non cryptée* de mon disque d'archives, sans le moindre problème (copie de prudence dans l'attente de la réception du nouveau disque).
- avec quel OS cela rame ?
MacOS Catalina 10.15.7 sur un Mac mini 2018, intel Core i5 à 6 coeurs. On pourrait tenir pour possible que ce soit la version mac de Veracrypt qui est en cause : en dehors de problèmes de portabilité inter-plateforme comme celle qui me soucie, il n'y a en effet *aucune* raison objective, pour quelqu'un sous MacOS, d'utiliser Veracrypt alors que Filevault est intégré au système. Veracrypt doit être peu utilisé, peu surveillé dans cet environnement, et peut-être encore moins sur de gros volumes. -- Gerald
Le 28 septembre 2020 à 16:43, denis.paris a écrit :
Tu peux tout de même préciser:
- le disque n'est pas une clé USB mais un vrai disque
WD "My Book" de 3 To. Pas très jeune (volumineux) mais fonctionne
bien, vérifié OK avec les outils proposés par le système (SOS disque
dans MacOS), actuellement en train de "manger" une copie *non
cryptée* de mon disque d'archives, sans le moindre problème (copie de
prudence dans l'attente de la réception du nouveau disque).
- avec quel OS cela rame ?
MacOS Catalina 10.15.7 sur un Mac mini 2018, intel Core i5 à 6 coeurs.
On pourrait tenir pour possible que ce soit la version mac de
Veracrypt qui est en cause : en dehors de problèmes de portabilité
inter-plateforme comme celle qui me soucie, il n'y a en effet
*aucune* raison objective, pour quelqu'un sous MacOS, d'utiliser
Veracrypt alors que Filevault est intégré au système. Veracrypt doit
être peu utilisé, peu surveillé dans cet environnement, et peut-être
encore moins sur de gros volumes.
Le 28 septembre 2020 à 16:43, denis.paris a écrit :
Tu peux tout de même préciser: - le disque n'est pas une clé USB mais un vrai disque
WD "My Book" de 3 To. Pas très jeune (volumineux) mais fonctionne bien, vérifié OK avec les outils proposés par le système (SOS disque dans MacOS), actuellement en train de "manger" une copie *non cryptée* de mon disque d'archives, sans le moindre problème (copie de prudence dans l'attente de la réception du nouveau disque).
- avec quel OS cela rame ?
MacOS Catalina 10.15.7 sur un Mac mini 2018, intel Core i5 à 6 coeurs. On pourrait tenir pour possible que ce soit la version mac de Veracrypt qui est en cause : en dehors de problèmes de portabilité inter-plateforme comme celle qui me soucie, il n'y a en effet *aucune* raison objective, pour quelqu'un sous MacOS, d'utiliser Veracrypt alors que Filevault est intégré au système. Veracrypt doit être peu utilisé, peu surveillé dans cet environnement, et peut-être encore moins sur de gros volumes. -- Gerald
Gerald
Le 28 septembre 2020 à 18:19, pehache a écrit :
C'est à dire qu'en entreprise on peut avoir des parcs hétérogènes, mais on ne passe pas son temps à déplacer les disques d'une machine à l'autre :-)
ARF ! C'est pamafôt m'sieu ! "avant" on était tous monoplateformes. C'est les conjoints qui on mis le b..d.l ! Pour le déplacement des disques c'est de simple logique, puisqu'il s'agit là de copies distantes dont on souhaiterait (donc) qu'elles soient *aussi* fonctionnelles pour le "distant" (sous Windows). L'habitude est de procéder à un simple échange entre disques A et B de sauvegarde, quand on se voit, le disque source ne quittant pas le bureau. -- Gerald
Le 28 septembre 2020 à 18:19, pehache a écrit :
C'est à dire qu'en entreprise on peut avoir des parcs hétérogènes,
mais on ne passe pas son temps à déplacer les disques d'une machine à
l'autre :-)
ARF ! C'est pamafôt m'sieu ! "avant" on était tous monoplateformes.
C'est les conjoints qui on mis le b..d.l ! Pour le déplacement des
disques c'est de simple logique, puisqu'il s'agit là de copies
distantes dont on souhaiterait (donc) qu'elles soient *aussi*
fonctionnelles pour le "distant" (sous Windows). L'habitude est de
procéder à un simple échange entre disques A et B de sauvegarde,
quand on se voit, le disque source ne quittant pas le bureau.
C'est à dire qu'en entreprise on peut avoir des parcs hétérogènes, mais on ne passe pas son temps à déplacer les disques d'une machine à l'autre :-)
ARF ! C'est pamafôt m'sieu ! "avant" on était tous monoplateformes. C'est les conjoints qui on mis le b..d.l ! Pour le déplacement des disques c'est de simple logique, puisqu'il s'agit là de copies distantes dont on souhaiterait (donc) qu'elles soient *aussi* fonctionnelles pour le "distant" (sous Windows). L'habitude est de procéder à un simple échange entre disques A et B de sauvegarde, quand on se voit, le disque source ne quittant pas le bureau. -- Gerald
Pascal Hambourg
Le 28/09/2020 à 20:15, pehache a écrit :
Le 28/09/2020 à 18:55, Pascal Hambourg a écrit :
Pas forcément. Ça peut être la gestion de la mémoire et du cache disque du système lui-même qui réagit de façon non optimale à l'écriture continue d'un énorme fichier. J'ai déjà vu ça dans des situations n'ayant rien à voir avec Veracrypt. Il faudrait vérifier l'occupation mémoire de Veracrypt.
Oui oui, là ce n'est pas "de façon non optimale", c'est "n'importe comment". Si l'OS met en cache d'écriture un volume de données qui le conduit à swapper, c'est de l'ordre du défaut de conception ou du bug.
Ça dépend des priorités.
Le 28/09/2020 à 20:15, pehache a écrit :
Le 28/09/2020 à 18:55, Pascal Hambourg a écrit :
Pas forcément. Ça peut être la gestion de la mémoire et du cache
disque du système lui-même qui réagit de façon non optimale à
l'écriture continue d'un énorme fichier. J'ai déjà vu ça dans des
situations n'ayant rien à voir avec Veracrypt. Il faudrait vérifier
l'occupation mémoire de Veracrypt.
Oui oui, là ce n'est pas "de façon non optimale", c'est "n'importe
comment". Si l'OS met en cache d'écriture un volume de données qui le
conduit à swapper, c'est de l'ordre du défaut de conception ou du bug.
Pas forcément. Ça peut être la gestion de la mémoire et du cache disque du système lui-même qui réagit de façon non optimale à l'écriture continue d'un énorme fichier. J'ai déjà vu ça dans des situations n'ayant rien à voir avec Veracrypt. Il faudrait vérifier l'occupation mémoire de Veracrypt.
Oui oui, là ce n'est pas "de façon non optimale", c'est "n'importe comment". Si l'OS met en cache d'écriture un volume de données qui le conduit à swapper, c'est de l'ordre du défaut de conception ou du bug.
