Répétez la remise en service de votre wiki partagé.

Décider ce qui compterait comme un carnet fonctionnel

Utilisez le wiki d'atelier illustratif de la l'inventaire des services. Ses critères de réussite sont précis : un éditeur peut trouver et modifier une page de test, un lecteur peut consulter les instructions autorisées, un livre d'organisation privé reste masqué, et un diagramme joint s'ouvre. Utilisez ces contrôles comme plan de test avant d'ouvrir la sauvegarde.

Choisissez des témoins qui existaient lors de la création de la sauvegarde sélectionnée. Une page nouvellement créée ne peut pas prouver qu'une sauvegarde plus ancienne est incomplète.

Identifier l'ensemble de récupération exact

Inscrivez l'identifiant de sauvegarde et l'horodatage sur la feuille de résultats. Incluez la configuration de l'application, les données de la base de données, les pièces jointes et les informations logicielles nécessaires pour les interpréter. Si leurs heures de capture diffèrent, examinez comment votre procédure de sauvegarde assure leur cohérence avant de commencer l'exercice.

Pour un dépôt restic, choisissez un instantané explicite ou vérifiez soigneusement les filtres utilisés avec latest. Son --path option sélectionne un instantané ; elle ne limite pas les fichiers restaurés. Une restauration peut écraser des fichiers existants, ce qui est une raison supplémentaire d'utiliser une cible vide et dédiée. Documentation restic restore.

Distinguez les contrôles du dépôt de la récupération applicative. Un check examine la structure du dépôt ; check --read-data lit aussi les données de pack stockées et peut consommer un transfert et un temps considérables. Ni l'un ni l'autre ne vérifie si un membre peut utiliser votre wiki. contrôles d'intégrité restic.

Rendre la copie de test silencieuse avant son démarrage

Gardez les hôtes de base de données de production, les chemins de stockage et les identifiants sortants hors de la configuration de test. Demandez au second mainteneur de comparer chaque destination avec la carte des services. Confirmez que la cible est séparée avant toute opération de restauration qui écrit des fichiers ou des objets de base de données.

• Limitez l'accès aux personnes menant l'exercice.
• Laissez les enregistrements DNS de production inchangés.
• Bloquez l'envoi sortant ou remplacez-le par une destination de capture approuvée.
• Désactivez les webhooks, les intégrations planifiées et les travailleurs de file d'attente jusqu'à ce que leur comportement de test soit défini.
• Vérifiez que les liens et redirections du navigateur ne peuvent pas ramener discrètement le testeur vers la production.

Traitez les données restaurées avec la même sensibilité que l'original. L'isolation est un contrôle opérationnel à démontrer, pas une étiquette attachée à un répertoire. Si vous ne pouvez pas vérifier les destinations ou les contrôles, arrêtez avant de démarrer l'application.

Rassembler les pièces dans un ordre délibéré

Suivez les instructions de restauration correspondant à la méthode d'installation et aux versions de votre inventaire. Pour l'exemple BookStack, la procédure officielle couvre une restauration séparée de la base de données et des fichiers, en conservant l'original APP_KEY, et en ajustant l'URL de l'application lorsque l'adresse change. Les configurations conteneurisées nécessitent la restauration de la base de données avant l'exécution du conteneur applicatif. Séquence de restauration et notes de configuration BookStack.

1. Préparez la cible d'exécution et de base de données dédiée sans démarrer le trafic des membres ordinaires.
2. Restaurez la base de données et les fichiers correspondants ; conservez la sauvegarde d'origine inchangée.
3. Appliquez les adresses de l'environnement de test et les connexions externes restreintes.
4. Vérifiez la propriété et l'accès des fichiers requis par rapport aux instructions d'installation de l'application.
5. Démarrez le service avec les actions sortantes toujours contrôlées, puis exécutez les témoins prévus.

Récupérer d'abord la version enregistrée permet de garder un exercice de routine ciblé. Si l'exercice nécessite aussi un changement de version, documentez son chemin de migration et son point de restauration séparément. Ne faites pas d'une mise à niveau non planifiée le remède à un échec de restauration inexpliqué.

Vérifier à la fois ce qui fonctionne et ce qui reste interdit

Exécutez les vérifications de lecteur et d'éditeur dans des sessions de navigateur distinctes afin qu'une session administrateur ne puisse pas masquer un échec de permissions. Testez une pièce jointe via la page et son adresse directe. Recherchez une phrase connue, suivez un lien interne et inspectez une révision plus ancienne qui devrait exister dans la sauvegarde.

Si une vérification échoue, consignez la première différence observable. Une image manquante suggère une enquête différente d'une redirection de connexion inattendue ou d'une connexion à la base de données interdite. Conservez les preuves d'erreur pertinentes sans copier de contenu privé ni d'identifiants dans une note de support générale. Corrigez une cause identifiée et répétez la vérification concernée ; ne modifiez pas largement les permissions juste pour faire disparaître une erreur.

N'exercez l'e-mail que vers la destination de capture choisie. BookStack propose une action d'e-mail de test et documente que certaines défaillances de notification apparaissent dans les journaux plutôt que sur la page de l'utilisateur. Examinez ces preuves ainsi que le résultat visible. Vérifications d'e-mail et comportement en cas d'échec de BookStack.

Laisser un résultat honnête pour la personne suivante

Service / test owner / reviewer:
Backup identifier / capture timestamp:
Application and database versions:
Isolated target / access restrictions:
Outbound actions disabled or redirected:
Test start / usable-service checkpoint / finish:
Reader / editor / private book / attachment results:
Search / links / revision / notification results:
Missing information or failed steps:
Corrective action / owner / next exercise:
Test data cleanup completed by:

N'indiquez les heures observées qu'après avoir fait le travail, et précisez ce que chaque point de contrôle mesure. Une seule répétition réussie est une preuve pour cette sauvegarde et cette procédure ; elle n'établit pas une garantie de restauration pour une autre défaillance. Confirmez le nettoyage de la copie de test et de ses messages capturés selon les règles de conservation du groupe. Réintégrez les ingrédients manquants dans l'inventaire, et utilisez les exports de données portables pour préparer un chemin distinct de déplacement du contenu du groupe.