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.

Ouvrez 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. Revenez ensuite aux 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.

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 à App Server. pwd affiche le répertoire courant :

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.

Passez à 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.

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.

Dans Workstation, entrez dans la zone de préparation :

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.

Passez à 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 :

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. Ouvrez Order Service et actualisez : le tableau doit correspondre.

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

Cliquez sur Public catalog dans le navigateur et confirmez le même contenu. Restaurer signifie retrouver les données 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, 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.