Erreur du lundi matin: Sudo rm -rf --no-preserve-root /
Veuillez noter: Les réponses et commentaires à cette question contiennent du contenu d'une autre question similaire qui a reçu beaucoup d'attention de la part des médias extérieurs mais s'est avérée être une question de canular dans une sorte de système de marketing viral. Comme nous ne permettons pas à ServerFault d'être abusé de cette manière, la question d'origine a été supprimée et les réponses ont été fusionnées avec cette question.
Voici une tragédie divertissante. Ce matin, je faisais un peu de maintenance sur mon serveur de production, quand j'ai exécuté par erreur la commande suivante:
Sudo rm -rf --no-preserve-root /mnt/hetznerbackup /
Je n'ai pas repéré le dernier espace avant / et quelques secondes plus tard, lorsque des avertissements ont envahi ma ligne de commande, j'ai réalisé que je venais d'appuyer sur le bouton d'autodestruction. Voici un peu de ce qui m'a brûlé aux yeux:
rm: cannot remove `/mnt/hetznerbackup': Is a directory
rm: cannot remove `/sys/fs/ecryptfs/version': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/inode_readahead_blks': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/mb_max_to_scan': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/delayed_allocation_blocks': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/max_writeback_mb_bump': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/mb_stream_req': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/mb_min_to_scan': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/mb_stats': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/trigger_fs_error': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/session_write_kbytes': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/lifetime_write_kbytes': Operation not permitted
# and so on..
J'ai arrêté la tâche et j'ai été soulagé lorsque j'ai découvert que le service de production était toujours en cours d'exécution. Malheureusement, le serveur n'accepte plus ma clé publique ou mon mot de passe pour tout utilisateur via SSH.
Comment progresseriez-vous à partir d'ici? Je vais nager dans un océan de barbelés pour récupérer cet accès SSH.
Le serveur exécute Ubuntu-12.04 et est hébergé chez Hetzner.
Démarrez dans le système de sauvetage fourni par Hetzner et vérifiez les dégâts que vous avez causés.
Transférez tous les fichiers vers un emplacement sûr et redéployez le serveur par la suite.
J'ai bien peur que ce soit la meilleure solution dans votre cas.
Le fait est? À ce stade, il n'y a pas de solution automatique simple/facile pour cela. La récupération de données est un science et même les outils communs de base ont besoin de quelqu'un pour s'asseoir et s'assurer que les données sont là. Si vous vous attendez à récupérer de cela sans temps d'immobilisation massifs, vous allez être déçu.
Je suggère d'utiliser testdisk o un outil de récupération spécifique au système de fichiers. Essayez un système, voyez s'il fonctionne, etc. Il n'y a pas de véritable moyen d'automatiser le processus mais vous pouvez probablement soigneusement le faire par lots.
Cela dit, il y a quelques choses très effrayantes dans les questions et commentaires qui devraient faire partie de vos rapports après action.
Tout d'abord, vous avez exécuté la commande partout sans la vérifier au préalable. Exécutez une commande sur une case. Puis quelques-uns, puis plus. Fondamentalement, si quelque chose se passe mal, il vaut mieux que cela affecte un pe plutôt que tous vos systèmes.
Deuxièmement
@Tim comment faire une sauvegarde sans monter un lecteur distant sur le serveur?
Me fait peur. Les sauvegardes unidirectionnelles au niveau du fichier sont un problème résol. Rsync peut être utilisé pour conserver les autorisations et copier les fichiers à sens unique vers un site de sauvegarde. Par accident quelque chose? Réinstallez (de préférence automatiquement) rsync et les choses fonctionnent. À l'avenir, vous pourrez utiliser des instantanés au niveau du système de fichiers avec des instantanés btrfs ou zfs et les envoyer pour les sauvegardes au niveau du système. En fait, je jouerais avec la séparation des serveurs d'applications, des bases de données et du stockage et j'introduirais le principe du moindre privilège afin de répartir le risque de quelque chose comme ça ..
Je sais qu'il y a tout ce que je peux faire. Je dois maintenant penser à me protéger
Après que quelque chose soit arrivé, c'est le pire moment pour y penser.
Que pouvons-nous en tirer?
- Les sauvegardes sauvegardent les données. Possiblement des carrières.
- Si vous avez un outil et que vous ne savez pas ce qu'il peut faire, c'est dangereux. Un jedi peut faire des choses incroyables avec un sabre laser. Une salle pleine de chimpanzés avec des sabres laser ... deviendrait désordonnée.
N'exécutez jamais une commande partout à la fois. Séparez les machines de test et de production, et de préférence faites les machines de production par étapes. Il vaut mieux réparer 1 ou 10 machines plutôt que 100 ou 1000.
Commandes de vérification double et triple. Il n'y a aucune honte à demander à un collègue de vérifier deux fois "hé, je suis sur le point de faire un disque dur, pourriez-vous vérifier la raison pour que je ne finisse pas par essuyer un disque dur?". Un emballage pourrait également aider, mais rien ne vaut un jeu d'yeux moins fatigué.
Que pouvez-vous faire maintenant? Envoyez un e-mail aux clients. Faites-leur savoir qu'il y a des temps d'arrêt et des pannes catastrophiques. Parlez à vos supérieurs, juridiques, commerciaux et autres et voyez comment vous pouvez atténuer les dommages. Commencez à planifier la récupération et, si nécessaire, vous devrez, au mieux, embaucher des mains supplémentaires. Au pire, prévoyez de dépenser beaucoup d'argent pour la reprise. À ce stade, vous allez travailler à atténuer les retombées ainsi que les correctifs techniques.
Lorsque vous supprimez des éléments avec rm -rf --no-preserve-root, c'est presque impossible à récupérer. Il est très probable que vous ayez perdu tous les fichiers importants.
Comme @ faker l'a dit dans sa réponse, la meilleure solution consiste à transférer les fichiers vers un emplacement sûr et à redéployer le serveur par la suite.
Pour éviter des situations similaires à l'avenir, je vous suggère:
Effectuez des sauvegardes toutes les semaines ou au moins toutes les deux semaines. Cela vous aiderait à récupérer le service affecté avec le moins de MTTR possible.
Ne fonctionne pas en tant que root lorsqu'il n'est pas nécessaire . Et toujours réfléchissez bien avant de faire quoi que ce soit. Je vous suggère également d'installer safe-rm .
Ne saisissez pas d'options que vous n'avez pas l'intention d'invoquer , telles que
--no-preserve-rootou--permission-to-kill-kittens-explicitly-granted, d'ailleurs.
J'ai eu le même problème mais juste en testant avec un disque dur, j'ai tout perdu. Je ne sais pas si ce sera utile mais n'installez rien, n'écrasez pas vos données, vous devez monter vos disques durs et lancer quelques analyses judiciaires des outils tels que l'autopsie, photorec, Testdisk.
Je recommande fortement Testdisk, avec certaines commandes de base, vous pouvez récupérer vos données si vous ne les avez pas écrasées.
La meilleure façon de résoudre un problème comme celui-ci est de ne pas l'avoir en premier lieu.
N'entrez pas manuellement une commande "rm -rf" qui a une barre oblique dans la liste des arguments. (Mettre de telles commandes dans un script Shell avec de très bonnes routines de validation/raison pour vous protéger de faire quelque chose de stupide est différent.)
Ne le fais pas.
Déjà. Si vous pensez que vous devez le faire, vous ne réfléchissez pas suffisamment.
Au lieu de cela, remplacez votre répertoire de travail par le parent du répertoire à partir duquel vous souhaitez commencer la suppression, de sorte que la cible de la commande rm ne nécessite pas de barre oblique:
cd/mnt
Sudo rm -rf hetznerbackup
J'essaierais de récupérer la machine de sauvegarde, où toutes les copies étaient stockées:
- 1ère étape - Effectuez une sauvegarde de ces disques "de sauvegarde" effacés avec la commande
dd. - 2ème étape - Utilisez
testdiskpour récupérer des fichiers.
Disons donc que vous voulez récupérer 1 To, vous aurez besoin de 2 To supplémentaires, 1 To pour la sauvegarde (1ère étape) plus 1 To pour la récupération (2e étape).
J'ai fait une erreur similaire avec l'alias rm -fr [téléphone a sonné] et cd vers le précieux répertoire. Maintenant, je pense toujours à deux fois et revérifie quelques fois avant d'utiliser la commande rm ou dd.
Comme mentionné dans une autre réponse, Hetzner dispose d'un système de sauvetage. Il comprend à la fois une option netboot avec accès ssh ainsi qu'une applet Java pour vous donner écran et clavier sur votre vserver.
Si vous souhaitez récupérer autant que possible, redémarrez le serveur dans le système netboot, puis connectez-vous et téléchargez une image du système de fichiers en lisant à partir de l'inode de périphérique approprié.
Je pense que quelque chose comme ça devrait fonctionner:
ssh root@Host cat /dev/sda > server.img
Bien sûr, la redirection est effectuée par le shell avant l'appel de la commande ssh, donc server.img est un fichier local. Si vous souhaitez uniquement le système de fichiers racine et non le disque complet, remplacez sda par sda3 en supposant que vous utilisez la même image que moi.
Comment progresseriez-vous à partir d'ici?
Je jurerais d'utiliser rm pour le reste de ma vie et je pense que c'est fou que trash-cli ne soit pas la commande de suppression par défaut sur les systèmes nix.
https://github.com/andreafrancia/trash-cli
Je voudrais m'assurer que c'est la première chose que j'installe sur un tout nouveau système et alias rm à quelque chose qui dit aux gens d'utiliser trash-cli au lieu. Il comprendrait également une note sur un autre alias qui exécute réellement /bin/rm mais leur dit d'éviter de l'utiliser dans la plupart des cas.
:( Histoire vraie
Je conseille dans ce cas de démonter et d'utiliser debugfs , et avec l'aide de lsdel vous pouvez lister tous les fichiers récemment supprimés, qui n'ont pas été nettoyés des journaux puis vider les fichiers nécessaires. Lien de recherche rapide pour le même: http://www.linuxvoodoo.com/resources/howtos/debugfs
j'espère que cela aidera quelqu'un. ;)
Et oui, une des suggestions est de faire un script, qui a déplacé ream rm vers real.rm et symlinc mv à rm ;)