Le Personal vDisk (PvD) permettait d’attacher un disque virtuel dédié à chaque machine virtuelle dans un environnement VDI, stockant personnalisations, applications installées par l’utilisateur et données persistantes. Avec l’abandon de cette technologie par Citrix dans les versions récentes de Virtual Apps and Desktops, la stratégie de sauvegarde et de restauration en contexte VDI a changé de nature.
Les données utilisateur ne résident plus sur un disque personnel par VM, mais sur des volumes centralisés portés par des solutions de profils comme FSLogix ou Citrix Profile Management.
A voir aussi : Les meilleures solutions pour sécuriser votre système en ligne
Fin du Personal vDisk : ce qui change pour la sauvegarde VDI
Le retrait du Personal vDisk des stacks VDI mainstream n’est pas un simple changement de composant. Il modifie l’unité logique de sauvegarde. Auparavant, chaque utilisateur disposait d’un fichier VHDX attaché à sa VM, et la sauvegarde s’organisait par machine virtuelle.
Avec la migration vers des profils utilisateurs centralisés (FSLogix, VMware DEM, Citrix Profile Management), les données persistantes se retrouvent sur un partage réseau, un file server, Azure Files ou un volume NetApp. La sauvegarde ne cible plus un vDisk par VM, mais un volume partagé qui agrège les profils de dizaines ou centaines d’utilisateurs.
A voir aussi : Types de hackers : Découvrez les différents profils en cybersécurité
Cette convergence rapproche les pratiques VDI de celles des sauvegardes de partages fichiers classiques. Le RPO et le RTO ne se définissent plus par machine virtuelle individuelle, mais par groupe d’utilisateurs et par criticité du profil (standard, VIP, applicatif critique).
Profils centralisés et stockage : où sauvegarder après le Personal vDisk
Le choix du stockage conditionne directement la granularité de restauration possible. Trois architectures reviennent dans les déploiements post-PvD.
- Un file server Windows avec des conteneurs de profils FSLogix (fichiers VHDX individuels par utilisateur sur un partage SMB), sauvegardé via un agent fichier classique ou des snapshots au niveau du volume
- Un stockage Azure Files ou Azure NetApp Files pour les environnements Azure Virtual Desktop, où la sauvegarde s’appuie sur les snapshots natifs du service cloud et une rétention configurable
- Un NAS ou un volume NetApp on-premises avec snapshots intégrés, répliqués vers un site secondaire ou un stockage objet pour la rétention longue
Dans chaque cas, la sauvegarde porte sur le conteneur de profil, pas sur la VM. La VM elle-même, si elle est non persistante (pooled desktop), ne contient rien à sauvegarder puisqu’elle est recréée à chaque session à partir d’une image de référence.
Restauration granulaire de profils VDI : fichier, dossier ou profil complet
Les solutions de sauvegarde adaptées au VDI mettent en avant depuis peu la restauration ciblée de fichiers ou de dossiers à partir de snapshots de VM ou de volumes, sans devoir restaurer l’intégralité du disque ou de la machine virtuelle.
En pratique, cette granularité permet trois niveaux de restauration distincts.
Restauration d’un fichier ou dossier isolé
Un utilisateur supprime un document dans son profil. L’administrateur monte le snapshot du conteneur VHDX correspondant et extrait le fichier ciblé. L’opération prend quelques minutes et ne perturbe pas la session active des autres utilisateurs sur le même volume.
Restauration d’un profil complet
Un profil FSLogix corrompu (registre utilisateur cassé, personnalisations incompatibles après une mise à jour applicative) nécessite le remplacement du conteneur entier. Le VHDX est restauré depuis le dernier snapshot sain, puis rattaché au partage. L’utilisateur retrouve son environnement tel qu’il était au moment du snapshot.
Restauration de masse après incident
Si le volume de stockage subit une corruption ou un chiffrement par rançongiciel, la restauration s’effectue au niveau du volume complet depuis une copie hors site ou immuable. C’est le scénario le plus critique, et celui qui justifie une copie de sauvegarde immuable stockée hors du réseau de production.
Stratégie de sauvegarde VDI : RPO, RTO et immuabilité
Définir une stratégie de sauvegarde pour un environnement VDI post-Personal vDisk revient à répondre à trois questions techniques.
La première concerne le RPO (Recovery Point Objective). Quelle quantité de données utilisateur peut-on se permettre de perdre ? Pour des profils bureautiques standards, un RPO de quelques heures est souvent acceptable. Pour des profils applicatifs critiques (données métier stockées localement dans le conteneur), un RPO plus serré impose des snapshots fréquents ou une réplication quasi temps réel.
La deuxième question porte sur le RTO (Recovery Time Objective). Un conteneur VHDX de quelques gigaoctets se restaure rapidement depuis un snapshot local. La restauration d’un volume entier hébergeant des centaines de profils prend beaucoup plus de temps, surtout si la copie vient d’un stockage objet distant.
La troisième question, devenue centrale face aux rançongiciels, est l’immuabilité des sauvegardes. Les attaquants ciblent désormais les dépôts de sauvegarde avant de déclencher le chiffrement des données de production. Une copie immuable empêche la modification ou la suppression des sauvegardes pendant une période définie, même par un compte administrateur compromis.
Pièges fréquents lors de la migration depuis un Personal vDisk
Le passage du Personal vDisk à un modèle centralisé génère des erreurs récurrentes sur le terrain.
La plus courante : continuer à sauvegarder les VM non persistantes comme si elles contenaient des données utilisateur. Cela gaspille du stockage et du temps de sauvegarde sans valeur ajoutée, puisque ces VM sont détruites et recréées en permanence.
Le deuxième piège concerne la taille des conteneurs de profils FSLogix. Sans politique de gestion, les VHDX gonflent au fil du temps (caches applicatifs, fichiers temporaires non nettoyés). Un conteneur qui dépasse plusieurs dizaines de gigaoctets ralentit la sauvegarde et la restauration. Mettre en place des règles d’exclusion dans le conteneur FSLogix (dossiers temporaires, caches navigateur) réduit la taille sauvegardée et accélère le RTO.
Le troisième point souvent négligé : ne pas tester la restauration. Un snapshot qui se crée sans erreur ne garantit pas une restauration fonctionnelle. Valider régulièrement la capacité à monter un conteneur VHDX depuis un snapshot et à rattacher le profil à une session VDI reste la seule preuve fiable que la stratégie de sauvegarde fonctionne.
La disparition du Personal vDisk a simplifié l’architecture VDI en centralisant les données utilisateur, mais elle a déplacé la responsabilité de sauvegarde vers le stockage partagé. Sauvegarder le bon périmètre, au bon rythme, avec une copie immuable testée : c’est sur ces trois axes que se joue la résilience d’un environnement VDI actuel.
