PhpBB Lab Académie

Rassembler des preuves de sauvegarde, de restauration, d’intervention et de retour, établir l’état final des trois installations, puis définir une routine de maintenance adaptée sans confondre laboratoire local et exploitation en production.

Ce que vous devez désormais pouvoir démontrer

Votre objectif n’est pas de posséder beaucoup d’archives. Vous devez savoir expliquer quelle installation a été sauvegardée, à quel instant, avec quels fichiers et quelle base, puis prouver que cette paire permet une restauration utilisable. Les témoins du cours matérialisent cette relation. Le fichier témoin prouve le retour d’un élément de l’arborescence ; les sujets prouvent le retour de données ; les essais de membres vérifient des règles de fonctionnement.

Aucun témoin ne prouve tout à lui seul. Un texte présent ne garantit pas que les pièces jointes, styles ou extensions d’un autre site fonctionnent. Dans notre laboratoire, vous contrôlez les éléments réellement utilisés par le parcours. Sur un service plus riche, la liste des vérifications doit s’enrichir avec ses fonctions. Une sauvegarde qui n’a jamais été restaurée reste une promesse non éprouvée.

Conserver trois états identifiables

La source reste à http://localhost/forum-ecole/ avec sa base phpbb_ecole. Le premier clone reste à http://localhost/forum-ecole-restauration/ avec phpbb_ecole_restauration. Le retour reste à http://localhost/forum-ecole-retour/ avec phpbb_ecole_retour. Chaque installation utilise son compte SQL dédié et ses réglages de session propres. Les mots de passe restent privés, hors des preuves destinées au partage.

La source conserve les ajouts des cours précédents et les seuls témoins créés au début de cette maintenance. Elle ne doit pas recevoir les sujets propres au premier clone. Le premier clone contient « Maintenance — témoin du clone » et « Maintenance — après intervention ». Le retour contient le premier de ces sujets et pas le second, puisque S2 les sépare dans le temps. C’est cette différence attendue, et non une ressemblance parfaite des trois sites, qui valide votre scénario.

En fin de travail, remettez la source dans son état d’ouverture initial, tel qu’il a été noté. Les clones peuvent rester fermés ; dans notre projet, vous les laissez fermés après leurs fenêtres de contrôle. Lisez l’adresse et le nom du site avant chaque changement de « Désactiver le forum ». Une fermeture dans le retour ne doit pas devenir par erreur une fermeture imprévue de la source.

Choisir une fréquence qui a un sens

La fréquence de sauvegarde dépend de l’activité et de ce que vous acceptez de perdre en cas d’incident. Imaginez une sauvegarde cohérente chaque nuit, et une panne juste avant la suivante : presque une journée d’échanges pourrait manquer dans le dernier état disponible. Cette situation peut être acceptable pour un laboratoire peu actif et insuffisante pour une communauté très active.

Choisissez donc un intervalle en fonction des nouveaux messages, inscriptions et fichiers, puis vérifiez qu’il est réalisable. Ajoutez une sauvegarde dédiée avant une intervention importante, même si une sauvegarde régulière existe déjà. Conservez plusieurs états identifiés : remplacer sans cesse l’unique sauvegarde par un état déjà dégradé peut vous priver d’un point de retour utile.

Séparer copie, protection et preuve

Une copie privée située sur le même disque protège de certaines erreurs, mais pas de la panne de ce disque. Une seconde copie sur un support distinct réduit cette dépendance. Un stockage chiffré peut protéger le contenu si le support est perdu, à condition de conserver l’accès à la clé ou au secret. Il ne rend pas les données cohérentes par magie et ne dispense pas d’un essai de restauration.

Les sauvegardes contiennent des messages, des comptes et des secrets de configuration. Elles ne doivent jamais être déposées dans un forum public ni dans un répertoire servi par le site. Les empreintes éventuellement calculées au chapitre 2 permettent de détecter certaines altérations d’un fichier comparé à son empreinte de référence. Elles ne prouvent pas qu’un export est complet ou qu’il correspond à l’archive des fichiers.

Définissez enfin une durée de conservation et un contrôle régulier : présence des copies, lisibilité, inventaire, accès au support et restauration d’essai. Avant d’effacer un ancien état, vérifiez que les états conservés répondent encore à votre besoin. N’effacez pas S1 ou S2 simplement parce que l’écran d’accueil des clones fonctionne aujourd’hui.

Comprendre ce qui manque encore pour la production

Ce cours a utilisé un laboratoire local maîtrisé, sans visiteurs réels ni intégration externe. En production, fermer l’accès ordinaire ne suffit pas à arrêter toutes les écritures : administrateurs, modérateurs, tâches planifiées, files de traitement ou services externes peuvent encore intervenir. La méthode de cohérence doit tenir compte de ces acteurs. Un instantané proposé par un hébergeur doit lui aussi être compris et testé ; son existence ne prouve pas à elle seule la cohérence entre fichiers et base.

L’adresse publique, HTTPS, les cookies, les permissions du système de fichiers, les envois de courriels, le DNS et les tâches planifiées demandent une préparation propre à l’environnement. Les réglages localhost et courriels désactivés du laboratoire ne sont pas une configuration de remplacement à copier sur le site public. Avant un vrai retour, il faut aussi estimer les données créées depuis la sauvegarde, conserver l’état récent si possible et décider comment traiter ces différences. Une réparation peut prendre du temps ; une restauration ne garantit pas une perte nulle.

Exemple de routine raisonnée

Pour son laboratoire, Camille prévoit une paire cohérente avant chaque atelier de maintenance, une copie privée sur un second support et un essai de restauration lorsqu’elle change sa méthode. Elle conserve l’inventaire avec la sauvegarde et note le temps nécessaire pour retrouver une installation utilisable.

Pour une communauté réelle, elle commencera par mesurer l’activité et définir l’ancienneté maximale acceptable du point de retour. Elle préparera ensuite une fréquence, une conservation et des tests adaptés. Elle ne promettra pas « aucun message perdu » uniquement parce qu’un fichier ZIP est créé chaque nuit. La décision de remettre en ligne dépendra des contrôles fonctionnels et de la situation des données récentes.

Projet autonome

Utilisez les trois installations et les sauvegardes déjà préparées. Vous ne devez ni les supprimer ni créer une quatrième copie. Constituez un dossier de validation textuel dans votre espace privé.

1. Décrivez S1 et S2 : installation d’origine, date réelle, emplacement privé de la paire fichiers-base, version des fichiers, version en base et moment des témoins. Vérifiez que les fichiers cités existent et sont lisibles. Si vous avez une seconde copie, notez son support sans inscrire son secret d’accès.

2. Vérifiez les trois config.php sans les recopier dans le rapport. Notez seulement, pour chaque adresse, le dossier, la base et le nom du compte SQL attendu. Vérifiez les cookies distincts des clones et leurs sorties de courriels/Jabber désactivées.

3. Pendant une fenêtre d’ouverture contrôlée de chaque clone, retrouvez les témoins attendus et constatez les absences attendues. Vérifiez avec inscrit_test l’accès public et le refus des espaces réservés ; avec eleve_test, l’accès des adhérents et le refus de Coordination ; avec equipe_test, Coordination et la modération locale des deux forums appris. Vérifiez aussi accueil_test actif et non banni.

4. Classez l’intervention du premier clone : véritable mise à jour vers une cible disponible et compatible, ou répétition avec le même paquet. Inscrivez les numéros réellement observés et les contrôles réussis. N’inventez pas une montée de version pour remplir la fiche.

5. Contrôlez l’absence de dossier install dans les installations finales. Refermez les deux clones, remettez la source dans son état initial et vérifiez chaque résultat comme visiteur. Rédigez ensuite votre routine : fréquence choisie, déclenchement avant intervention, seconde copie, conservation et prochain essai de restauration.

Une maintenance maîtrisée repose sur des paires cohérentes, des restaurations éprouvées et des preuves lisibles. La fréquence de sauvegarde reflète l’activité et la perte acceptable ; plusieurs copies et un support distinct complètent les tests. Vous savez désormais expliquer l’état de vos trois installations, leurs différences attendues et les points à préparer avant toute transposition en production.