REPUBLIQUE DU CAMEROUN REPUBLIQUE DU CAMEROUN

PAIX-TRAVAIL-PATRIE PAIX-TRAVAIL-PATRIE

*************** ***************

MINISTERE DE L’ENSEIGNEMENT MINISTERE DE L’ENSEIGNEMENT

SUPERIEUR SUPERIEUR

**************** ****************

UNIVERSITE UNIVERSITE

***************** *****************

INSTITUT UNIVERSITAIRE INSTITUT UNIVERSITAIRE

FACULTE DES SCIENCE

Filière : Technologie
Option : Réseau et Télécommunication
Niveau : licence

Thème : Mise en place d’un système de

sauvegarde et de restauration des données
(Cas de l’école ABC)

Année académique : 2024/2025

 Remerciements

Nous tenons à exprimer notre profonde gratitude à toutes les personnes qui, de près ou de loin,
ont contribué à la réalisation et à l’aboutissement de ce projet.

Nos remerciements les plus sincères vont particulièrement à Monsieur [Nom du Superviseur],
notre encadrant, pour ses conseils éclairés, sa disponibilité et son accompagnement constant
tout au long de ce travail. Ses orientations méthodologiques et ses remarques constructives ont
été déterminantes pour la qualité de ce projet.

Nous remercions également l’ensemble du corps enseignant de L’INSTITUT

UNIVERSITAIRE SIANTOU pour la formation de qualité dispensée, qui a constitué la base
solide de nos connaissances en informatique et en gestion des systèmes.

Nos pensées reconnaissantes vont aussi à nos camarades de promotion, avec qui nous avons
partagé des échanges fructueux, des discussions enrichissantes et un véritable esprit d’équipe,
éléments essentiels dans la réussite de ce projet collectif.

Enfin, nous adressons nos plus vifs remerciements à nos familles et à nos amis pour leur
soutien moral constant, leurs encouragements et leur patience tout au long de cette aventure
académique.

À toutes et à tous, merci infiniment.

 Dédicace

A NOS FAMILLES
 Avant-Propos

Le présent document constitue le rapport de projet de fin d’études réalisé dans le cadre de
l’obtention de la Licence Professionnelle en Informatique en Administration réseaux sur le
thème Intitulé « Mise en place d’une solution de sauvegarde automatisée des données sous
Windows », ce projet s’inscrit dans un contexte où la protection des données numériques est
devenue un enjeu majeur pour toutes les organisations, quelles que soient leur taille et leur
activité.

L’objectif principal est de concevoir et d’implémenter une stratégie de sauvegarde fiable et

efficace des données au sein d’une structure simulée, représentée ici par une petite institution
éducative. Pour cela, nous avons retenu l’outil Cobian Reflector sous Windows, une solution
gratuite et reconnue pour sa simplicité d’utilisation et ses fonctionnalités adaptées aux petites
entreprises.

La démarche adoptée s’est articulée autour de plusieurs étapes :

 une étude des concepts et bonnes pratiques en matière de sauvegarde et de

restauration de données ;
 une analyse comparative de différentes solutions, notamment l’utilisation de scripts
sous Linux et de logiciels de sauvegarde sous Windows ;
 le choix raisonné de Cobian Reflector, jugé plus adapté à notre contexte.

La mise en œuvre a été réalisée dans un environnement de test simulé, à l’aide de machines
virtuelles, afin de reproduire un cas réel avec un serveur de fichiers et un serveur de
sauvegarde. Ce rapport détaille l’architecture proposée, les étapes d’installation et de
configuration, ainsi que les tests de sauvegarde et de restauration réalisés.

Enfin, nous partageons les résultats obtenus, les difficultés rencontrées et des pistes
d’amélioration pour des déploiements futurs. Nous espérons que ce travail reflète fidèlement
les compétences techniques et méthodologiques acquises, et qu’il pourra servir de référence
pour des projets similaires.
 Liste des acronymes et abréviations

 OS – Operating System, en français : Système d’Exploitation.

 NAS – Network Attached Storage, serveur de stockage en réseau.
 FTP – File Transfer Protocol, protocole de transfert de fichiers.
 SFTP – Secure File Transfer Protocol, version sécurisée du protocole FTP.
 PRA – Plan de Reprise d’Activité, stratégie pour redémarrer les opérations après un
sinistre.
 PCA – Plan de Continuité d’Activité, mesures garantissant la continuité des services
en cas de panne.
 VSS – Volume Shadow Copy Service, service de copie instantanée utilisé par
Windows pour sauvegarder des fichiers ouverts.
 VM – Virtual Machine, ou Machine Virtuelle (exécutée via un hyperviseur tel que
VirtualBox).
 TPE/PME – Très Petite Entreprise / Petite et Moyenne Entreprise.
 SSD – Solid State Drive, disque électronique (à semi-conducteurs) utilisé pour le
stockage.
 Résumé
Dans un contexte où la protection des données numériques est devenue essentielle pour assurer
la continuité des activités, ce projet de fin d’études a consisté à concevoir et mettre en place une
solution de sauvegarde automatisée au sein d’une institution éducative fictive. Après avoir
étudié différentes approches, dont l’utilisation de scripts sous Linux, le choix s’est porté sur
Cobian Reflector, un outil gratuit sous Windows, pour sa simplicité et ses fonctionnalités
adaptées (sauvegardes complètes et incrémentielles, planification automatique, chiffrement).
La solution a été déployée sur un serveur Windows, avec des sauvegardes quotidiennes
dirigées vers un espace de stockage distinct. Des tests de restauration ont confirmé la fiabilité
du système et sa capacité à récupérer efficacement les données en cas de suppression
accidentelle ou de panne. Ce travail démontre qu’une solution simple et peu coûteuse peut offrir
une protection efficace des données, à condition de suivre de bonnes pratiques, telles que la
vérification régulière des sauvegardes et l’externalisation des copies critiques.

Abstract
In a context where data protection has become essential to ensure business continuity, this final-year
project focused on designing and implementing an automated data backup solution within a
simulated educational institution. After evaluating several approaches, including Linux scripts, Cobian
Reflector was selected for its simplicity and suitable features (full and incremental backups, automated
scheduling, encryption). The solution was deployed on a Windows server, with daily backups stored
on a separate storage device. Restoration tests confirmed the system’s reliability and its ability to
efficiently recover data in case of accidental deletion or system failure. This work demonstrates that a
simple and cost-effective solution can provide reliable data protection, provided that best practices,
such as regular backup verification and offsite copy storage, are followed.
Table des matières
 Remerciements
 Dédicace
 Avant-Propos
 Liste des acronymes et abréviations
 Résumé
 Abstract
 Table des matières
 Liste des figures
 Liste des tables
 Introduction
 Chapitre 1 : Contexte et Problématique
o 1.1. Présentation de la structure simulée et de ses besoins
o 1.2. Problématique de la perte de données et impacts
o 1.3. Objectifs du projet de sauvegarde
 Chapitre 2 : Généralités sur la sauvegarde des données
o 2.1. Définition de la sauvegarde et importance stratégique
o 2.2. Types de sauvegardes (complète, incrémentielle, différentielle)
o 2.3. Bonnes pratiques de sauvegarde (règle du 3-2-1, etc.)
 Chapitre 3 : Étude des solutions de sauvegarde
o 3.1. Option 1 – Solution sous Linux par script (aperçu)
o 3.2. Option 2 – Logiciels de sauvegarde sous Windows
o 3.3. Choix de la solution Cobian Reflector (justification)
 Chapitre 4 : Conception et implémentation de la solution
o 4.1. Architecture de la solution au sein de l’entreprise
o 4.2. Installation de Cobian Reflector et paramétrage initial
o 4.3. Configuration des tâches de sauvegarde (sources, cibles, planification)
o 4.4. Mécanisme de restauration des données sauvegardées
o 4.5. Tests de sauvegarde et de restauration (scénarios et résultats)
 Chapitre 5 : Conclusion et perspectives
 Bibliographie
Liste des figures
1. Figure 4.1 – Architecture de la solution de sauvegarde proposée. (Schéma illustrant
le serveur principal et le serveur de sauvegarde, avec les flux de données de
sauvegarde et de restauration.)
2. Figure 4.2 – Capture d’écran de l’interface de Cobian Reflector. (Exemple de tâche
de sauvegarde planifiée dans Cobian Reflector.)

Liste des tables

1. Tableau 2.1 – Comparatif des types de sauvegardes (complète, incrémentielle,
différentielle).
2. Tableau 4.1 – Planning de sauvegarde hebdomadaire pour l’institution (exemple de
calendrier).
 Introduction

La pérennité des données d’une organisation est aujourd’hui un enjeu critique.

La perte de données, qu’elle soit causée par une panne matérielle, une erreur humaine ou une
attaque informatique peut avoir des conséquences désastreuses sur le fonctionnement et la
survie d’une entreprise. Des statistiques alarmantes montrent que « 80 % des entreprises ayant
subi une perte de données critique ferment dans les 12 mois ». Cette réalité souligne
l’importance pour toute structure, quelle que soit sa taille, de mettre en place une politique de
sauvegarde fiable et régulière de ses informations stratégiques.

L’institution éducative fictive qui sert de cadre à ce projet (que nous appellerons École ABC
par la suite) illustre bien ces enjeux. L’École ABC gère au quotidien des données variées :
informations administratives sur les étudiants, contenus pédagogiques numériques, bases de
données des résultats académiques, etc. Jusqu’à présent, aucune solution de sauvegarde
automatisée n’était en place dans cette structure simulée. Les données étaient donc exposées à
des risques de perte définitive en cas d’incident, mettant potentiellement en péril la continuité
des activités (cours, suivi des étudiants, gestion des notes, etc.).

La problématique à laquelle ce projet entend répondre est la suivante : comment

implémenter, avec des ressources limitées, une solution de sauvegarde automatique des
données de l’école, simple à gérer et capable de sécuriser l’ensemble des fichiers critiques ?

Les objectifs de notre projet tutoriel incluent donc : analyser les besoins spécifiques de
l’École ABC en matière de sauvegarde (volume de données, fréquence de modification,
contraintes horaires), étudier les différentes stratégies et outils de sauvegarde envisageables,
choisir une solution adaptée et l’implémenter dans un environnement de test, et valider la
solution par des tests de récupération de données (restauration) afin de s’assurer que, en cas de
sinistre, l’école serait en mesure de retrouver rapidement un fonctionnement normal.
 Chapitre 1 : Contexte et Problématique

La dépendance croissante aux systèmes d’information rend la protection des

données stratégiques indispensable pour toute organisation. Entre cyberattaques, pannes
matérielles et erreurs humaines, la perte de données peut entraîner des conséquences graves
: interruption des services, perte de crédibilité ou impact financier important.

Ce chapitre présente à la fois le contexte général de la sauvegarde des données

et la problématique spécifique à laquelle répond ce projet. Il met en évidence les enjeux ayant
motivé la mise en place d’une solution de sauvegarde automatisée et fiable, adaptée aux
contraintes d’une petite structure éducative simulée.

.
1.1. Présentation de la structure simulée et de ses besoins

L’École ABC est une institution éducative fictive de taille modeste, choisie
comme cas d’étude pour ce projet. On peut l’assimiler à un petit centre de formation
professionnelle, comptant par exemple une centaine d’étudiants et une dizaine de membres du
personnel administratif et enseignant.

Comme toute structure de ce type, l’école s’appuie sur un système d’information

pour gérer ses activités quotidiennes. Un serveur principal (sous Windows Server, dans notre
simulation) centralise les données essentielles : base de données des étudiants, dossiers
pédagogiques, notes de cours, résultats d’examens, documents financiers et ressources
humaines, etc. Les postes de travail des employés (secrétariat, direction, formateurs) accèdent
à ces données via le réseau local.

Les besoins en matière de sécurité des données sont critiques pour l’École ABC. Une perte de
données pourrait se traduire par l’indisponibilité des bulletins de notes, la disparition de
documents officiels, ou encore la perte d’historiques de cours, ce qui impacterait gravement la
qualité du service offert aux étudiants. De plus, certaines données (par exemple les notes ou
informations personnelles des étudiants) sont sensibles et doivent être protégées, non seulement
contre la perte, mais aussi contre les accès non autorisés. Ainsi, au-delà de la sauvegarde, des
aspects de confidentialité (chiffrement des sauvegardes) et d’intégrité sont à considérer.

Avant la mise en place de ce projet, aucun mécanisme de sauvegarde systématique n’était en

place à l’École ABC. Les quelques sauvegardes qui pouvaient exister étaient manuelles et
ponctuelles . Ce mode de fonctionnement laisse une large place à l’oubli ou à l’erreur humaine,
et n’offre aucune garantie en cas de sinistre majeur (incendie dans le local serveur, vol de
matériel, attaque par ransomware, etc.). En d’autres termes, l’école était dans une situation de
vulnérabilité importante face au risque de perte de données.

Les besoins exprimés par la direction simulée de l’École ABC pour ce projet sont donc :

 Automatisation : Mettre en place un système automatique de copie de sauvegarde, ne

nécessitant pas d’intervention humaine quotidienne.
 Régularité et fréquence : Réaliser des sauvegardes à une périodicité adaptée.
 Sécurisation : S’assurer que les données sauvegardées sont stockées en lieu sûr.
 Simplicité et coût : La solution doit être peu onéreuse (l’école disposant de ressources
limitées) et simple à utiliser, afin que le personnel non spécialiste puisse surveiller son
bon fonctionnement et restaurer les données si nécessaires.
 Fiabilité : Les sauvegardes doivent être fiables, c’est-à-dire exploitables lors des
restaurations. Il faut donc pouvoir vérifier régulièrement qu’elles s’exécutent
correctement et que les fichiers sauvegardés ne sont pas corrompus.
1.2. Problématique de la perte de données et impacts
La perte de données est très fréquente dans le monde professionnel. Ses causes peuvent
être multiples, mais qu’elle survienne suite à une panne matérielle, une erreur humaine ou une
attaque informatique, ses conséquences sont souvent dramatiques.

Plusieurs études et sources mettent en lumière l’ampleur des dégâts qu’une perte de données
peut engendrer.

Dans le contexte de l’École ABC, une perte de données pourrait signifier par exemple :

 L’impossibilité de fournir des relevés de notes ou diplômes fiables aux étudiants

 La nécessité pour les enseignants de reconstituer des ressources pédagogiques
accumulées sur plusieurs années.
 La non-disponibilités des documents importants (reçus, documents administratifs etc.)
 Une interruption temporaire des cours ou des services administratifs, le temps de rétablir
un système fonctionnel.

Outre l’impact opérationnel, la perte de données peut nuire à la réputation de l’école Dans un
monde de plus en plus tourné vers le numérique, étudiants et partenaires font confiance aux
établissements pour assurer la sécurité des informations confiées. Une défaillance sur ce plan
peut entamer la confiance et entacher l’image de marque de l’école.

Il est également important de noter que la cybersécurité est un volet lié à la problématique de
la sauvegarde. Une attaque d’un ransomware, par exemple, peut chiffrer et rendre inaccessibles
toutes les données d’un établissement. Les sauvegardes régulières apparaissent alors comme le
dernier rempart pour éviter de payer la rançon et pour restaurer les services rapidement.

Enjeux récapitulés : La problématique se résume donc à garantir la survie et la continuité

des activités de l’École ABC en cas d’incident affectant les données. Cela passe par la mise
en place d’une solution qui réponde aux questions suivantes :

 Que sauvegarder ?
 Où sauvegarder ?
 Quand et à quelle fréquence ?
 Comment restaurer ?
 Qui gère ?
 Chapitre 2 : Généralités sur la sauvegarde
des données

Ce chapitre présente les principes fondamentaux de la sauvegarde des données, indispensables pour
comprendre les choix techniques réalisés dans le cadre de ce projet. Nous commencerons par définir
la sauvegarde et rappeler son rôle crucial dans la protection des informations. Seront ensuite exposés
les principaux types de sauvegardes – complète, incrémentielle et différentielle – avec leurs avantages
et limites respectifs. Enfin, nous aborderons les bonnes pratiques généralement recommandées,
notamment la célèbre règle du 3-2-1, qui serviront de base à l’élaboration de notre propre stratégie
de sauvegarde.
2.1. Définition de la sauvegarde et importance stratégique

Une sauvegarde informatique se définit comme une copie de données existantes,

stockée de manière à pouvoir être utilisée pour restaurer ces données en cas de perte ou de
détérioration de l’original. En termes simples, sauvegarder ses données consiste à en faire un
duplicata sur un support distinct, dans le but de pouvoir les récupérer ultérieurement en cas de
besoin

L’importance stratégique de la sauvegarde vient du fait que les données sont aujourd’hui l’un
des actifs les plus précieux. Comme mentionné précédemment, leur perte peut mettre en péril
l’existence même d’une entreprise ou, dans le cas d’une école, la poursuite de sa mission
pédagogique. Les causes de perte de données sont variées : panne de disque dur, erreur humaine
(effacement accidentel), sinistre (incendie, inondation), malware (ex: ransomware), etc.

Aucune infrastructure n’est à l’abri d’un incident, aussi rare soit-il, pouvant entraîner
une perte de données. La sauvegarde est donc une forme d’assurance contre ces risques. Il est
important de souligner que la valeur d’une sauvegarde ne se révèle qu’en cas de restauration
réussie.

Une sauvegarde non vérifiée ou impossible à restaurer n’a aucune utilité. De même,
une sauvegarde trop ancienne peut ne pas contenir les données récentes indispensables. D’où
l’importance de combiner la sauvegarde avec une stratégie de fréquence (périodicité adaptée)
et de rétention (nombre de versions conservées) pour offrir un point de récupération
suffisamment proche du moment de la défaillance.

Par exemple, si l’école subit une perte de données à 17h, et que la dernière sauvegarde date de
la veille 18h, alors seules les données de la journée seront perdues, ce qui peut être acceptable
dans la plupart des cas. En revanche, si la dernière sauvegarde date de 2 mois, les conséquences
seraient bien plus graves.

SHEMA
SAUVEGARDE
S
2.2. Types de sauvegardes (complète, incrémentielle, différentielle)

Lorsqu’on parle de sauvegarde, il existe plusieurs approches pour copier les données.
Ces approches diffèrent principalement par la quantité de données copiées à chaque
sauvegarde et par le temps que prend la sauvegarde et l’espace de stockage qu’elle consomme.

Les trois types principaux sont la sauvegarde complète, la sauvegarde

incrémentielle et la sauvegarde différentielle. Chacun a ses avantages et inconvénients, et ils
sont souvent utilisés en combinaison dans une stratégie de sauvegarde optimisée.

Shema des types

de sauvegardes

La sauvegarde complète (ou full backup) consiste à copier toutes les données
choisies vers le support de sauvegarde, à chaque fois qu’elle est exécutée.
Par exemple, si l’on sauvegarde le dossier « Documents », tous les fichiers et sous-dossiers
seront copiés, même si certains n’ont pas été modifiés depuis la dernière sauvegarde.
 La sauvegarde incrémentielle ne copie que les fichiers modifiés ou ajoutés depuis
la dernière sauvegarde (qu’elle soit complète ou incrémentielle).

 Exemple :
 Lundi : on fait une sauvegarde complète.
 Mardi : on sauvegarde uniquement les fichiers changés depuis lundi.
 Mercredi : on sauvegarde seulement les changements depuis mardi, et ainsi de suite.

La sauvegarde différentielle est un compromis entre la complète et

l’incrémentielle. Elle ne copie que les fichiers modifiés depuis la dernière sauvegarde
complète, et non depuis la sauvegarde précédente.

 Exemple :
 Lundi : sauvegarde complète.
 Mardi : sauvegarde différentielle = changements depuis lundi.
 Mercredi : sauvegarde différentielle = toujours les changements depuis lundi (elle
inclut donc ceux de mardi + mercredi)

Type de Description Avantages Inconvénients

sauvegarde
Complète Copie de toutes les Simplifie la Longue et lourde : temps et
données sélectionnées. restauration : une seule espace importants à chaque
archive à restaurer. sauvegarde et Redondance
Incrémentielle Copie uniquement des Rapide et économe Restauration complexe :
données modifiées .Moins d’espace utilisé nécessite la chaîne complète (
depuis la dernière
sauvegarde
Différentielle Copie des données sauvegardes plus Taille croissante :
modifiées depuis la rapides qu’un full, mais
dernière complète plus lentes qu’un
uniquement. incrément.Restauration
simplifiée :

Tableau 2.1 : Comparatif des principales stratégies de sauvegarde de fichiers.

En réalité en pratique, les administrateurs combinent souvent ces stratégies en ce qu’on appelle un
plan de sauvegarde rotatif pour être plus efficace.
2.3. Bonnes pratiques de sauvegarde
Au fil du temps, la communauté informatique a développé un certain nombre de
bonnes pratiques pour assurer l’efficacité des sauvegardes. En voici quelques-unes qui ont
guidé notre réflexion lors de l’élaboration de la stratégie pour l’École ABC :

 Règle du 3-2-1 : C’est probablement la règle de sauvegarde la plus connue et

recommandée. Elle stipule qu’il faut conserver 3 copies des données, sur 2 types de
supports différents, dont 1 copie off-site (hors site).

En d’autres termes, en plus des données de production actives (copie primaire),

on devrait avoir au moins deux sauvegardes : par exemple une sur un disque de
sauvegarde local, et une autre sur un support différent et géographiquement éloigné
(cloud, bande magnétique stockée dans un autre bâtiment…).

Ainsi, la probabilité de perdre simultanément les 3 copies est extrêmement faible, Cette
règle couvre la plupart des scénarios de pertes de données et constitue un standard
éprouvé en matière de résilience.

Regle du
3-2-1

 Stockage sur supports multiples : Rejoignant la règle précédente, il est conseillé de

diversifier les supports. Par exemple, ne pas mettre toutes les sauvegardes sur le même
NAS unique ou le même cloud unique.

 Sauvegardes automatiques et régulières : Une sauvegarde doit être planifiée de sorte

à s’exécuter sans intervention humaine. L’erreur humaine ou l’oubli fait que si l’on
compte sur une action manuelle régulière, tôt ou tard une sauvegarde sera manquée.
 Les outils modernes, permettent d’automatiser cela de manière fiable. La
régularité (quotidienne, hebdomadaire, etc.) doit être choisie en fonction du rythme auquel les
données changent et de l’importance de ces changements.

Dans le cas de l’École ABC, une base de données de notes peut changer quotidiennement en
période d’examens, justifiant une sauvegarde quotidienne. En revanche, des archives
administratives changent peu fréquemment – une sauvegarde hebdomadaire pourrait suffire.

 Chiffrement des sauvegardes : Si les sauvegardes contiennent des données sensibles

(personnelles, confidentielles), il est prudent de les chiffrer Ainsi, en cas de vol du
support de sauvegarde les données ne seront pas lisibles sans la clé ou le mot de passe.
De nombreux logiciels de sauvegarde, y compris Cobian Backup/Reflector, offrent la
possibilité de chiffrer les fichiers de sauvegarde par mot de passe.

 Vérification et tests de restauration : Une sauvegarde n’est fiable que si on peut la

restaurer. Par conséquent, il est fortement recommandé de tester périodiquement ses
sauvegardes. Ces tests permettent de détecter des problèmes tels que des fichiers de
sauvegarde corrompus, des paramètres manquants

En appliquant ces bonnes pratiques à l’École ABC, nous allons tendre vers une solution où :

 Il existe au moins deux copies de sauvegarde en plus des données originales (l’idéal
serait une locale + une distante, même si dans notre projet l’emphase sera surtout sur
la copie locale ou sur serveur de sauvegarde dédié).
 Les sauvegardes sont automatisées quotidiennement, avec possiblement une
segmentation entre full/incrémentielle pour optimiser.
 Les sauvegardes sont chiffrées par mot de passe afin de protéger les données sensibles
(surtout si un support externe est utilisé ou en cas de stockage sur un cloud).
 Une procédure de test de restauration est prévue

Ces principes directeurs en tête, nous passons maintenant à l’étude des solutions
envisageables pour concrétiser la stratégie.
Chapitre 3 : Étude des solutions de sauvegarde

Dans ce chapitre, nous examinons les solutions techniques possibles pour répondre au besoin
de l’École ABC en matière de sauvegarde automatique.

Deux approches principales seront analysées : la première consiste à utiliser un environnement

Linux et des scripts personnalisés pour effectuer les sauvegardes, tandis que la seconde
s’appuie sur des logiciels de sauvegarde dédiés sous Windows. Cette dernière approche inclut
notamment l’étude de l’outil Cobian Reflector, qui sera la solution finalement retenue.

Chaque approche sera évaluée sur la base de critères tels que la faisabilité , le coût , les
fonctionnalités offertes ainsi que la fiabilité et la maintenabilité de la solution sur le long
terme.
3.1. Option 1 – Solution sous Linux par script (aperçu)

On peut mettre en place une sauvegarde gratuite sous Linux en utilisant des outils
déjà présents dans le système, comme tar (pour créer des archives), rsync (pour copier
seulement les fichiers modifiés) et cron (pour lancer la sauvegarde automatiquement à une
heure précise, par exemple chaque soir à 22h).

Le principe est simple : un script est écrit pour copier les dossiers à sauvegarder,
éventuellement en les compressant (pour économiser l’espace) et en les protégeant par un
mot de passe ou un chiffrement. Chaque sauvegarde est enregistrée avec la date du jour sur
un serveur Linux ou un disque externe.

Avantages de cette approche :

 Coût nul : tout est basé sur des logiciels libres déjà inclus dans Linux.
 Contrôle total : on peut personnaliser le script (par exemple, envoyer un email en cas
d’erreur, supprimer les anciennes sauvegardes automatiquement, etc.).
 Portabilité : un même script fonctionne sur presque toutes les versions de Linux et
peut même être adapté sur Windows avec des outils comme WSL ou Cygwin.
 Pas de logiciel inutile : pas besoin d’installer un programme tiers

Inconvénients :

 Demande des compétences techniques : écrire et tester un bon script prend du temps
et nécessite de connaître Linux.
 Maintenance plus difficile : si le script ne marche plus (problème de droit d’accès,
changement d’un chemin…), une personne non technique aura du mal à corriger.
 Moins convivial : pas d’interface graphique ; la restauration se fait manuellement (il
faut aller chercher l’archive et l’extraire soi-même).
 Évolutivité limitée : plus on veut ajouter des fonctions (ex. sauvegarder sur deux
serveurs, ne garder que les 10 dernières sauvegardes…), plus le script devient
complexe et difficile à maintenir.

Pour l’École ABC, l’option Linux est possible mais pas idéale : elle demande des
compétences techniques que nous n’avons pas forcément et du temps pour écrire et tester les
scripts, Nous préférons donc utiliser un outil déjà prêt qui gère automatiquement la plupart
des tâches (planification, suivi des erreurs, etc.).

Cependant, nous mentionnons cette solution pour montrer que nous connaissons les autres
options possibles. Dans une vraie entreprise avec un en Linux, rsync ou des scripts
personnalisés pourraient être une très bonne solution, car ils offrent un contrôle total.
3.2. Option 2 – Logiciels de sauvegarde sous Windows

Sous Windows, plusieurs solutions de sauvegarde existent, allant des fonctionnalités intégrées
du système d’exploitation à des logiciels tiers gratuits ou payants. Avant de zoomer sur Cobian
Reflector, qui est le choix final, passons rapidement en revue ces options pour justifier notre
sélection.

 Utilitaires natifs Windows : Windows Server inclut un outil appelé Windows Server
Backup (ou Sauvegarde Windows sur les versions client) qui permet de planifier des
sauvegardes du système ou de fichiers vers un disque local ou réseau. Cet outil a
l’avantage d’être fourni par Microsoft et bien intégré (il sait sauvegarder l’état du
système, Active Directory, etc. le cas échéant).

Cependant, cette solution présente certaines limites. Elle utilise un format propriétaire pour stocker les
sauvegardes, ce qui signifie qu’il ne s’agit pas simplement de copies directes des fichiers. Elle offre
également moins de flexibilité pour une sélection précise des données à sauvegarder et son interface
reste assez basique.

 Solutions commerciales populaires : Sur le marché, il existe de nombreux logiciels de

sauvegarde professionnels, tels que Acronis True Image (Cyber Protect), Veeam
Backup, Backup Exec, Uranium Backup, etc. Ces solutions offrent pléthore de
fonctionnalités mais elles sont souvent coûteuses et parfois complexes.

Pour une petite structure comme l’École ABC, dont les besoins restent basiques ces solutions
apparaissent surdimensionnées. L’objectif du projet étant aussi pédagogique et pratique, il a été décidé
de s’orienter vers une solution gratuite et légère, suffisamment performante pour notre cas d’usage.

 Logiciels gratuits/ouverts : Outre Cobian, qui va être détaillé juste après, il existe
d’autres logiciels gratuits comme EaseUS Todo Backup (Free), Duplicati (open-
source, orienté sauvegarde chiffrée vers cloud), FBackup, Areca Backup, etc. Chacun
a ses avantages.

Après analyse, notre choix s’est porté sur Cobian Reflector pour plusieurs raisons.
3.3. Choix de la solution Cobian Reflector (justification)
le choix s’oriente vers Cobian Reflector comme cœur de la solution de sauvegarde pour
l’École ABC, installé directement sur le serveur Windows principal de l’école. Voici un
récapitulatif des justifications, en s’appuyant sur les critères annoncés :

1. Gratuit– Cobian Reflector est le successeur de Cobian Backup, un logiciel gratuit qui
a existé depuis le début des années 2000.

2. Simplicité d’utilisation – ilo ffre une interface graphique claire et disponible en

plusieurs langues, permettant de créer et planifier des tâches de sauvegarde facilement.
Pas besoin de compétences en ligne de commande, ce qui est idéal si, par la suite, le
personnel de l’école doit être capable de comprendre et gérer l’outil.

3. Fonctionnalités– Cobian gère les sauvegardes complètes, différentielles et

incrémentielles de fichiers et dossiers. Il peut sauvegarder localement ou vers un
emplacement réseau ou FTP/SSH distant.

Il supporte la compression des sauvegardes et le chiffrement avec mot de passe. Il permet de

planifier les tâches selon quasiment n’importe quel calendrier (. Il utilise le service Volume
Shadow Copy (VSS) de Windows pour copier les fichiers même s’ils sont ouverts par un
programme, ce qui est bienpour ne pas sauter par exemple un fichier de base de données en
cours d’utilisation.

4. Communauté et support – il a une base d’utilisateurs importante. Il existe des forums,

une FAQ officielle, et de la documentation en ligne. En cas de question ou de problème,
il est probable qu’on trouve une solution existante (Cobian Backup a plus de 20 ans
d’existence accumulée).

En conclusion, Cobian Reflector apparaît comme un bon compromis pour notre projet. C’est
la solution que nous allons déployer dans le chapitre suivant.
Chapitre 4 : Conception et implémentation de la solution

Ce chapitre présente la mise en œuvre concrète de la solution de sauvegarde

retenue, à savoir l’implémentation de Cobian Reflector dans l’environnement simulé de l’École ABC. Il
débute par la présentation de l’architecture générale mise en place pour les tests, puis décrit en détail
l’installation et la configuration initiale de du logiciel. Par la suite, nous expliquons la création et la
planification des tâches de sauvegarde (choix des sources, des destinations, des horaires et du type de
sauvegarde). Nous abordons ensuite la procédure de restauration des données, illustrant les étapes à
suivre en cas de sinistre. Enfin, nous présentons les tests réalisés – simulations de perte de données et
vérification des sauvegardes planifiées – ainsi que les résultats obtenus, confirmant la fiabilité de la
solution.

4.1. Architecture de la solution au sein de l’entreprise

Afin de mettre en œuvre et valider la solution, une architecture de test a été déployée
en utilisant deux machines virtuelles (VM) via l’hyperviseur VirtualBox sur un PC de notre
choix. Cette approche VirtualBox permet de simuler de manière isolée l’environnement de
l’École ABC sans risque pour des systèmes réels, tout en reproduisant fidèlement les conditions
de fonctionnement.

 Serveur Principal (VM1) – Cette VM représente le serveur de fichiers de l’École

ABC. Pour coller au contexte, nous avons configuré VM1 avec Windows Server 2019
Standard (en version d’évaluation) et l’avons intégrée à un domaine fictif « ECOLE-
 ABC.local ». Sur ce serveur, nous avons créé un dossier partagé nommé DATA_ECOLE
contenant divers fichiers et sous-dossiers symbolisant les données critiques de l’école
(par ex. Etudiants/ pour les données étudiantes, Pedagogie/ pour les cours,
Administration/ pour les docs administratifs, etc.). C’est ce serveur qui sera la source
des données à sauvegarder. Cobian Reflector sera installé sur cette machine pour qu’il
puisse directement accéder aux données locales et les sauvegarder.

 Serveur de Sauvegarde (VM2) – Cette seconde VM sert de cible de sauvegarde. Nous

l’avons configurée avec Windows 10 (pour démontrer que la cible pourrait être un OS
client, ou ça pourrait tout aussi bien être un NAS, etc.). Sur VM2, un dossier partagé
SAUVEGARDES a été créé pour recevoir les backups. Ce dossier est exposé sur le réseau
et accessible depuis VM1 via un chemin réseau du type \\VM2\SAUVEGARDES\. VM2
simule ainsi un serveur NAS ou un disque de sauvegarde réseau distinct du serveur
principal. Dans une implémentation réelle, VM2 pourrait être remplacée par un vrai
NAS, un disque USB connecté à VM1, ou même un espace cloud monté comme lecteur
réseau. Le choix d’une VM Windows pour la cible facilite en tout cas les tests (contrôle
des fichiers reçus, etc.).

Les deux machines virtuelles sont connectées sur un réseau virtuel VirtualBox simulant le
réseau local de l’école. Elles communiquent via ce réseau interne, hors accès internet (ce
dernier n’étant pas nécessaire pour la fonctionnalité de base). Le groupe de travail/domaine est
le même, ce qui permet un partage aisé des ressources.

Compte utilisateur pour la sauvegarde : Sur VM1, nous avons créé un compte utilisateur
spécifique backup_service (membre du groupe Administrateurs) qui sera utilisé par le service
Cobian Reflector. Sur VM2, le partage SAUVEGARDES a été sécurisé de sorte que seul un compte
backup_user (avec mot de passe) puisse y écrire. Lors de la configuration, nous ferons en sorte
que Cobian s’exécute sous backup_service et accède au partage réseau avec les identifiants
de backup_user. Cette séparation vise à simuler de bonnes pratiques de sécurité (le compte de
sauvegarde a des accès contrôlés, et on évite d’utiliser un compte générique sans mot de passe).

Topologie de réseau : Hormis les deux machines, le schéma est assez simple. Il n’y a pas de
routeurs ou de VLANs spéciaux, on considère que le serveur principal et le serveur de
sauvegarde sont dans le même LAN (par exemple, branchés sur le même switch au siège de
l’école). Une amélioration ultérieure pourrait être d’avoir le serveur de sauvegarde sur un autre
site (bâtiment distant relié par VPN), mais cela sort du périmètre de ce projet.

En résumé, l’architecture retenue consiste en une sauvegarde de serveur-à-

serveur sur le LAN. Cobian Reflector fonctionnant sur le serveur principal VM1 va copier les
données vers le serveur de sauvegarde VM2 à travers le réseau local. A intervalle régulier, les
deux serveurs communiqueront pour transférer les nouvelles données à sauvegarder. En cas de
crash du serveur principal, le serveur de sauvegarde conservera une copie sur laquelle s’appuyer
pour restaurer. La figure suivante synthétise ce déploiement :

La figure 4.1 illustre l’architecture proposée

de la solution de sauvegarde. On y distingue
deux machines principales :

Figure 4.1 : Schéma de l’architecture de

sauvegarde. Sur cette figure, on voit le
serveur principal (Windows Server VM1) à
gauche, hébergeant les données de l’école,
Topologie et le serveur de sauvegarde (Windows 10
architecture VM2) à droite, stockant les copies de
sauvegarde. Cobian Reflector (icône de
seau) est installé sur VM1 et envoie les
données vers le dossier partagé de VM2 via
le réseau local (câble symbolique).

Remarque : Dans la figure, le cloud externe

est indiqué en option (pointillé) pour signifier
qu’une copie externe pourrait être ajoutée
plus tard (ex: synchronisation des
sauvegardes vers un stockage cloud pour
avoir une copie hors-site). Ce n’est pas
implémenté dans le cadre de ce projet mais
c’est une perspective.

4.2. Installation de Cobian Reflector et paramétrage initial

Une fois l’environnement préparé, nous procédons à l’installation de Cobian Reflector sur le
serveur principal (VM1). Les étapes suivies sont décrites ci-dessous :

 Téléchargement : Nous avons récupéré l’installateur de Cobian Reflector (version

2.7.20, la dernière en date au moment du projet) depuis le site officiel CobianSoft. Le
fichier .exe fait environ 54 Mo. Il convient de s’assurer de la provenance du fichier
(sites officiels ou sources de confiance comme Gratilog.net, MajorGeeks). Un hash
SHA256 était fourni pour vérification, que nous avons contrôlé pour valider l’intégrité
de l’installeur.
 Lancement de l’installation : Sur VM1 (Windows Server), on exécute l’installateur en
tant qu’administrateur. L’assistant d’installation Cobian Reflector s’ouvre. Il est
similaire aux installations classiques de Cobian Backup décrites dans des tutoriels. On
accepte le contrat de licence, on choisit le répertoire d’installation par défaut
(C:\Program Files\Cobian Reflector\).

 Choix du mode d’installation (Service ou Application) : Cobian propose à

l’installation de s’installer soit comme un Service Windows démarrant
automatiquement, soit comme une application classique lancée manuellement. Nous
avons choisi le mode service, car il est plus adapté pour un serveur (les backups pourront
se lancer même si personne n’est connecté à la session Windows). Lors de ce choix,
Cobian demande sous quel compte le service va tourner. Comme évoqué
précédemment, nous avons opté pour « Installer sous le compte » et fourni les
identifiants du compte backup_service créé pour l’occasion. Si on avait choisi Compte
Système local, le service aurait tourné avec de très hauts privilèges mais sans accès
réseau (le compte Système local ne peut pas accéder aux partages distants, d’où
l’importance ici de prendre un compte utilisateur du domaine ou local avec droits
réseau). Après avoir saisi le login/mot de passe de backup_service et validé,
l’installateur configure le service.

 Fin de l’installation : L’installation copie les fichiers et enregistre le service. A la fin,

Cobian Reflector se lance automatiquement (une icône en forme de seau apparaît dans
la zone de notification de la barre des tâches si une session est ouverte). Sur un Windows
Server Core (sans interface graphique), on pourrait tout gérer via l’utilitaire de
configuration ou en ligne de commande, mais ici nous avons une interface graphique
disponible.

 Mise en français de l’interface : Par défaut, Cobian Reflector s’ouvre en anglais.

Toutefois, il offre la possibilité de passer en plusieurs langues. Dans notre cas, nous
sommes allés dans le menu Tools -> Options -> General -> Language et avons choisi
 Français, confirmant ainsi le passage de l’interface en langue française (ce qui facilitera
la prise en main pour des opérateurs francophones). Ce réglage est similaire à Cobian
Backup où “au démarrage, à gauche, [on peut] passer la langue en français”.

A ce stade, Cobian Reflector est opérationnellement installé sur le serveur principal. Aucun
job de sauvegarde n’est encore défini, ce qui est normal. Le service Windows tourne en arrière-
plan (on peut voir dans la console Services de Windows un service “Cobian Reflector Interface”
et “Cobian Reflector Engine” – en effet Reflector a séparé le moteur et l’interface).

Configuration de base du logiciel (options globales) : Avant de créer nos tâches, nous avons
ajusté quelques réglages globaux dans Cobian :

 Dans Options -> Engine : vérification que le service VSS est activé pour permettre la
copie des fichiers ouverts
 Dans Options -> Archives : choix du format de compression par défaut
 Dans Options -> Logs : on a vérifié que Cobian conserve un historique des logs
suffisant.
 Dans Options -> FTP (puisque Reflector ajoute SFTP) : nous n’en avons pas l’utilité
immédiate (on sauvegarde sur partage Windows), donc pas de configuration
particulière.
 Mot de passe global : Cobian Reflector permet de définir un mot de passe maître pour
protéger l’accès à l’interface. Dans un contexte multi-utilisateur, ça peut éviter qu’un
utilisateur lambda arrête le service ou modifie la config. Ici, comme c’est un serveur
maîtrisé par l’administrateur, nous n’avons pas défini de mot de passe d’interface (mais
c’est une option à connaître).

En somme, l’installation s’est déroulée sans encombre. Cobian Reflector est prêt à recevoir des
tâches de sauvegarde. La prochaine étape est de créer ces tâches pour répondre aux besoins
identifiés de l’École ABC.

4.3. Configuration des tâches de sauvegarde

Nous allons maintenant créer et paramétrer les tâches de sauvegarde dans

Cobian Reflector pour qu’il effectue automatiquement la copie des données de l’École ABC
vers le serveur de sauvegarde. Cobian fonctionne par tâches indépendante

Dans un souci de simplicité pour l’école, nous avons choisi de configurer une unique tâche de
sauvegarde principale englobant toutes les données critiques, ce qui facilite la gestion (un seul
plan de sauvegarde à superviser) Voici les détails de la configuration effectuée :
Création de la tâche : Dans l’interface nous avons cliqué sur le menu Tâche -> Nouvelle
tâche. Une fenêtre de propriétés de la nouvelle tâche s’est alors ouverte. Nous avons procédé
à remplir les onglets successivement :

 Onglet “Général” :
o Nom de la tâche : “Sauvegarde_Quotidienne_EcoleABC”. Un nom explicite
aidant à comprendre l’objet.

o Type de sauvegarde : Reflector propose « Complet, Incrémental, Différentiel,

Ouverture de session, etc. ». Nous avons choisi Incrémentielle

o Séparer les sauvegardes avec horodatage : il existe une option “Créer des
sauvegardes séparées en utilisant l’horodatage. Cela signifie que chaque
exécution de la tâche créera un dossier ou fichier différent (par date) au lieu
d’écraser la précédente sauvegarde.

o Compression : Nous avons opté pour Créer une archive compressée en zip. On
peut choisir de fractionner l’archive si on veut, mais pas nécessaire ici car nos
volumes sont raisonnables

o Chiffrement : Nous avons décidé d’utiliser un chiffrement par mot de passe

(AES 256) sur les archives, pour protéger les données sauvegardées et
renseigner un mot de passe fort .

Onglet général

 Onglet “Fichiers” (Source et Destination) :

o Source : On ajoute ici les répertoires à sauvegarder. Nous avons inclus le dossier
D:\DATA_ECOLE\ (chemin local sur VM1 où sont les données de l’école). Ce
dossier contient tout : c’est la racine commune partagée. Destination : On
indique le chemin cible de la sauvegarde.

Dans notre cas, c’est un partage réseau sur VM2. Nous avons donc ajouté
comme destination \\VM2\SAUVEGARDES\ (ou l’équivalent en IP). Cobian
demande alors sous quel compte accéder à ce partage. On a donc spécifié les
informations d’authentification réseau : VM2\backup_user + mot de passe, ce
qui correspond à l’utilisateur autorisé sur le partage VM2
 Onglet fichier

o À ce stade, on peut tester la connexion (il y a un bouton “Tester” dans Cobian).

Nous l’avons fait et obtenu un message “Connexion réussie” ou la création d’un
dossier test sur la cible, confirmant que Cobian peut écrire sur
\\VM2\SAUVEGARDES\.

Bouton test

 Onglet “Planification” :

o On peut décider quand et comment les sauvegardes se lancent.

Pour l’École ABC, on veut une sauvegarde chaque jour à 18h, après la fin des
cours. Mais pour éviter d’avoir trop de petites sauvegardes qui s’enchaînent (les
incrémentielles), on veut aussi faire une sauvegarde complète une fois par
semaine (le dimanche).
Cobian ne peut pas changer automatiquement de type de sauvegarde selon le jour, mais il existe
une astuce : on ajoute deux horaires différents dans la même tâche :

 Du lundi au samedi à 18h → sauvegarde incrémentielle (seuls les fichiers modifiés

sont copiés).
 Le dimanche à 18h → sauvegarde complète (tous les fichiers sont copiés, créant une
nouvelle base).

Ainsi, chaque semaine démarre avec une sauvegarde complète le dimanche, et les sauvegardes
incrémentielles des jours suivants se basent sur cette nouvelle copie. Ce plan est bien adapté au
rythme de l’école.

o On a également coché “Ne pas lancer si système sur batterie” (pas applicable sur
un serveur fixe, mais au cas où, c’est une option).

Onglet
Plannification

 Onglet “Dynamiques” :

la suppression automatique des anciennes sauvegardes. On peut dire par

exemple “ne conserver que les 10 dernières archives”. Cela évite de saturer
l’espace disque. Nous avons configuré dans l’onglet Archiver une règle :
“Conserver au plus 14 jours de sauvegardes”.
  Onglet “Exclusions” :

Ici, on peut lister des fichiers ou types de fichiers à ne pas sauvegarder. Par
exemple, on pourrait exclure *.tmp ou des cache navigateurs.

Dans notre cas académique, nous n’avons pas mis d’exclusions spécifiques, voulant tout
sauvegarder.

 Onglet “Avancé” :
o On y trouve quelques paramètres comme la priorité des processus (on a laissé
“normal”), la compression multi-thread (activée par défaut, bien pour
performances), la possibilité de diviser l’opération en plusieurs parties
(découpage), que nous n’utilisons pas.

o Il y a aussi l’option “Utiliser Volume Shadow Copy” ici qu’il faut bien cocher
si on veut que VSS soit sollicité. Normalement c’est automatique, mais on vérifie
que c’est actif pour notre source D:\ (un volume NTFS local, donc éligible).

o On a aussi coché “Exécuter la tâche si une sauvegarde a été manquée” pour

être sûr qu’au redémarrage suivant d’un éventuel arrêt, on ne saute pas une
sauvegarde (bien que sur un serveur c’est rare de redémarrer durant la semaine
de travail sans planif).

Après avoir paramétré tout cela, nous avons enregistré la tâche. Elle apparaît alors dans la liste

Avec cette configuration, Cobian Reflector est fin prêt. Nous avons en quelque sorte codifié la
politique de sauvegarde de l’École ABC dans l’outil :

 Sauvegarde chaque jour en fin de journée de travail.

 Incrémentielle en semaine pour efficacité.
 Complète en fin de semaine pour simplicité de restauration.
 Données chiffrées et compressées, stockées sur un serveur distinct via le réseau.
 Nettoyage automatique des vieilles sauvegardes au-delà de 14 jours.

. Figure 4.2 : Capture d’écran de Cobian

Reflector – Configuration de la tâche de
sauvegarde. Cette figure montre
l’interface de Cobian Reflector
configurée pour la tâche
Onglet “Sauvegarde_Quotidienne_EcoleABC”.
Plannification On peut y voir, dans la partie gauche, la
tâche listée avec son type (Incrémentielle
planifiée). La partie droite affiche un
résumé : Source = D:\DATA_ECOLE,
Destination = \VM2\SAUVEGARDES,
Compression Zip activée, Chiffrement
AES activé, Planification quotidienne
 4.4. Mécanisme de restauration des données sauvegardées
La sauvegarde n’a de valeur que si l’on sait restaurer les données lorsqu’un sinistre survient.
Dans cette section, nous décrivons la procédure de restauration des fichiers à partir des
sauvegardes réalisées par Cobian Reflector, dans le cadre de notre solution. Nous le ferons en
deux temps :

a- Procédure type en cas de perte partielle (fichier unique) : Supposons qu’un

utilisateur a supprimé par erreur un fichier important
Etudiants/These2025.docx et qu’on veuille le restaurer.

1. On ouvre Cobian Reflector sur le serveur (ou sur un poste où l’interface est installée,
car on peut la piloter à distance, mais ici on est en local).
2. On va dans l’onglet Historique et on cherche la sauvegarde la plus récente avant la
date de suppression.
3. On peut soit retrouver directement l’archive correspondante sur le disque
\\VM2\SAUVEGARDES soit demander dans Cobian à parcourir cette sauvegarde.
4. Nos essais ont consisté à naviguer sur VM2, repérer l’archive d’une sauvegarde. On
l’a copiée sur VM1 temporairement.
5. Double-cliquer l’archive : Windows sait l’ouvrir car c’est un zip, il demandera le mot
de passe, on le fournit. On peut alors parcourir l’arborescence dans l’archive jusqu’à
Etudiants/These2025.docx et faire extraire vers D:\DATA_ECOLE\Etudiants\.
6. Vérification : le fichier est de retour sur le serveur avec son contenu intact (on peut
l’ouvrir, il n’est pas corrompu).

1. On ouvre Cobian Reflector sur le serveur (ou sur

un poste où l’interface est installée, car on peut
la piloter à distance, mais ici on est en local).
2. On va dans l’onglet Historique et on cherche la
sauvegarde la plus récente avant la date de
suppression.
3. On peut soit retrouver directement l’archive
correspondante sur le disque
\\VM2\SAUVEGARDES soit demander dans Cobian
Capture Procedure à parcourir cette sauvegarde.
restauration 4. Nos essais ont consisté à naviguer sur VM2,
 b- Procédure en cas de sinistre majeur (restauration complète) : Imaginons le
pire : le disque du serveur principal crashe. On le remplace, on réinstalle
Windows et Cobian Reflector. Comment restaurer toutes les données de l’école
?

1. On commence par monter le volume contenant les sauvegardes

2. Pour tester si la restauration complète fonctionnait bien, nous avons choisi de revenir
à un point précis dans le temps. Par exemple, nous avons voulu remettre les données
dans l’état où elles étaient le dimanche 20/07. Pour cela, nous avons utilisé :

 La sauvegarde complète du dimanche 13/07,

 Puis toutes les sauvegardes incrémentielles faites jusqu’au 20/07.

3. Il faut reconnaître que cette procédure de restauration globale demanderait du temps

(pour un volume de ~10 Go de données, compter peut-être 30-40 min de
décompression et de recopie, ce qui reste raisonnable pour une reprise d’activité en
quelques heures). Dans le cas de l’école, ce délai est acceptable étant donné que ce
n’est pas une entreprise 24/7 critique ; perdre une demi-journée pour tout remettre
d’aplomb est tenable en cas de crash majeur (qui de toute façon impliquerait aussi de
réinstaller un OS, etc.).

1. On commence par monter le volume contenant les

sauvegardes
2. Pour tester si la restauration complète
fonctionnait bien, nous avons choisi de revenir à un
point précis dans le temps. Par exemple, nous avons
voulu remettre les données dans l’état où elles
étaient le dimanche 20/07. Pour cela, nous avons
utilisé :

 La sauvegarde complète du dimanche 13/07,

Capture Procedure  Puis toutes les sauvegardes incrémentielles faites
jusqu’au 20/07.
4.5. Tests de sauvegarde et de restauration (scénarios et résultats)
Pour nous assurer de la fiabilité de la solution mise en place, nous avons réalisé une série de
tests en condition réelle sur notre environnement simulé. Ces tests visaient à vérifier que :

 Les sauvegardes s’exécutent bien aux moments prévus et couvrent l’ensemble des
données attendues.
 Les sauvegardes incrémentielles ne recopient que ce qui est nécessaire.
 Les journaux de Cobian ne signalent pas d’erreurs (fichiers non copiés, etc.).
 Les restaurations (tant partielles que complètes) permettent effectivement de retrouver
les données intactes.

Voici un résumé des principaux scénarios de test effectués et de leurs résultats :

Test A – Exécution planifiée d’une sauvegarde complète (dimanche) :

 Scénario : Nous avons initialisé manuellement la première sauvegarde complète (plutôt
que d’attendre le dimanche planifié).

 Observation : La sauvegarde a démarré, on peut suivre sa progression dans l’onglet

Tâches et Journal. Tous les fichiers du dossier source ont été compressés et transférés
 vers la destination. Durée : environ 4 minutes pour 1,2 Go de données de test
(documents divers), sur un lien réseau virtuel gigabit.

 Résultat : Un fichier Sauvegarde_Quotidienne_EcoleABC_2025-07-

12_220000.zip a été créé sur \\VM2\SAUVEGARDES, pesant ~300 Mo (car beaucoup de
documents texte compressés efficacement). Le journal indique “Tâche terminée avec
succès”. Aucune erreur notée. On a vérifié sur VM2 que le fichier était bien présent et
accessible. Test d’extraction de quelques fichiers au hasard depuis le zip : OK (intègres).

 Conclusion : La première sauvegarde complète s’est bien déroulée, produisant une base
saine.

 Scénario : Nous avons initialisé manuellement la

première sauvegarde complète (plutôt que d’attendre le
dimanche planifié).
 Observation : La sauvegarde a démarré, on peut suivre sa
progression dans l’onglet Tâches et Journal. Tous les
fichiers du dossier source ont été compressés et transférés
vers la destination. Durée : environ 4 minutes pour 1,2 Go
de données de test (documents divers), sur un lien réseau
virtuel gigabit.
 Résultat : Un fichier
Capture test A Sauvegarde_Quotidienne_EcoleABC_2025-07-
12_220000.zip a été créé sur \\VM2\SAUVEGARDES,
pesant ~300 Mo (car beaucoup de documents texte
compressés efficacement). Le journal indique “Tâche
terminée avec succès”. Aucune erreur notée. On a vérifié
sur VM2 que le fichier était bien présent et accessible.
Test d’extraction de quelques fichiers au hasard depuis le
zip : OK (intègres).
 Conclusion : La première sauvegarde complète s’est bien
déroulée, produisant une base saine.

Test B – Exécution planifiée d’une sauvegarde incrémentielle (jour suivant)

:

 Scénario : Nous avons laissé la planification faire son travail le lendemain à 18h. Entre-
temps, nous avons modifié quelques fichiers dans les sources (édité un document Word,
ajouté 2-3 nouveaux fichiers, supprimé un fichier pour simuler un cas).
  Observation : À 18h, Cobian Reflector (service) a automatiquement lancé la tâche
incrémentielle. Le journal de ce 13/07/2025 18:00 montre qu’il a détecté X fichiers
nouveaux/modifiés et qu’il les a ajoutés dans l’archive incrémentielle.

 Résultat : Un fichier Sauvegarde_Quotidienne_EcoleABC_2025-07-

13_180000.zip a été créé, très léger (~5 Mo) contenant seulement les quelques
modifications du jour. Le log indique succès. Nous avons ouvert ce zip, il ne contenait
que les fichiers attendus (les modifiés/nouveaux).

 Conclusion : La sauvegarde incrémentielle fonctionne : elle a ignoré tout ce qui n’avait

pas changé, ne copiant que l’essentiel, conformément à la définition. Le lien entre la full
et l’incrémentiel se fait via les attributs archive sur les fichiers . Test reussi

 Scénario : Nous avons laissé la planification faire son

travail le lendemain à 18h. Entre-temps, nous avons
modifié quelques fichiers dans les sources (édité un
document Word, ajouté 2-3 nouveaux fichiers, supprimé
un fichier pour simuler un cas).
 Observation : À 18h, Cobian Reflector (service) a
automatiquement lancé la tâche incrémentielle. Le journal
de ce 13/07/2025 18:00 montre qu’il a détecté X fichiers
nouveaux/modifiés et qu’il les a ajoutés dans l’archive
incrémentielle.
Capture test B  Résultat : Un fichier
Sauvegarde_Quotidienne_EcoleABC_2025-07-
13_180000.zip a été créé, très léger (~5 Mo) contenant
seulement les quelques modifications du jour. Le log
indique succès. Nous avons ouvert ce zip, il ne contenait
que les fichiers attendus (les modifiés/nouveaux).
 Conclusion : La sauvegarde incrémentielle fonctionne :
elle a ignoré tout ce qui n’avait pas changé, ne copiant que
l’essentiel, conformément à la définition. Le lien entre la
full et l’incrémentiel se fait via les attributs archive sur les
fichiers .Test reussi

Test C – Test de restauration suite à sinistre :

 Scénario : Nous avons simulé une panne totale du serveur principal le lundi 21/07. Pour
ce faire, nous avons pris nos sauvegardes arrêtées au 20/07 et nous avons complètement
effacé le dossier source sur VM1 (suppression de D:\DATA_ECOLE\ entier, comme si le
 disque était mort). Puis, en suivant la procédure de restauration globale (voir 4.4), nous
avons tenté de récupérer l’intégralité des données à l’état du 20/07.

 Observation : On choisit la full la plus récente (dimanche 20/07), on la décompresse

en premier. Puis on applique l’incrémentielle du lundi 21/07 18h (s’il y en avait, dans
notre cas on s’est arrêté au dimanche donc pas d’incrémentielle ce jour-là). S’il y avait
eu des incréments, on les aurait appliqués successivement

 Résultat : Après extraction, le dossier D:\DATA_ECOLE\ a été recréé avec toute son
arborescence et tous les fichiers comme attendu. On compare avec ce qu’il y avait le
20/07 avant panne (on avait exporté une liste de fichiers de référence) : tout correspond.
Les attributs de fichier (date modif, etc.) sont conservés puisque Cobian conserve les
timestamps dans les zip. Seuls les ACL (permissions NTFS) n’étaient pas restaurées,
car Cobian ne gère pas les permissions par défaut (on aurait pu cocher l’option “sauver
les attributs NTFS” lors de la configuration, ce que nous n’avions pas fait pour simplifier
– mais c’est faisable).

 Conclusion : La restauration complète est réussie. Temps pris : environ 10 minutes pour
dézipper ~1 GB de données. L’école pourrait repartir avec ses fichiers. Bien sûr, il
faudrait aussi reconfigurer les partages, etc., mais l’essentiel (les données) est sauvé.

 Scénario : Nous avons simulé une panne totale du serveur

principal le lundi 21/07. Pour ce faire, nous avons pris nos
sauvegardes arrêtées au 20/07 et nous avons complètement
effacé le dossier source sur VM1 (suppression de
D:\DATA_ECOLE\ entier, comme si le disque était mort).
Puis, en suivant la procédure de restauration globale (voir
4.4), nous avons tenté de récupérer l’intégralité des données
à l’état du 20/07.
Capture test C
 Observation : On choisit la full la plus récente (dimanche
20/07), on la décompresse en premier. Puis on applique
l’incrémentielle du lundi 21/07 18h (s’il y en avait, dans
notre cas on s’est arrêté au dimanche donc pas
d’incrémentielle ce jour-là). S’il y avait eu des incréments,
on les aurait appliqués successivement


Résultat : Après extraction, le dossier D:\DATA_ECOLE\ a
été recréé avec toute son arborescence et tous les fichiers
Test D – Journalisation et alertescomme : attendu. On compare avec ce qu’il y avait le 20/07
avant panne (on avait exporté une liste de fichiers de
 Scénario : Nous avons forcé une erreur pour voir comment c’est géré.
référence) : tout correspond. Les attributs de fichier (date
modif, etc.) sont conservés puisque Cobian conserve les
 Observation : Le log Cobian a noté en rouge que le fichier était verrouillé et n’a pas pu
timestamps
être copié. La sauvegarde se termine avec dans les zip. Seuls les ACL (permissions
des “Avertissements”
NTFS) n’étaient pas restaurées, car Cobian ne gère pas les
permissions par défaut (on aurait pu cocher l’option
“sauver les attributs NTFS” lors de la configuration, ce que
nous n’avions pas fait pour simplifier – mais c’est faisable).
 Résultat : Cobian n’arrête pas toute la sauvegarde pour autant, il continue avec les
autres fichiers. Ce comportement est bien car on ne veut pas qu’une erreur sur un fichier
empêche tous les autres de se sauvegarder. Cependant, l’administrateur doit examiner
les logs (ou configurer envoi email) pour détecter ces alertes et y

 Conclusion : Le système de log fonctionne, et il sera essentiel que l’École ABC ait un
rituel de vérification des rapports de sauvegarde

 Scénario : Nous avons forcé une erreur pour voir comment

c’est géré.

 Observation : Le log Cobian a noté en rouge que le fichier

était verrouillé et n’a pas pu être copié. La sauvegarde se
termine avec des “Avertissements”

Capture test D  Résultat : Cobian n’arrête pas toute la sauvegarde pour

autant, il continue avec les autres fichiers. Ce
comportement est bien car on ne veut pas qu’une erreur sur
un fichier empêche tous les autres de se sauvegarder.
Cependant, l’administrateur doit examiner les logs (ou
configurer envoi email) pour détecter ces alertes et y

 Conclusion : Le système de log fonctionne, et il sera

essentiel que l’École ABC ait un rituel de vérification des
rapports de sauvegarde

En synthèse, les tests réalisés confirment que la solution de sauvegarde remplit son rôle :

 Les données sont copiées régulièrement et de manière fiable vers un stockage

secondaire.
  Le mécanisme d’incrément permet de gagner du temps et de la place tout en préservant
un historique de versions.
 La restauration, quoique manuelle, est possible et a été validée sur des exemples
concrets.
 Aucune perte ou corruption de données n’a été constatée au cours des transferts.
 La charge sur le serveur principal durant la sauvegarde est restée modérée
 Le réseau a été sollicité modérément (sauvegardes de l’ordre de quelques centaines de
Mo à 18h, ce qui sur un LAN gigabit passe en quelques minutes sans impacter les
utilisateurs puisqu’ils sont partis).

Ces résultats nous donnent confiance dans le déploiement de cette solution en environnement
réel. Dans la section suivante, nous conclurons en récapitulant les bénéfices du projet et en
évoquant les améliorations futures envisageables.

Shema expliquenat tous

nos test suvegardes full
et incrementielles +
restaurations +
jounalisation +resultats

Conclusion et perspectives
 Au terme de ce projet de fin d’études consacré à la mise en place d’une solution de
sauvegarde automatisée des données pour une petite structure (ici, l’École ABC simulée), nous
pouvons tirer plusieurs enseignements et conclusions positives.

Tout d’abord, les objectifs initiaux ont été atteints. Une stratégie de sauvegarde adaptée a été
conçue, fondée sur les bonnes pratiques du domaine (sauvegardes régulières, multiples copies,
conservation d’historique). Cette stratégie a été implémentée à l’aide de l’outil Cobian
Reflector sous Windows, qui s’est avéré être un choix judicieux en termes de fonctionnalités
et de simplicité d’utilisation. La solution déployée permet désormais de sécuriser les données
critiques de l’école de manière fiable : chaque jour, une copie des nouveaux fichiers ou des
fichiers modifiés est stockée sur un serveur distinct, et chaque semaine une sauvegarde
complète actualise la base. En cas de perte de données, les fichiers peuvent être restaurés
rapidement à partir des archives de sauvegarde.

Le système de sauvegarde mis en place offre une réponse efficace à la

problématique de départ. Il réduit drastiquement le risque de perte définitive d’informations
pour l’École ABC. Là où auparavant une panne de disque ou une attaque virale aurait pu
signifier la destruction irrémédiable de documents essentiels, l’école dispose maintenant d’un
filet de sécurité. Ce progrès s’inscrit pleinement dans la statistique sectorielle qui souligne que
80% des entreprises sans sauvegarde font faillite après un gros sinistre : l’École ABC ne fera
pas partie de ces victimes, ayant désormais une résilience face aux incidents.

Le déploiement de la solution s’est fait à moindre coût, ce qui est un critère important pour une
petite structure. Tout le logiciel utilisé est gratuit ou déjà possédé par l’organisation. Ce projet
a également servi de mise en situation professionnelle pour les etudiants que nous sommes. Il
nous a permis de mobiliser des compétences variées : analyse du besoin, veille technologique
(comparaison d’outils de sauvegarde), configuration système, tests et validation, rédaction
technique.

En somme, la mise en place de cette solution de sauvegarde répond au défi posé en début de
projet. L’École ABC peut désormais envisager l’avenir numérique avec sérénité, ayant réduit
l’un des risques majeurs pesant sur son système d’information.

Perspectives d’amélioration
Bien que la solution actuelle soit fonctionnelle et satisfasse aux besoins exprimés, il
existe plusieurs axes par lesquels on pourrait la renforcer ou l’étendre à l’avenir. En voici les
principaux :
  Sauvegarde externalisée (off-site) : Actuellement, les sauvegardes sont stockées sur
un serveur de sauvegarde situé dans le même réseau local que le serveur principal. Cela
protège contre nombre de défaillances (panne matérielle du serveur principal, erreur
humaine, ransomware ciblant le serveur principal uniquement, etc.), mais ne couvrirait
pas un sinistre majeur sur le site (incendie, vol simultané des deux serveurs,
inondation).

Une évolution recommandée serait de mettre en place une copie externalisée des
sauvegardes. Par exemple, utiliser un service cloud sécurisé pour y expédier
automatiquement les archives chiffrées générées .

 Sauvegarde des bases de données spécifiques : avec des bases de données (MySQL,
SQL Server, etc.) il conviendrait de s’assurer que les données sont bien sauvegardées
dans un état cohérent. Cobian, via VSS, peut copier les fichiers de base de données en
cours, mais il est parfois recommandé d’exporter les BDD (dumps) régulièrement et de
sauvegarder ces dumps pour plus de sûreté.

 Interface de suivi pour le personnel : Pour faciliter le suivi par une personne non
technique, on pourrait envisager d’ajouter un tableau de bord simplifié. Par exemple,
un fichier HTML ou un petit script PowerShell qui lit le dernier log et affiche
“Sauvegarde OK” en vert ou “Erreur” en rouge, éventuellement sur l’intranet de l’école.
Ceci afin que, d’un coup d’œil, on sache si tout va bien. C’est une amélioration en
ergonomie qui peut être faite ultérieurement.

En définitive, les perspectives d’amélioration touchent à la fois la robustesse technique (copie

hors-site, tests de restauration automatisés) et la facilité d’exploitation (alertes, monitoring).
Elles pourront être mises en œuvre progressivement, en fonction des priorités et des ressources
de l’école. L’important est que le socle est désormais en place : la sauvegarde existe et
fonctionne. Chaque amélioration viendra ajouter une couche de sécurité ou de confort
supplémentaire.

Annexes 1

 Dans Options -> Engine : vérification que le service VSS est activé pour permettre la
copie des fichiers ouverts
 Dans Options -> Archives : choix du format de compression par défaut
 Dans Options -> Logs : on a vérifié que Cobian conserve un historique des logs
suffisant.
 Dans Options -> FTP (puisque Reflector ajoute SFTP) : nous n’en avons pas l’utilité
immédiate (on sauvegarde sur partage Windows), donc pas de configuration
particulière.
 Mot de passe global : Cobian Reflector permet de définir un mot de passe maître pour
protéger l’accès à l’interface. Dans un contexte multi-utilisateur, ça peut éviter qu’un
utilisateur lambda arrête le service ou modifie la config. Ici, comme c’est un serveur
maîtrisé par l’administrateur, nous n’avons pas défini de mot de passe d’interface
(mais c’est une option à connaître).

 Annexe
 Annexe 2
 Annexe 2
Bibliographie
1. 8TECH – 80 % des entreprises ayant perdu leurs données informatiques font faillite
dans les 12 mois. (Consulté en juillet 2025).
2. Oodrive – Différences entre sauvegarde incrémentielle et sauvegarde différentielle.
(Article blog, mis à jour le 06/11/2024).
3. Koesio – Votre entreprise est-elle préparée au risque de perte de données
informatiques ? (Article, statistiques PME).
4. Nowteam – La règle 3-2-1 de sauvegarde des données : comment l’appliquer ? (Blog,
22 mars 2025).
5. Malekal.com – Tutoriel Cobian Backup : sauvegarde de données. (2019, par
malekalmorte).
6. CobianSoft (Luis Cobian) – Site officiel Cobian Backup/Reflector – Page de
présentation.
7. MajorGeeks – Cobian Reflector 2.7 – Description. (Fiche logiciel, 2024).
8. TechRadar – Cobian Backup and Cobian Reflector review (S. E. Wyciślik-Wilson, 2
sept. 2024).
9. Reddit – Create automatic backups with TAR and Cron – Beginner's Guide. (Post,
expliquant tar + cron sous Linux).
10. CobianSoft Forums – User experiences & tips on Cobian Reflector. (Consultation de
commentaires d’utilisateurs).