Choisir une sauvegarde fiable et restaurer le site

Introduction

Une petite boutique utilise un service de commandes pour relier clients, produits et quantités. Après un incident préparé, deux commandes manquent. Vous devez récupérer les données sans remplacer le catalogue public indépendant. Personnes et enregistrements sont synthétiques ; aucun logiciel malveillant n’est présent.

Une sauvegarde est une copie destinée à la restauration. Une archive regroupe des fichiers ; une empreinte résume leurs octets. Vous apprendrez pourquoi l’empreinte n’est utile qu’avec une référence fiable, puis restaurerez une véritable base SQLite par une zone de préparation. Cet exercice limité ne constitue pas une procédure complète de réponse aux incidents.

Savoir saisir des commandes et changer d’onglet suffit. Workstation et App Server sont deux sessions du même hôte, avec des répertoires initiaux différents, et non deux machines. Order Service fournit la vue web.

Préserver les données endommagées du service

Dans cette étape, vous comprendrez les données métier manquantes et préserverez une copie de retour arrière avant toute modification.

Sélectionnez l’onglet Order Service dans l’interface du laboratoire pour commencer cette étape.

Passez à l’onglet Order Service. Chaque ligne relie normalement un numéro de commande à un client, un état, un produit et une quantité. Le point de restauration requis comprend ces trois commandes :

Seule 4101 apparaît. Cliquez sur Public catalog : tasses, carnets et sacs doivent toujours y figurer. Ce fichier est indépendant de la base et doit survivre à la restauration. Utilisez ensuite le bouton Retour du navigateur dans l’onglet Order Service pour revenir à la page des commandes.

Une API est l’interface d’un service pour les programmes. Dans Workstation, curl interroge l’API ; -f traite les erreurs serveur comme des échecs, -s masque la progression et -S affiche tout de même les erreurs. 127.0.0.1 désigne cet hôte et 8080 le port du service.

Passez à l’onglet Workstation avant d’exécuter la commande suivante.

curl -fsS http://127.0.0.1:8080/api/orders

Le résultat est un tableau JSON, une liste de lignes entre crochets. Seule la ligne de Mina existe. Une requête réussie ne signifie pas que les données sont complètes.

Passez à l’onglet App Server. pwd affiche le répertoire courant :

Passez à l’onglet App Server avant d’exécuter la commande suivante.

pwd

Vous devez obtenir /srv/order-service. SQLite conserve les tables dans orders.db. Ce service préparé n’a aucun processus d’écriture et rouvre la base à chaque requête ; sa copie est sûre ici. Une base de production active nécessite une sauvegarde cohérente avec l’application.

cp prend la source puis la destination. Préservez la base hors du répertoire applicatif pour pouvoir annuler une mauvaise restauration :

cp /srv/order-service/orders.db /home/labex/project/recovery/damaged-before-recovery.db

L’absence de sortie indique généralement une copie terminée. Ne répétez pas cette commande après restauration : la base restaurée écraserait votre copie de retour arrière. L’état endommagé est préservé ; le service reste à restaurer.

Choisir une archive de restauration fiable

Dans cette étape, vous rejetterez les octets altérés et placerez l’archive vérifiée adaptée dans un répertoire de préparation.

Sélectionnez l’onglet Workstation dans l’interface du laboratoire pour commencer cette étape.

Passez à l’onglet Workstation. cd change de répertoire ; ls en liste le contenu. Un chemin absolu commence par / et fonctionne quel que soit le répertoire courant.

Passez à l’onglet Workstation avant d’exécuter la commande suivante.

cd /home/labex/project/recovery/backups

ls

Trois archives .tar.gz sont présentes : tar regroupe les fichiers et gzip les compresse. Les noms décrivent les heures de restauration ; le plus récent n’est pas forcément sûr ou adapté.

cat affiche un fichier texte. Lisez les points fournis séparément par le dépositaire des sauvegardes :

cat /opt/backup-custodian/recovery-points.txt

L’archive 0800 précède 4102 et 4103. Celle de 0900 couvre le point requis. Le candidat 1000 est plus récent, mais son intégrité reste à vérifier.

L’intégrité signifie que les octets n’ont pas changé par rapport à une référence. SHA-256 produit une empreinte de comparaison. Le manifeste appartient à root et se trouve hors du dossier de restauration normalement modifiable. Le scénario suppose une livraison par un canal protégé indépendant ; signatures et distribution des clés ne sont pas enseignées. Un administrateur peut contourner la propriété locale : cet hôte pédagogique n’est donc pas une ancre de confiance inviolable.

sha256sum -c lit les couples nom/empreinte et compare les fichiers du répertoire courant. Utilisez le manifeste indépendant :

sha256sum -c /opt/backup-custodian/SHA256SUMS

0800 et 0900 doivent afficher OK, 1000 FAILED. Le code non nul et l’avertissement sont attendus : au moins une archive a changé. N’extrayez pas ce candidat.

Le manifeste voisin peut être modifié avec les sauvegardes. Comparez son résultat :

sha256sum -c SHA256SUMS

Les trois affichent OK. Qui peut modifier l’archive peut remplacer l’empreinte voisine. Une correspondance avec une référence non fiable ne prouve pas l’authenticité. 0800 est inchangée mais incomplète. Choisissez 0900, inchangée et adaptée.

La préparation permet d’examiner les données avant de toucher au service actif. mkdir -p crée le répertoire et accepte qu’il existe déjà :

mkdir -p /home/labex/project/recovery/stage

Copiez-y le candidat vérifié :

cp orders-0900.tar.gz /home/labex/project/recovery/stage/orders-0900.tar.gz

Si la source est mal saisie, cp signale un fichier introuvable ; utilisez ls et réessayez. Le contrôle examine les octets réels de l’archive préparée, pas une déclaration de vérification.

Examiner la base en préparation

Dans cette étape, vous examinerez les membres, extrairez le seul fichier attendu et lirez la base préparée sans la modifier.

Sélectionnez l’onglet Workstation dans l’interface du laboratoire pour commencer cette étape.

Passez à l’onglet Workstation et entrez dans la zone de préparation :

Passez à l’onglet Workstation avant d’exécuter la commande suivante.

cd /home/labex/project/recovery/stage

tar -tvzf liste une archive gzip : t liste, v inclut type et permissions, z indique gzip et f nomme l’archive. La liste n’extrait rien.

tar -tvzf orders-0900.tar.gz

Le seul membre doit être orders.db, avec des permissions commençant par -, signe d’un fichier ordinaire. Arrêtez-vous devant des chemins absolus, composants .., liens ou fichiers inattendus. Cette inspection est utile car l’archive pédagogique fiable ne contient qu’un fichier ordinaire ; elle ne constitue pas une politique complète d’extraction sûre d’archives arbitraires. N’exécutez jamais les programmes d’une sauvegarde suspecte.

Pour extraire, utilisez x au lieu de t et retirez v. Le orders.db final limite l’extraction à ce membre ; --no-same-owner conserve votre propre propriété :

tar -xzf orders-0900.tar.gz --no-same-owner orders.db

SQLite stocke les tables liées dans un fichier. L’outil préparé db-view ouvre la base en lecture seule, contrôle cohérence et relations, puis affiche les lignes métier jointes. Vous n’avez pas à écrire de SQL ni à modifier la base. Donnez le chemin préparé :

/opt/c11-runtime/db-view /home/labex/project/recovery/stage/orders.db

Attendez Integrity: ok, Relationships: ok, puis les trois commandes. Une base valide peut néanmoins correspondre au mauvais point : comparez aussi clients, états et quantités à l’étape 1.

Un mauvais chemin produit une erreur sans créer de base vide. Vérifiez pwd et ls, puis réessayez. Si les données diffèrent, revenez au manifeste indépendant et choisissez la bonne archive avant une nouvelle extraction. Le site reste endommagé : préparer ne restaure pas l’application.

Restaurer et tester le service actif

Dans cette étape, vous remplacerez uniquement la base désignée et confirmerez la restauration par de vraies requêtes, tout en préservant le fichier public.

Sélectionnez l’onglet App Server dans l’interface du laboratoire pour commencer cette étape.

Passez à l’onglet App Server. La copie de retour arrière est hors de ce répertoire et la base préparée a été examinée. Copiez uniquement cette base au chemin de données prévu :

Passez à l’onglet App Server avant d’exécuter la commande suivante.

cp /home/labex/project/recovery/stage/orders.db /srv/order-service/orders.db

Source et destination sont différentes. Évitez de copier tout le répertoire préparé sur /srv/order-service : il contient des fichiers publics indépendants à préserver. Aucun redémarrage n’est nécessaire, car cette application préparée en lecture seule ferme la base après chaque requête. D’autres applications peuvent imposer une maintenance ou un redémarrage documenté.

Interrogez l’application au lieu de vous fier à une sauvegarde ou à un fichier texte restored :

curl -fsS http://127.0.0.1:8080/api/orders

Les trois lignes 4101, 4102 et 4103 doivent avoir les bons clients, l’état packed et les quantités 1, 2, 3. Passez à l’onglet Order Service et actualisez : le tableau doit correspondre.

Revenez à l’onglet App Server. Vérifiez aussi le fichier public indépendant :

curl -fsS http://127.0.0.1:8080/uploads/catalog.txt

Public catalog: mugs, notebooks, tote bags

Passez à l’onglet Order Service, revenez à la page des commandes avec le bouton Retour du navigateur si nécessaire, puis cliquez sur Public catalog et confirmez le même contenu. Utilisez le bouton Retour du navigateur dans Order Service pour revenir au tableau des commandes une fois terminé. Restaurer signifie retrouver les données métier requises et conserver les autres fonctions normales.

Si le service affiche Database unavailable, examinez de nouveau la base préparée et répétez la copie d’un seul fichier avec les bons chemins absolus. Pour revenir à l’état endommagé pendant l’analyse d’une erreur, passez à l’onglet App Server et utilisez la copie préservée :

cp /home/labex/project/recovery/damaged-before-recovery.db /srv/order-service/orders.db

Cette dernière commande annule volontairement la restauration. Si vous l’utilisez, recopiez la base préparée vérifiée vers la base active avant de terminer. Gardez le fichier de retour arrière pour examen ultérieur.

Résumé

Vous avez préservé une copie de retour arrière, comparé les octets à un manifeste indépendant fiable, choisi un point adapté et examiné une base SQLite préparée. Vous avez ensuite restauré le service réel et contrôlé relations et fichier public indépendant. Récent, inchangé et adapté sont des propriétés distinctes ; une restauration sûre les combine correctement.