Apple Core Storage et ses principes d'organisation des données. Défis possibles en matière de récupération des données
Les bases d'Apple Core Storage
Apparu pour la première fois dans macOS 10.7 Lion, le Core Storage a été l’un des composants clés du système de gestion de données de Mac jusqu’à macOS 10.13 High Sierra. Il s’agit essentiellement d’une implémentation propriétaire d’Apple d’un gestionnaire de volume logique – tout comme la LVM Linux, il agit comme une couche de virtualisation entre le schéma de partitionnement appliqué au stockage physique et les systèmes de fichiers avec lesquels ses volumes sont formatés.
Le modèle de base implique qu’un schéma de partitionnement donne certains paramètres logiques au lecteur physique et établit certaines limites fixes entre les « régions » qui s’y trouvent (appelées partitions) afin que le système d’exploitation puisse gérer les informations sur chacune des régions indépendamment et les présenter à l’utilisateur sous forme de disques logiques séparés. Ensuite, un système de fichiers peut être écrit sur chacune des partitions dont les structures définissent la façon dont les morceaux de données sont effectivement organisés sur le lecteur.
En revanche, un gestionnaire de volume logique permet une relation beaucoup plus souple entre les lecteurs et les volumes que celle offerte par les schémas de partitionnement classiques : les partitions peuvent être allouées dynamiquement par le système tandis qu‘un seul volume peut couvrir plus d’un périphérique de stockage physique.
Au départ, le Core Storage a servi de base à FileVault 2 – la technologie qui a apporté aux Macs de Lion des capacités de cryptage natif sur disque complet. Dans Mountain Lion, la possibilité d’augmenter la capacité d’un seul volume au-delà d’un lecteur physique a étendu l’utilisation du Core Storage pour la configuration Fusion Drive – une combinaison d’un disque dur et d’un lecteur à semi-conducteurs traités comme un seul élément logique.
Comment les données sont-elles organisées par Core Storage ?
La structure du Core Storage est assez similaire à celle de Linux LVM : elle se compose également de quatre niveaux principaux, bien que ces derniers ne coïncident pas complètement – un ou plusieurs volumes physiques sont combinés en un groupe de volumes logiques dans lequel des volumes logiques sont créés et qui peut exporter une ou plusieurs familles de volumes :
- Comme dans la LVM Linux, un Volume Physique (PV) est le composant le plus basique, généralement un véritable périphérique de stockage physique (par exemple, un disque dur ou un SSD), mais il peut aussi s’agir d’une image lecteur ou d’un ensemble de disques qui constituent un système RAID. Cependant, pour devenir un PV, un stockage doit être partitionné selon le schéma de partitionnement GPT (GUID Partition Table) et obtenir son propre identifiant appelé GUID. De plus, chacun d’entre eux conserve certaines informations sur le groupe de volumes logiques auquel il appartient.
- Un groupe de volumes logiques (LVG) est l’équivalent d’un groupe de volumes dans LVM qui englobe un ou plusieurs volumes physiques formant un seul pool de stockage pour les volumes logiques. En règle générale, un volume logique est établi avec la capacité totale de tous les volumes physiques.
- Un volume logique (LV) est un dispositif de stockage virtuel au sein d’un groupe de volumes logiques qui reçoit un système de fichiers (HFS+) et est monté. Les données d’un volume logique sont organisées comme celles d’un volume traditionnel de manière à pouvoir être facilement accessibles et lues.
- Une famille de volumes logiques (LVF) est un nouveau concept introduit par Apple, elle conserve diverses métadonnées relatives aux volumes logiques constituant un groupe de volumes logiques ainsi que l’ensemble des propriétés relatives à leur cryptage. Toutes les propriétés spécifiées sont héritées par chacun des LV.
Étant capable d’effectuer des opérations d’allocation de stockage en arrière-plan, le Core Storage est utilisé pour faciliter le processus de cryptage de disque effectué par FileVault 2. Auparavant, FileVault stockait un système de fichiers cryptés dans des fichiers ordinaires, mais la technologie basée sur les fichiers était loin d’être parfaite, surtout lorsque le volume entier devait être crypté. Le stockage central permet de chiffrer les données d’un volume au niveau des blocs : il crée des volumes logiques pour les données chiffrées de l’utilisateur et du système et déplace des blocs dans et hors d’une partition chiffrée. De cette façon, lorsqu’un volume crypté est déverrouillé, un nouveau volume logique est créé, qui contient l’ensemble du système de fichiers crypté et de l’espace non alloué sous la forme d’un bloc. Une configuration typique de FileVault 2 se présente comme suit :
- /dev/disk0 – un système de stockage physique avec plusieurs volumes.
- /dev/disk0s3 – un volume physique sur disk0s3, dont le contenu est crypté et le volume est inclus dans le groupe de volumes logiques de stockage de base.
- /dev/disk1 – un volume logique dans un groupe de volumes logiques qui est le point de départ pour le décryptage du contenu de disk0s3.
Deuxièmement, le stockage central est devenu le principal mécanisme permettant d’automatiser le processus de distribution des données entre les deux composants d’un lecteur de fusion, qui a généralement la composition suivante :
- dev/disk0 – un lecteur physique à semi-conducteurs qui fait partie d’un Core Storage LVG.
- dev/disk1 – un lecteur de disque dur physique faisant partie d’un Core Storage LVG.
- dev/disk2 – un volume logique qui se compose du disk0 et du disk1.
Dans cette configuration, le disk0 est défini comme étant le périphérique principal d’un groupe de volumes logiques. Par conséquent, le système lui donne la priorité pour le stockage des fichiers, de sorte que ceux qui sont fréquemment utilisés sont déplacés par blocs de 128 Ko vers le stockage SSD plus rapide et vice versa. La migration des données est effectuée par quatre appels principaux de stockage de base : RdChunkCS, WrChunkCS, WrBgMigCS et RdBgMigrCs. L’utilisateur obtient ainsi un système optimisé qui combine les performances de la mémoire flash et la capacité de la mémoire magnétique.
Avantages et inconvénients de la mémoire centrale
Le Core Storage est un format de volume fiable et performant. Il constitue la base de Fusion Drive et de sa migration intelligente des données, sans parler des transformations en place nécessaires à la mise en œuvre du cryptage de disque FileVault 2. Cependant, cette technologie présente plusieurs lacunes importantes dont il faut être conscient :
- Contrairement à la LVM de Linux, le stockage central ne permet pas le Thin Provisioning.
- L’extension de capacité en temps réel n’est pas disponible dans le Core Storage contrairement à la LVM, il est donc impossible d’étendre le pool de stockage au fur et à mesure que le stockage s’étend. En fait, la commande diskutil offre la possibilité de redimensionner les groupes et les volumes du Core Storage, mais elle n’est pas vraiment bien documentée et comporte un risque inhérent de perte totale de données.
- Disk Utility n’a pas la capacité de manipuler la disposition du Core Storage – on ne peut pas créer ou supprimer des volumes logiques, des groupes de visualisation ou des familles sans utiliser le terminal.
- Le Core Storage ne prend pas en charge le nouveau système de fichiers APFS d’Apple : après l’installation de macOS High Sierra et plus tard (macOS Mojave pour Fusion Drive), le groupe de volumes logiques sera converti en un conteneur APFS spécial.
- La technologie n’offre aucune option de tolérance aux pannes. De plus, chaque lecteur appartenant au Core Storage fait partie d’un ensemble unique et ne peut être accédé séparément en cas de déconnexion ou de défaillance de l’un des disques membres. Toutes les données conservées par le système défectueux sont inévitablement perdues.
Possibilité de récupération de données
Pour s’assurer que le Core Storage est bien activé sur les lecteurs problématiques, on peut vérifier la vue hexadécimale de la plus grande partition de chaque disque : le « numéro de signature » 0x4353 doit être présent en position 0x58.
Toutes les données utilisateur que le Core Storage contient sont réparties sur les lecteurs composants. De plus, des métadonnées cryptées spéciales à la fin de chaque stockage sont nécessaires pour son interprétation correcte. Par conséquent, la présence de tous les composants est absolument nécessaire pour la récupération des données – la défaillance totale d’au moins un d’entre eux entraîne une perte de données irréversible. De plus, si les métadonnées cryptées ou le GUID de stockage sont gravement endommagés, il est impossible de récupérer des fichiers intacts. Parmi les autres problèmes potentiels, on peut citer.
La perte d’une table de partition sur l’un des disques
Le stockage, dans ce cas, peut être ouvert si toutes les partitions sont définies manuellement : le secteur de départ et la taille de la partition en secteurs doivent être spécifiés correctement.
Problèmes liés au cryptage du stockage
Lorsque le cryptage intégral du disque est activé sur Mac, une clé de cryptage de stockage spéciale est générée et écrite dans la zone des métadonnées ou dans un fichier spécial sur la partition de configuration du système appelé EncryptedRoot.pllist.wipekey. Lorsque la zone de métadonnées est corrompue ou que l’accès au fichier EncryptedRoot.pllist.wipekey devient impossible, les données ne peuvent malheureusement pas être décryptées et leur récupération dépasse les limites du possible.
Dans d’autres cas, les métadonnées du stockage de base sont reconnues par Hexascan et le stockage peut être assemblé puis scanné par le programme.