NovaBACKUP 22 : préparez la migration de vos sauvegardes

Si votre PME utilise NovaBACKUP, ne déployez pas la nouvelle version sur tous vos serveurs sans vérifier vos tâches existantes. Publiée le 22 octobre 2026, NovaBACKUP 22 modifie la sauvegarde système et abandonne certaines fonctions dans sa nouvelle interface. Le journal officiel de la version 22.0.1019 précise notamment le traitement des anciennes tâches et plusieurs problèmes connus.

La bonne décision n’est donc ni de bloquer systématiquement la mise à jour, ni de l’installer partout immédiatement. Nous recommandons une migration pilote, avec un inventaire des données protégées et une restauration réellement vérifiée. Voici les changements à comprendre, les situations qui demandent une vigilance particulière et les critères pour autoriser le déploiement.

Que change NovaBACKUP 22 pour les sauvegardes d’une PME ?

NovaBACKUP 22 intègre la sauvegarde système dans une tâche appelée « Disaster Recovery », au lieu de la traiter comme un module de sauvegarde image distinct. L’éditeur annonce également une restauration vers une machine virtuelle Hyper-V et une interface locale reconstruite autour d’API, dans son annonce du 22 octobre 2026.

Pour une entreprise, l’intérêt potentiel est de simplifier les opérations de sauvegarde et les exercices de restauration. Mais nous conseillons de traiter cette évolution comme un changement de procédure, pas comme un simple rafraîchissement visuel. Votre prestataire doit pouvoir expliquer comment chaque ancienne tâche sera reprise, remplacée ou conservée.

Le premier contrôle concerne le périmètre : la documentation de migration destinée aux partenaires indique que la sauvegarde système couvre le disque Windows. Les autres volumes, par exemple D: ou E:, doivent être sélectionnés dans la même tâche pour que leurs données soient protégées.

Notre recommandation : comparez les volumes sélectionnés avant et après migration, plutôt que les seuls noms des tâches. Une tâche intitulée « serveur complet » ne constitue pas une preuve de couverture.

Votre entreprise doit-elle intervenir maintenant ?

Votre PME doit préparer une intervention si NovaBACKUP protège un serveur métier, un poste indispensable ou des machines administrées par un prestataire. Si vous n’utilisez pas ce produit, cette annonce ne justifie pas, à elle seule, de changer de solution.

Commencez par demander à votre responsable informatique un inventaire limité aux machines concernées. Évitez un audit général qui retarderait une décision simple. Pour chaque équipement, faites préciser :

• le logiciel métier ou le processus qui dépend de la machine ;
• la version de NovaBACKUP installée ;
• les tâches actives et leur calendrier ;
• les disques, répertoires et bases attendus dans les sauvegardes ;
• l’emplacement des copies et la personne capable de les restaurer ;
• la date et le résultat du dernier exercice de restauration.

Si votre interlocuteur ne peut pas fournir ces éléments, le premier chantier est la documentation de l’existant. Ne commandez pas encore une migration globale.

Pour une entreprise équipée d’un logiciel métier sur mesure, ajoutez le mainteneur applicatif à la discussion. Demandez-lui une liste des composants à retrouver après restauration : configuration, documents, traitements planifiés, accès et dépendances externes.

Les anciennes tâches ne disparaissent pas toutes à la mise à jour

Il faut distinguer suppression d’une fonction dans le nouveau parcours et arrêt des tâches existantes. Le journal des changements de NovaBACKUP 22 indique que les anciennes tâches, notamment image, Copy et Virtual Dashboard, continuent sur les ordinateurs mis à niveau et se gèrent dans l’interface historique. Une installation neuve n’inclut pas ces composants historiques.

Pour votre projet, nous recommandons donc de distinguer deux scénarios : mettre à niveau une machine existante et reconstruire son environnement de sauvegarde sur une installation neuve. Faites tester le scénario réellement prévu, sans supposer qu’ils sont équivalents.

Le cas particulier des environnements VMware

La FAQ officielle annonce le retrait du support des sauvegardes d’hôtes VMware, tout en précisant que les machines virtuelles peuvent être sauvegardées depuis leur intérieur. Faites examiner ce point avant toute migration si votre dispositif actuel s’appuie sur cette fonction.

Demandez une proposition écrite pour chaque machine virtuelle : conserver temporairement l’existant, déployer un agent dans la machine ou retenir une autre solution. Comparez ces options sur leur exploitation future, pas seulement sur leur coût d’installation. Qui surveillera les tâches ? Qui recevra les alertes ? Qui réalisera les restaurations ?

Le contrôle prioritaire : retrouver une activité, pas seulement Windows

Nous recommandons de définir le succès du pilote par un parcours métier observable. Ne vous contentez pas d’une machine qui démarre ou d’une fenêtre de connexion qui s’affiche.

Prenons un exemple fictif : une PME de maintenance utilise un serveur pour gérer ses interventions et leurs pièces jointes. Le test de migration devrait permettre à un responsable d’ouvrir une intervention récente, de consulter son historique, de retrouver une photo et de produire un document. Ce scénario donne une réponse utile au dirigeant : l’équipe pourra-t-elle travailler ?

Pour votre ERP ou CRM, choisissez également un dossier témoin représentatif. Préférez une opération courante mais complète à une succession de vérifications superficielles.

Écrire les critères avant de lancer le test

Demandez au responsable métier de fixer les éléments suivants :

• le dossier ou la transaction à retrouver ;
• la date minimale des données attendues ;
• les documents associés à ouvrir ;
• l’action à réaliser dans l’environnement de test ;
• les échanges externes à neutraliser ;
• la personne habilitée à accepter le résultat.

Pour éviter les ambiguïtés, rédigez un résultat attendu concret : « Le responsable peut ouvrir le dossier témoin et exporter son bon d’intervention », plutôt que « L’application fonctionne ».

Comment migrer NovaBACKUP 22 sans perdre ses repères ?

Nous conseillons un déploiement par lots, précédé d’un pilote et suivi d’une période d’observation. Le passage au lot suivant doit dépendre de preuves enregistrées, pas de l’absence de plainte des utilisateurs.

1. Photographier la configuration existante

Conservez les paramètres utiles avant intervention : sources, destinations, horaires, rétention, notifications et commandes personnalisées. Documentez également les moyens de récupération des accès et des clés nécessaires, dans un emplacement sécurisé accessible aux personnes autorisées.

Ajoutez une liste des tâches volontairement suspendues. Sans cette distinction, le contrôle après migration risque de confondre une suspension prévue et un oubli.

2. Choisir un pilote représentatif

Ne sélectionnez pas automatiquement la machine la moins importante. Choisissez une configuration qui représente votre parc : plusieurs volumes si vous en utilisez, une destination distante si elle fait partie de votre stratégie, et un parcours applicatif testable.

Pour une entreprise multisite, évitez aussi de commencer par le site le plus difficile à joindre. Validez d’abord la méthode dans un environnement où le support peut intervenir facilement, puis testez les particularités des autres implantations.

3. Créer la nouvelle tâche sans supprimer prématurément l’ancienne

La procédure présentée par l’éditeur prévoit de conserver les anciennes sauvegardes jusqu’à expiration de leur rétention. La documentation autorise également la coexistence des tâches image et Disaster Recovery pendant la transition.

Prévoyez cette coexistence dans votre organisation : capacité de stockage, horaires et supervision. Fixez surtout une condition de sortie. Par exemple, n’autorisez le retrait de l’ancien calendrier qu’après une sauvegarde complète exploitable, une restauration testée et l’accord du responsable métier.

4. Restaurer dans un environnement isolé

Organisez un exercice hors production. Avant le démarrage de la copie restaurée, faites vérifier les connexions susceptibles d’agir sur le réel : messagerie, paiement, synchronisation commerciale, notifications et traitements automatiques.

Chronométrez l’exercice depuis le début de l’intervention jusqu’à la validation métier. Notez séparément les temps d’attente, les manipulations et les problèmes rencontrés. Ce relevé servira à corriger la procédure et à estimer les prochains lots.

5. Observer puis généraliser

Après le pilote, contrôlez les prochaines exécutions planifiées, les notifications et la capacité à retrouver un point de restauration. Vérifiez aussi qu’une autre personne peut suivre la procédure documentée.

Le feu vert doit couvrir trois sujets : les données sélectionnées sont les bonnes, la restauration aboutit au résultat attendu et l’exploitation quotidienne reste compréhensible.

Les vérifications techniques à confier au CTO ou au prestataire

Cette liste constitue une proposition de recette technique, à adapter à votre environnement. Elle ne remplace pas les instructions de l’éditeur ni celles du mainteneur de vos applications.

Examiner les problèmes connus avant le pilote

Le changelog de la version 22.0.1019 signale notamment des avertissements ou échecs de tâches SQL Server dans certaines configurations. Pour un problème impliquant plusieurs bases, l’éditeur propose une tâche par base afin d’éviter les avertissements. Faites rapprocher ces cas de votre installation avant d’interpréter les résultats.

Notre recommandation reste de tester une restauration applicative lorsque votre configuration correspond à un problème documenté. Archivez le journal de la tâche et le résultat du test ensemble, afin que le support dispose du contexte complet.

Préparer la compatibilité avec les outils de protection

La FAQ partenaires demande de revoir les exclusions antivirus ou EDR : la nouvelle application communique avec un service Windows local, et un blocage peut empêcher les sauvegardes.

Faites valider des exceptions précises par le responsable sécurité. N’acceptez pas une désactivation générale de la protection comme solution durable. Ajoutez au pilote un contrôle des événements de blocage et de la communication avec le service.

Encadrer les nouvelles automatisations

La présentation des nouveautés met en avant les API de l’agent local. Si votre équipe souhaite les exploiter, commencez par une intégration de consultation, par exemple la remontée du statut dans votre supervision.

Avant d’autoriser des actions automatisées, demandez une revue des droits, des accès réseau, de la journalisation et des conditions d’échec. Évitez d’ajouter simultanément une migration de version et une automatisation complexe : séparez les deux changements pour faciliter le diagnostic.

Quel budget prévoir pour cette migration ?

Demandez un chiffrage par livrable plutôt qu’un prix forfaitaire « par serveur » sans détail. Pour ce projet, nous proposons de séparer quatre postes : inventaire, préparation technique, pilote de restauration et déploiement accompagné.

Le devis devrait également expliciter les hypothèses qui peuvent modifier la charge :

• nombre de configurations réellement différentes, plutôt que nombre brut de machines ;
• présence de tâches historiques à conserver ou remplacer ;
• disponibilité d’un environnement de restauration ;
• intervention du mainteneur ERP, CRM ou base de données ;
• capacité nécessaire pendant la coexistence des sauvegardes ;
• créneaux imposés et déplacements éventuels.

Pour comparer deux propositions, exigez le même résultat final : configuration documentée, restauration vérifiée, procédure remise et responsabilités définies. Une offre limitée à l’installation ne répond pas au même besoin qu’une migration validée de bout en bout.

Nous recommandons de séparer ce budget de toute refonte applicative. Si le pilote révèle une dépendance mal documentée, faites-la qualifier avant de commander un remplacement de votre logiciel métier.

La décision à prendre cette semaine

Nommez un responsable et demandez un plan de migration NovaBACKUP 22 avec un pilote daté. Le dossier de décision doit tenir sur quelques éléments : machines concernées, fonctions historiques utilisées, volumes protégés, scénario de restauration et conditions de généralisation.

Si votre prestataire ne peut pas encore démontrer la reprise du logiciel métier, autorisez la préparation et le pilote, pas le déploiement global.

Vous devez arbitrer entre mise à niveau, maintien temporaire et adaptation de vos applications ? La séance de consulting IT offerte par Novane permet de cadrer les dépendances applicatives, les questions à poser à votre prestataire et les critères de validation avant d’engager le projet.