PhpBB Lab Académie

Réunir les preuves de sauvegarde, distinguer contrôle d’intégrité et test de restauration, conserver une seconde copie et remettre la source dans son état d’accès initial.

Donner un sens au mot « terminé »

Nous avons obtenu les deux éléments de S1 : phpbb_ecole.sql et fichiers\forum-ecole. Avant de quitter la période sans écriture, nous allons vérifier qu’ils forment bien un point cohérent. Cela signifie qu’aucun participant, administrateur ou traitement n’a modifié le forum entre l’export SQL et la copie des fichiers.

Si vous avez publié un message, changé un réglage ou ajouté un fichier au milieu de l’opération, ne rapprochez pas artificiellement les dates dans vos notes. Refaites les deux parties pendant une nouvelle période maîtrisée, dans un nouveau dossier horodaté. N’associez pas le SQL d’hier à la copie des fichiers d’aujourd’hui en les appelant ensemble « sauvegarde du jour ».

Pour notre laboratoire, vous contrôlez les comptes et l’activité locale. Pour un véritable forum fréquenté, il faut aussi prendre en compte les tâches planifiées, les intégrations, les téléversements en cours et les garanties du système de sauvegarde. Le présent exercice enseigne une méthode vérifiable ; il ne transforme pas la fermeture publique de phpBB en arrêt universel des écritures.

Compléter un inventaire exploitable

Dans inventaire.txt, rassemblez le nom S1, les horaires, l’URL de la source, son dossier, la base phpbb_ecole, le moteur et le port SQL, la version PHP, la version phpBB et le préfixe des tables. Ajoutez les styles et extensions effectivement présents, les chemins éventuellement personnalisés et l’état initial du forum : ouvert ou déjà fermé.

Indiquez le nom du compte SQL, mais pas son mot de passe. Notez que son secret est conservé avec votre méthode privée habituelle. La copie de config.php reste, elle, à protéger comme un fichier contenant un secret. Une personne qui retrouve vos notes doit comprendre quel environnement était sauvegardé sans recevoir inutilement tous ses accès.

Dans preuves.txt, écrivez les résultats observés : export terminé sans erreur, toutes les tables sélectionnées, structure et données, pas de sélection de base imposée, fichier SQL lisible, copie des fichiers terminée, témoins retrouvés dans les éléments contrôlés. Ajoutez la taille du SQL et la taille totale relevée pour le dossier copié. Une case cochée sans résultat ne raconte pas ce qui a été vérifié.

Une empreinte pour détecter un changement de fichier

Une empreinte SHA-256 est un résultat calculé à partir des octets d’un fichier. Deux copies donnant la même empreinte offrent un contrôle d’intégrité beaucoup plus précis que leur nom ou leur taille. L’empreinte n’est pas un mot de passe et ne chiffre pas le fichier. Elle ne dit pas non plus si les données sauvegardées étaient les bonnes.

Sous Windows, l’outil Get-FileHash de PowerShell peut calculer cette empreinte. Cette étape est facultative dans notre atelier. Ouvrez PowerShell normalement, sans mode administrateur. La commande suivante est un modèle : remplacez le chemin complet entre apostrophes par celui de votre propre fichier SQL, avec votre nom Windows et la date réelle. Si Documents est redirigé, utilisez son emplacement réel.

Get-FileHash -LiteralPath 'C:\Users\VotreNom\Documents\Sauvegardes-phpBB\S1-AAAA-MM-JJ-HHMM-source\phpbb_ecole.sql' -Algorithm SHA256 | Format-List Algorithm,Hash,Path

Get-FileHash lit le fichier ; -LiteralPath précise son chemin exact ; -Algorithm choisit SHA256. La partie Format-List demande un affichage en lignes séparées. Lisez les valeurs Algorithm, Hash et Path. Notez la valeur complète de Hash dans preuves.txt. Si le chemin n’est pas trouvé, corrigez le chemin réel ; ne créez pas un fichier vide pour faire disparaître l’erreur.

Ce contrôle porte ici uniquement sur phpbb_ecole.sql. Il n’a pas calculé une empreinte de tous les fichiers de forum-ecole. Ne lui attribuez pas une portée plus grande. La copie des fichiers a ses propres contrôles, puis les essais de restauration vérifieront le fonctionnement de l’ensemble.

Préserver la copie de référence

S1 servira de point de départ à une restauration. Nous travaillerons sur une copie préparée ailleurs ; nous ne modifierons pas le config.php conservé dans S1. Si un clone demande un nouveau nom de base, cette adaptation se fera dans les fichiers de travail du clone. Une sauvegarde historique ne doit pas être transformée progressivement en installation en cours de modification.

Conservez également les notes de S1. Vous pourrez ajouter un résultat de test à preuves.txt, mais gardez la distinction entre les fichiers sauvegardés et le compte rendu. Une restauration faite demain restera une restauration du point S1 d’aujourd’hui. Elle ne contiendra pas les messages apparus entre-temps.

Faire une copie qui résiste à la perte du premier support

Deux dossiers sur le même disque ne protègent pas contre la panne de ce disque. Si vous disposez d’un support distinct, copiez-y le dossier S1 complet, avec ses notes. Il peut s’agir d’un support externe privé que vous pouvez ensuite déconnecter. Vérifiez sa destination et sa place disponible avant la copie. Un support prêté ou partagé publiquement ne convient pas à des fichiers contenant config.php et des données de membres.

Attendez la fin, contrôlez les mêmes éléments et ouvrez le fichier témoin depuis cette seconde copie. Si vous avez réalisé le calcul SHA-256, recommencez-le sur le SQL de ce support et comparez la valeur complète avec celle de la première copie. Une différence doit être comprise et corrigée ; n’effacez pas l’empreinte de référence pour accepter la seconde.

Le chiffrement peut protéger un support contre une lecture non autorisée. Il demande un outil correctement configuré et un moyen de retrouver sa clé ; ce cours ne vous fait pas improviser une nouvelle procédure de chiffrement. Si votre support est déjà chiffré, vérifiez que vous pouvez l’ouvrir avec la méthode prévue. Si vous n’avez pas encore de support distinct, écrivez explicitement « seconde copie indépendante non réalisée » et prévoyez-la. Le clone local peut servir au prochain exercice, mais il ne remplace pas une sauvegarde indépendante.

Réouvrir uniquement ce qui était ouvert

Lorsque SQL, fichiers et contrôles S1 sont terminés, la période sans écriture de la source peut finir. Avec CamilleAdmin, retournez au Panneau d’administration du forum source, à l’adresse habituelle http://localhost/forum-ecole/. Retrouvez le réglage « Désactiver le forum » utilisé au chapitre précédent.

Si le forum était ouvert avant la sauvegarde, remettez ce réglage à Non. S’il était déjà fermé, conservez son état initial. Rétablissez aussi le message de fermeture initial relevé au chapitre 1 si vous l’aviez modifié, puis validez le formulaire. Vérifiez avec une session de visiteur que le résultat correspond à ce choix, puis notez l’heure de fin de la période. N’ouvrez pas encore un futur dossier de restauration dans le navigateur : le prochain chapitre commencera par créer sa base indépendante et préparer sa configuration.

S1 contient le réglage de fermeture qui existait au moment de l’export. C’est normal. La préparation du clone gérera son propre état. N’éditez pas le SQL pour le faire ressembler au forum source désormais rouvert.

L’étape suivante fournit la preuve décisive

Vous pouvez maintenant écrire « S1 constitué et contrôlé ». N’écrivez pas encore « restauration validée ». Une taille plausible, une copie sans erreur et une empreinte concordante vérifient des aspects utiles, mais ne prouvent ni la cohérence de l’application ni le retour des permissions. Le chapitre suivant restaurera S1 dans une autre base et un autre dossier, puis recherchera nos deux témoins et testera les accès.

Exemple — une empreinte exacte, une sauvegarde incomplète

Camille exporte par erreur seulement la table des messages, puis copie ce SQL sur un disque externe. Les deux empreintes sont identiques : la copie reproduit fidèlement ce fichier. Pourtant, les tables des comptes et des permissions sont absentes. L’intégrité de la copie et la complétude de la sauvegarde sont deux questions différentes.

Une seconde erreur serait de tester la restauration uniquement avec CamilleAdmin. Un accueil qui s’affiche ne prouve pas qu’un invité reste exclu de Coordination. C’est pourquoi le prochain chapitre combinera les témoins de données, les fichiers et plusieurs profils d’accès.

Exercice — clôturer le point S1

1. Dans votre dossier privé S1, retrouvez le SQL, fichiers\forum-ecole, inventaire.txt et preuves.txt. Vérifiez que les horaires appartiennent à une même période sans écriture.
2. Complétez les notes avec la base, le moteur, les versions, les chemins, les tailles relevées et les contrôles réellement effectués. Retirez tout mot de passe qui aurait été ajouté aux notes.
3. Facultativement, calculez l’empreinte SHA-256 du SQL et consignez la valeur complète ainsi que le chemin concerné.
4. Si vous disposez d’un support privé distinct, copiez S1 entier sur ce support et contrôlez cette copie. Sinon, notez honnêtement que cette seconde copie reste à organiser.
5. Avec CamilleAdmin sur le forum source, rétablissez la valeur initiale de « Désactiver le forum » et le message de fermeture initial. Contrôlez le résultat avec une session de visiteur et notez l’heure.
6. Écrivez votre bilan en deux lignes : « point S1 constitué et contrôlé » si tous ces contrôles passent ; « restauration à tester au chapitre suivant ». N’importez encore aucun SQL.

Un point utile réunit fichiers, SQL et inventaire cohérents. Conservez sa référence intacte et, si possible, une seconde copie sur un support distinct. Une empreinte contrôle le contenu d’un fichier, pas la réussite d’une restauration. Remettez la source dans son état initial et testez ensuite S1 dans un clone isolé.