Fichiers corrompus après avoir converti un volume HFS+ en APFS crypté

J'ai récemment tenté de convertir un disque dur (sans amorçage) que j'utilise pour les sauvegardes de HFS+ en APFS (crypté). J'ai commencé par convertir le disque en APFS (non crypté) :

diskutil apfs convert /Volumes/Archive

Je ne me souviens plus très bien, mais je pense avoir utilisé l'application Utilitaire de disque pour cette étape, et non la ligne de commande. L'opération s'est déroulée rapidement et avec succès. Tout va bien. Ensuite, j'ai lancé une commande pour crypter le volume :

diskutil apfs encryptVolume disk7s1 -user disk 

J'ai saisi une nouvelle clé de cryptage lorsque j'y ai été invité et j'ai procédé au lancement du processus de cryptage. J'ai certainement fait cette étape sur la ligne de commande. Je n'ai plus la sortie du terminal, mais il n'y a pas eu d'erreur et tout s'est déroulé comme prévu.

En plus de diverses copies de sauvegarde de fichiers stockés ailleurs, le disque contient une image disque formatée HFS+ (Backup.sparsebundle) qui est utilisée comme destination de sauvegarde Time Machine. J'ai remarqué que cette image disque avait été démontée lors du processus de conversion et de cryptage du disque, j'ai donc essayé de la remonter. À ma grande surprise et à ma grande inquiétude, cela a provoqué un crash brutal de MacOS et un redémarrage.

Après le redémarrage, j'ai vérifié le processus de cryptage du disque, qui semblait être toujours en cours :

Container disk7 E0...
====================================================
APFS Container Reference:     disk7
Size (Capacity Ceiling):      4000443056128 B (4.0 TB)
Minimum Size:                 2472421744640 B (2.5 TB)
Capacity In Use By Volumes:   2396837355520 B (2.4 TB) (59.9% used)
Capacity Not Allocated:       1603605700608 B (1.6 TB) (40.1% free)
|
+-< Physical Store disk6s2 D2...
|   -----------------------------------------------------------
|   APFS Physical Store Disk:   disk6s2
|   Size:                       4000443056128 B (4.0 TB)
|
+-> Volume disk7s1 B7...
    ---------------------------------------------------
    APFS Volume Disk (Role):   disk7s1 (No specific role)
    Name:                      Archive (Case-insensitive)
    Mount Point:               /Volumes/Archive
    Capacity Consumed:         2396365815808 B (2.4 TB)
    Encryption Progress:       10.0% (Unlocked)

Après avoir observé pendant un certain temps, j'ai pensé que le cryptage s'était arrêté, mais après quelques heures, il a progressé jusqu'à 11,0 %, je suppose donc qu'il crypte le disque en arrière-plan... très lentement. Une semaine plus tard, il est seulement à 32,0%. Très lent en effet.

Malheureusement, si la structure du répertoire est intacte, les fichiers sur le disque sont illisibles. Peut-être est-ce la raison pour laquelle l'image disque n'a pas été montée et a provoqué un crash dur ? Par exemple, il y a un fichier texte qui contient les journaux d'un travail rsync qui semble être corrompu. En l'ouvrant avec vim, il ne montre aucun contenu et un message d'erreur dans la barre d'état :

"/Volumes/Archive/rsync-stats.txt" [readonly][READ ERRORS] 0L, 0C

Je suis capable de visualiser le contenu (non corrompu) de certains fichiers avec iBoysoft Data Recovery.app Le programme ne récupère pas les fichiers gratuitement, contrairement à ce que dit le site Web. Certains des fichiers que j'ai pu prévisualiser avec iBoysoft il y a une semaine semblent maintenant être corrompus, même lorsqu'ils sont prévisualisés avec iBoysoft - peut-être est-ce dû au processus de cryptage ? Aucun d'entre eux n'a jamais été visualisable en dehors d'iBoysoft depuis que le disque a été crypté. Cette corruption a-t-elle été causée par un bogue dans le cryptage APFS ?

La vérification du lecteur avec diskutil ne montre aucune erreur (exécuté il y a quelques minutes) :

$ sudo diskutil verifyVolume disk7s1
Password:
Started file system verification on disk7s1 Archive
Verifying file system
Volume was successfully unmounted
Performing fsck_apfs -n -x /dev/rdisk7s1
Checking volume
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the object map
Checking the APFS volume superblock
Checking the object map
Checking the fsroot tree
Checking the snapshot metadata tree
Checking the extent ref tree
Checking the snapshots
Verifying allocated space
The volume /dev/rdisk7s1 appears to be OK
File system check exit code is 0
Restoring the original state found as mounted
Finished file system verification on disk7s1 Archive

Malheureusement, je n'ai pas de sauvegarde de mon disque dur. Et oui, c'était idiot de faire ça sans faire de sauvegarde d'abord. Ce n'est pas la fin du monde si je perds les fichiers, mais je préfère ne pas les perdre si je n'y suis pas obligé.

La machine fonctionne sous MacOS 10.13.6.

Deux questions :

1. Puis-je récupérer les données de ce disque, de préférence avec des outils d'Apple ou de la communauté open source ? Comment ?
2. Y a-t-il un moyen de dire à MacOS de donner la priorité au processus de cryptage pour accélérer les choses ? 32% au bout d'une semaine, c'est plutôt triste, et la plupart du temps, l'ordinateur est inactif, il a donc beaucoup de ressources à sa disposition.

Edit :

3. Existe-t-il des outils permettant de déterminer ce qui s'est passé lors du processus de cryptage et qui a rendu les fichiers du disque illisibles ?