Comment récupérer de la corruption du système de fichiers en utilisant le mode mono-utilisateur de FreeBSD

Malgré tous vos efforts, votre serveur peut être corrompu dans certains cas et nécessiter une récupération. Cela se produit parfois lorsque votre VPS est mis hors tension brusquement ou lorsqu’un logiciel ou un matériel informatique subit un dysfonctionnement soudain.

Dans les deux cas, vous pouvez prendre certaines mesures pour récupérer votre VPS. Sous FreeBSD, beaucoup de ces fonctions peuvent être exécutées en mode mono-utilisateur. Dans ce tutoriel, nous allons passer en revue les étapes que vous pouvez suivre pour démarrer votre droplet FreeBSD en mode mono-utilisateur et comment utiliser les outils disponibles pour tenter de récupérer un système de fichiers endommagé.

En toute circonstance, de bonnes sauvegardes sont le meilleur moyen d’éviter les pertes de données. La mise en œuvre d’une solution de sauvegarde hors site fiable et son test minutieux sur une base régulière constituent le seul moyen de garantir l’intégrité de vos données importantes.

Bien que les options de récupération telles que fsck soient souvent utiles, rien ne garantit qu’elles fonctionneront correctement et le succès est souvent une simple question de chance. L’opération fsck peut occasionnellement endommager les données des disques actifs. Des problèmes peuvent néanmoins survenir dans les cas de dommages graves, par conséquent, envisagez ces méthodes de dernier recours pour la récupération des données.

Pour démarrer votre droplet en mode mono-utilisateur, vous pouvez exécuter la commande suivante:

Cela indiquera à votre droplet de passer en mode mono-utilisateur lors du prochain redémarrage plutôt que d’essayer de charger le système complet. Une fois que vous êtes prêt, vous pouvez utiliser la commande + reboot + pour redémarrer votre droplet.

Après le redémarrage, votre droplet ne sera plus accessible via le réseau via ssh. Vous devez maintenant accéder à votre droplet via la console du panneau de configuration. Une fois le redémarrage terminé, vous vous retrouverez dans un shell très minimal similaire à celui présenté ci-dessous:

image: https: //assets.digitalocean.com/articles/freebsd-single-user/single_user_start.png [image]

Quand vous voyez la ligne:

Vous pouvez appuyer sur + Entrée pour démarrer une session shell.

Maintenant que votre droplet est en mode mono-utilisateur, nous pouvons continuer. Premièrement, assurons-nous que nous savons quel périphérique nous vérifions. L’exécution de la commande ci-dessous affiche les systèmes de fichiers actuellement configurés.

La sortie que vous voyez devrait être semblable à ceci:

image: https: //assets.digitalocean.com/articles/freebsd-single-user/fstab.png [image]

Le premier élément de la liste montre un système de fichiers ufs qui correspond à ce que nous recherchons. Vous pouvez maintenant exécuter la commande suivante pour effectuer une vérification du système de fichiers sur ce disque.

Une fois la vérification du système de fichiers terminée, vous pouvez redémarrer votre droplet à l’aide de la commande + reboot + pour quitter le mode mono-utilisateur et redémarrer votre dropet en mode normal (multi-utilisateur).

Connectez-vous à votre droplet à l’aide d’un client SSH. Si votre droplet répond à votre connexion ssh et que ce n’était pas avant, alors c’est bon signe. Si vous rencontriez précédemment des problèmes spécifiques qui vous avertissaient de la possibilité d’une corruption, vous devez réessayer ces opérations pour voir si elles réussissent.

Une chose importante à faire est de vérifier le répertoire / lost + found. C’est là que fsck met les fichiers partiellement récupérés.

Parfois, fsck est capable de récupérer des données de fichier, mais il ne peut pas trouver de référence au fichier sur le système de fichiers. Fondamentalement, c’est un fichier sans nom. Si fsck est confronté à cette situation, il place ces fichiers dans le répertoire / lost + found afin que vous puissiez essayer manuellement de déterminer le fichier.

Après avoir exécuté fsck, vérifiez si quelque chose a été placé dans ce répertoire. Puisque le répertoire lost + found n’est disponible que pour l’utilisateur root, nous allons d’abord passer au compte root avec une commande + sudo su +:

S’il y a des fichiers dans ce répertoire, vous voudrez voir si vous pouvez les identifier. Ce sont souvent des fichiers que vous avez quand même supprimés, mais que vous utilisiez toujours lorsque le système est tombé en panne. Cela vaut la peine de les vérifier pour être sûr.

Si votre système de fichiers est encore visiblement cassé, ou si le démarrage échoue lors du passage en mode multi-utilisateur, votre meilleure option peut être de https://www.digitalocean.com/community/tutorials/recovering-files-from-a- compromise-droplet-using-the-recovery-iso [utilisez un ISO de récupération pour récupérer les fichiers nécessaires]. Pour ce faire, vous devez couvrir un ticket avec l’équipe de support afin qu’ils puissent démarrer votre droplet dans l’environnement de récupération.

Bien que la corruption du système de fichiers ne soit jamais une bonne chose, cela ne signifie pas nécessairement que toutes vos données importantes ont été perdues. Le succès de vos opérations de récupération dépend d’un certain nombre de facteurs, tels que la rapidité avec laquelle le système de fichiers a constaté la corruption, l’étendue du problème et les fichiers affectés.

Au bout du compte, la récupération simple à l’aide d’outils automatisés est en grande partie une question de chance. Cela étant dit, dans de nombreux cas, la récupération de fsck est réussie et vous pouvez revenir à l’utilisation de votre serveur sans trop de maux de tête. N’oubliez pas que la sauvegarde des sauvegardes est la mesure la plus importante à prendre pour éviter la perte de données.