Évalue sauvegarde, stockage et haute disponibilité dans un incident intégré

01Contrat de l’évaluation

assessmentId : BTS-SISR-Y2-RES-001
blocs        : Bloc 1 + Bloc 2 SISR + Bloc 3
format       : TP évalué intégré + incident + reprise
contexte     : SORIA Distribution — environnement synthétique
objectif     : concevoir → observer → diagnostiquer → basculer/restaurer → vérifier → documenter

Cette évaluation ne fournit aucune suite de commandes à recopier. Les leçons techniques servent de documentation d’apprentissage ; l’étudiant doit choisir ses contrôles et justifier ses décisions.

02Contexte métier fictif

SORIA Distribution utilise trois services de laboratoire :

IDENTITE     : authentification + DNS du domaine
CONFIG_RESEAU: attribution DHCP des postes
OPERATIONS   : partage de fichiers via chemin DFS

Le scénario pédagogique fixe les objectifs suivants :

IDENTITE      RTO cible : 10 min
CONFIG_RESEAU RTO cible : 15 min
OPERATIONS    RTO cible : 20 min
OPERATIONS    RPO cible : 24 h maximum

Ces valeurs appartiennent uniquement au scénario de SORIA Distribution. Elles ne constituent ni une norme BTS ni une recommandation universelle.

L’étudiant doit expliquer, avant toute panne, ce que chaque objectif implique et quelles dépendances peuvent empêcher de l’atteindre.

03Infrastructure disponible

Le laboratoire fournit ou permet de construire :

2 contrôleurs de domaine avec DNS
2 serveurs DHCP en relation de failover
2 serveurs de fichiers publiés via DFS
stockage RAID 1 de laboratoire pour un volume défini
1 passerelle redondée VRRP si le scénario réseau complet est activé
1 client membre du domaine
1 copie de sauvegarde indépendante du jeu de données Operations

Les produits exacts de sauvegarde peuvent varier. La preuve attendue porte sur copie indépendante, point de restauration identifiable, intégrité et restauration testée.

04Prépare la carte de dépendances

Avant de toucher à l’infrastructure, l’étudiant remet un schéma ou tableau couvrant au minimum :

client
→ DHCP
→ passerelle
→ DNS
→ Active Directory
→ namespace DFS
→ cible de fichiers
→ stockage
→ sauvegarde / point de restauration

Pour chaque service :

composant nécessaire
point de défaillance restant
mécanisme de résilience
test positif prévu
limite du mécanisme

Une architecture redondée sans dépendances explicites n’est pas considérée comme préparée pour l’incident.

05Établis la baseline saine

Avant l’incident, le dossier doit prouver :

Identité / DNS

- deux DC disponibles ;
- réplication saine ;
- résolution DNS depuis le client ;
- secure channel valide.

DHCP

- relation de failover en état normal ;
- scope attendu ;
- renouvellement client réussi ;
- options gateway/DNS correctes.

DFS / fichiers

- chemin logique accessible ;
- deux targets attendues ;
- fichier témoin cohérent sur les deux membres ;
- permissions conformes.

RAID

- tableau sain ;
- membres actifs ;
- capacité observée ;
- fichier témoin et hash.

Sauvegarde

- point de restauration identifié ;
- heure du point ;
- données incluses ;
- emplacement distinct de la source ;
- preuve d'intégrité disponible.

La baseline reçoit un horodatage commun T0.

06Incident A — disponibilité

Le formateur sélectionne une carte de panne sans fournir la commande de correction.

Variante A — identité

SRV-DC01 devient indisponible.
Symptôme fourni : un serveur ne répond plus.
Attendu : démontrer si le client conserve DNS et domaine via le nœud restant.

Variante B — DHCP

un partenaire DHCP devient indisponible.
Symptôme fourni : perte d'un serveur réseau.
Attendu : renouveler un client et démontrer une configuration valide.

Variante C — fichiers

SRV-FS01 devient indisponible.
Symptôme fourni : un serveur de fichiers n'est plus joignable.
Attendu : conserver le même chemin DFS et accéder à une donnée cohérente.

Variante D — stockage

un membre du RAID 1 est déclaré en panne.
Symptôme fourni : tableau dégradé.
Attendu : prouver service restant puis reconstruire avec le membre de remplacement.

Variante E — passerelle

le nœud VRRP actif est perdu.
Symptôme fourni : passerelle primaire indisponible.
Attendu : mesurer le basculement et tester le service depuis le client.

L’étudiant doit distinguer :

symptôme
fait observé
hypothèse
cause démontrée
impact
mesure corrective ou basculement

07Mesure le RTO observé

La chronologie minimale est :

T1 panne déclenchée
T2 panne confirmée
T3 diagnostic orienté
T4 service fonctionnel via basculement/remédiation

Le RTO observé du service testé est calculé à partir du temps réellement mesuré jusqu’au retour fonctionnel côté client.

L’étudiant compare ensuite :

RTO observé
vs
RTO cible du scénario

Si la cible n’est pas atteinte, l’évaluation n’est pas automatiquement nulle : l’étudiant doit identifier pourquoi et proposer l’action d’amélioration la plus justifiée.

08Incident B — perte de donnée

Une fois l’infrastructure stabilisée, le scénario impose une perte logique d’une donnée synthétique dans Operations :

suppression contrôlée
OU
corruption contrôlée d'un fichier témoin

La donnée ne doit pas être recréée manuellement à partir du souvenir de l’étudiant.

L’étudiant doit :

1. prouver l'état perdu/corrompu ;
2. identifier un point de restauration conforme ;
3. restaurer vers une destination sûre ou selon la procédure étudiée ;
4. vérifier contenu et intégrité ;
5. remettre la donnée au bon emplacement selon le scénario ;
6. valider depuis le client ;
7. calculer l'âge réel de la donnée restaurée.

09Mesure le RPO observé

Le dossier contient :

heure de la dernière donnée valide avant incident
heure du point restauré
écart de données réellement perdu
RPO observé
RPO cible

Un job de sauvegarde marqué success n’est pas une preuve de RPO atteint. Le calcul doit porter sur la donnée effectivement restaurée.

10Retour à l’état sain

Après les deux incidents, l’étudiant doit fermer le cycle :

- nœud perdu revenu ou remplacé ;
- réplication AD/DNS saine ;
- failover DHCP cohérent ;
- DFS/DFSR convergé ;
- RAID reconstruit si concerné ;
- client fonctionnel ;
- sauvegarde toujours disponible ;
- aucun mécanisme laissé volontairement en mode dégradé sans justification.

La reprise technique n’est pas considérée terminée tant que les dépendances critiques ne sont pas revalidées.

11Preuves obligatoires

Le dossier remis contient au minimum :

01-architecture-dependances
02-baseline-T0
03-chronologie-incident-A
04-tests-service-pendant-panne
05-preuve-failover-ou-remediation
06-etat-apres-retour-A
07-preuve-perte-donnee-B
08-point-restauration-selectionne
09-preuve-restauration-integrite
10-calcul-RPO-RTO
11-recette-finale
12-limites-et-actions

Chaque élément suit :

EXIGENCE
→ CONTEXTE
→ ACTION
→ RESULTAT + VERIFICATION
→ LIMITE

Les captures contenant un mot de passe, secret partagé, jeton, donnée personnelle réelle ou topologie de production sont interdites.

12Grille d’évaluation

Exactitude et disponibilité technique

- services demandés réellement utilisables ;
- basculement/restauration fonctionnels ;
- retour à un état cohérent.

Méthode et diagnostic

- baseline avant action ;
- hypothèses explicites ;
- tests discriminants ;
- ordre de diagnostic justifié ;
- pas de redémarrage/modification aléatoire.

Sécurité et maîtrise des droits

- environnement borné ;
- secrets protégés ;
- accès conformes ;
- restauration sans écraser inutilement la source ;
- moindre impact pendant les tests.

Vérification et preuves

- tests côté client ;
- tests positifs et négatifs ;
- mesures temporelles ;
- hash ou preuve d'intégrité ;
- limites explicites.

Documentation et communication

- chronologie lisible ;
- faits séparés des hypothèses ;
- RPO/RTO calculés ;
- décision finale défendable ;
- amélioration priorisée.

13Décision finale

L’étudiant choisit une seule conclusion :

RESILIENCE_VALIDEE
→ les services testés satisfont les critères du scénario et les preuves sont complètes.

RESILIENCE_AVEC_ACTIONS
→ la reprise fonctionne, mais une cible, une preuve ou une dépendance reste à améliorer.

RESILIENCE_NON_DEMONTREE
→ le service, le failover, la restauration ou les preuves ne permettent pas de conclure.

La conclusion doit citer :

RTO cible / observé
RPO cible / observé
incident de disponibilité choisi
incident de donnée choisi
preuves déterminantes
limites du test
prochaine action prioritaire