Points clés
- NinjaOne Backup prend en charge VSS : les applications et bases de données compatibles avec le service de cliché instantané des volumes (Volume Shadow Copy Service) peuvent être sauvegardées dans un état cohérent au niveau applicatif, dans le cadre d’une sauvegarde d’image système système standard et sans configuration particulière.
- Microsoft SQL Server est compatible VSS : une sauvegarde d’image système système classique produit donc une copie exploitable et restaurable de la base de données, sans étape supplémentaire.
- Toutes les applications ne sont pas compatibles VSS. Dans ce cas, un fichier de sauvegarde généré par script (comme un fichier BAK pour SQL) vous fournit une copie propre, au format natif de l’application, à protéger en complément de votre sauvegarde d’image système système.
- Les bases de données SQL en mode de récupération Simple peuvent voir leurs journaux de transactions purgés automatiquement à chaque point de contrôle.
- Les sauvegardes d’image système peuvent être montées pour récupérer des fichiers individuels, par exemple un seul fichier de base de données, sans restaurer l’image entière.
Sauvegarder un serveur Windows est simple, jusqu’à ce qu’on s’intéresse à ce qui tourne réellement dessus. Une base de données ne reste pas immobile comme un fichier statique : elle est en pleine transaction, en pleine écriture, et change en permanence. Une sauvegarde prise au mauvais moment peut vous laisser une copie qui semble complète mais qui ne se restaurera pas correctement. NinjaOne Backup® répond à ce problème grâce à la prise en charge applicative, en s’appuyant sur le service de cliché instantané des volumes de Microsoft (VSS) pour faire une bonne partie du travail.
Le fonctionnement de la sauvegarde compatible avec les applications
VSS est un service Windows qui se coordonne avec les applications pour créer un cliché instantané, un instantané (snapshot) d’un volume à un moment précis, sans arrêter l’application ni interrompre les utilisateurs. Les applications qui prennent en charge VSS utilisent ce qu’on appelle un enregistreur VSS (VSS writer) : il indique au processus d’instantané comment figer les données de l’application dans un état cohérent avant la copie.
NinjaOne Backup dialogue directement avec ces enregistreurs VSS dans le cadre d’une sauvegarde d’image système système standard. Pour toute application compatible VSS, la sauvegarde capture donc automatiquement l’application dans un état cohérent au niveau applicatif, sans tâche de sauvegarde distincte ni script particulier. Il s’agit simplement d’une sauvegarde d’image système système classique qui protège aussi ce qui s’exécute par-dessus le système d’exploitation.
Cela dit, la prise en charge de VSS par l’outil de sauvegarde ne remplace pas les recommandations du fournisseur de l’application. Vérifiez ce qu’il préconise pour sauvegarder son produit : certaines applications imposent des exigences supplémentaires que VSS seul ne couvre pas.
SQL Server : l’exemple d’une application compatible VSS
Microsoft SQL Server est compatible VSS par défaut, grâce à son propre enregistreur VSS intégré. Une sauvegarde d’image système système standard d’un serveur exécutant SQL Server produit une copie exploitable et restaurable de la base de données, sans configuration supplémentaire.
Quelques points méritent d’être connus sur la façon dont cela se traduit en pratique :
- Troncature du journal en mode de récupération Simple : SQL Server tronque automatiquement son propre journal de transactions à chaque point de contrôle lorsque la base de données fonctionne en mode de récupération Simple.
- Troncature du journal en mode de récupération Complet : en mode Complet, le journal n’est tronqué que lorsqu’une sauvegarde du journal de transactions est exécutée. Une sauvegarde complète de la base ne suffit pas, votre sauvegarde d’image système système non plus : le journal continue donc de grossir tant que rien ne le sauvegarde réellement. Si vos bases fonctionnent en mode Complet, il vous faut un plan de maintenance SQL incluant des sauvegardes de journaux, et pas seulement des sauvegardes complètes. Cela fait partie de la routine de sauvegarde native SQL décrite plus bas.
- Récupération granulaire de fichiers : avec des sauvegardes d’image système NinjaOne stockées sur des destinations Hybride ou Cloud uniquement, vous pouvez monter l’image et extraire un fichier précis, par exemple un fichier de base de données, sans restaurer l’image complète. C’est utile quand vous n’avez besoin que d’un seul fichier et que vous ne voulez pas lancer une restauration intégrale pour l’obtenir.
Gérer les applications non compatibles VSS
Toutes les bases de données ne s’entendent pas bien avec VSS. Voici deux exemples courants.
MySQL n’est pas compatible VSS. L’approche standard utilisée par NinjaOne consiste donc à exécuter d’abord un script pour générer une sauvegarde de la base, puis à sauvegarder le fichier obtenu via une tâche de sauvegarde d’image système système ou de fichiers/dossiers.
QuickBooks Desktop n’est pas compatible VSS non plus. Une sauvegarde d’image système système standard produit malgré tout une copie cohérente en cas de panne, mais sans garantie de cohérence applicative. Nous recommandons d’utiliser l’outil de sauvegarde interne de QuickBooks, planifié de façon indépendante, pour obtenir une copie native plus fiable. NinjaOne Backup se contente alors de protéger le fichier produit par cet outil, en complément de la sauvegarde d’image système système qui couvre déjà la machine.
Le schéma est le même dans les deux cas. Lorsqu’une application ne prend pas en charge VSS, laissez l’application (ou un script) produire d’abord un fichier de sauvegarde propre au format natif, puis protégez ce fichier avec votre tâche de sauvegarde habituelle.
Le fichier BAK garde toute son utilité
Même pour SQL Server, pourtant pleinement compatible VSS, générer aussi un fichier de sauvegarde dédié a du sens. Un script exécuté en amont peut lancer la commande de sauvegarde native de SQL Server pour produire un fichier BAK, que NinjaOne Backup protège ensuite comme n’importe quel autre fichier.
Vous disposez ainsi d’une seconde option de récupération, plus souple, en parallèle de la sauvegarde d’image système système. Voici quelques raisons de mettre cela en place.
- Des restaurations plus rapides et plus ciblées : restaurer directement depuis un fichier BAK avec les outils natifs de SQL Server peut être plus rapide que restaurer une image entière juste pour récupérer la base de données.
- Des objectifs de point de récupération plus serrés : les tâches de sauvegarde et les plans de maintenance spécifiques à SQL peuvent s’exécuter plus fréquemment que votre planification de sauvegarde d’image système système. Si vous avez besoin d’une fenêtre de récupération plus courte que ce que permet une sauvegarde d’image système système quotidienne dans le cloud, lancez des sauvegardes SQL plus souvent et protégez uniquement ces fichiers avec une tâche de sauvegarde de fichiers/dossiers.
- Une sauvegarde indépendante du système d’exploitation : un fichier BAK est portable et directement compris par les outils SQL Server. Il est donc utile dans des scénarios comme la migration d’une base vers un autre serveur, et pas uniquement pour la reprise d’activité après incident.
Si vous optez pour cette approche, mieux vaut stocker vos sauvegardes et plans de maintenance spécifiques à SQL sur un volume non couvert par votre tâche de sauvegarde d’image système système, puis utiliser une tâche de sauvegarde de fichiers/dossiers distincte pour protéger uniquement ces fichiers. Les deux stratégies de sauvegarde restent ainsi bien séparées, sans se chevaucher.
L’importance de la prise en charge applicative pour la récupération
Une sauvegarde qui se termine correctement n’est pas la même chose qu’une sauvegarde qui se restaure correctement, et c’est précisément cet écart que comble la prise en charge applicative. Grâce à VSS, vos sauvegardes d’image système capturent SQL Server dans un état réellement exploitable au moment voulu, sans effort supplémentaire de votre part. Pour les applications que VSS ne couvre pas, le principe reste le même : laissez l’application produire une copie propre de ses propres données, puis sauvegardez cette copie.
Bien faire les choses, c’est la différence entre une mauvaise journée passée à tenter de récupérer une base de données qui semblait sauvegardée sans l’être, et une simple restauration de routine.
