Question Erreur du lundi matin: sudo rm -rf --no-conserve-root /


Remarque: les réponses et les commentaires à cette question contiennent le contenu d'une autre question similaire, qui a suscité beaucoup d'attention de la part des médias extérieurs, mais qui s'est révélée être une question de canular dans une sorte de système de marketing viral. Comme nous n'autorisons pas les abus de ServerFault de cette manière, la question d'origine a été supprimée et les réponses fusionnées avec cette question.


Voici une tragédie divertissante. Ce matin, je faisais un peu de maintenance sur mon serveur de production lorsque 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, alors que des avertissements inondaient ma ligne de commande, je me suis rendu compte que je venais d'appuyer sur le bouton d'autodestruction. Voici un peu de ce qui a brûlé dans mes 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 fonctionnait toujours. Malheureusement, le serveur n'accepte plus ma clé publique ou mon mot de passe pour aucun utilisateur via SSH.

Comment voulez-vous avancer à partir d'ici? Je vais nager un océan de fils barbelés pour récupérer cet accès SSH.

Le serveur exécute Ubuntu-12.04 et est hébergé chez Hetzner.


142
2018-04-07 06:39


origine


Restaurer à partir de sauvegardes. Honnêtement, c’est l’un de ces scénarios difficiles. - MadHatter
Comment vous tapez même --no-preserve-root accidentellement?! : -o - ThatGraemeGuy
Greame, les touches sont comme l'un à côté de l'autre. - MadHatter
Travail de mardi: cherchez un nouvel emploi;) Prenez comme exemple la raison pour laquelle les sauvegardes sont nécessaires. - TomTom
Cela me fait penser à quelque chose. Vous ne pouvez pas taper accidentellement --i-vraiment-méchant-supprimer-ma-racine-complète. - psusi


Réponses:


Démarrez dans le système de secours 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, puis redéployez le serveur.

J'ai bien peur que ce soit la meilleure solution dans votre cas.


92
2018-04-07 07:00



Regarde le bon côté des choses, au moins, il n’a aucun problème avec heartbleed! - metacom


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 de base communs ont besoin de quelqu'un pour s'asseoir et s'assurer que les données sont là. Si vous vous attendez à ce que vous récupériez votre situation sans temps d'arrêt massif, vous serez déçu.

Je suggère d'utiliser testdisk ou un outil de récupération spécifique au système de fichiers. Essayez un système, voyez si cela fonctionne, et ainsi de suite. Il n'y a pas de véritable moyen d'automatiser le processus mais vous pouvez probablement soigneusement faites-le par lots.

Cela dit, les questions et commentaires contiennent quelques éléments très effrayants 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écuter une commande sur une boîte. Puis quelques-uns, puis plus. Fondamentalement, si quelque chose ne va pas, il vaut mieux que cela affecte un peu 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 fichier sont problème résolu. Rsync peut être utilisé pour conserver les permissions et copier les fichiers une manière sur un site de sauvegarde. Accidentellement quelque chose? Réinstallez (de préférence automatiquement) rsync, et tout fonctionne. À l'avenir, vous pourrez utiliser des instantanés au niveau du système de fichiers avec des instantanés btrfs ou zfs et à les expédier pour des sauvegardes au niveau du système. En fait, je jouais avec la séparation des serveurs d'applications, des bases de données et du stockage et introduisais le principe du moindre privilège afin de diviser le risque.

Je sais qu'il y a tout ce que je peux faire. J'ai maintenant besoin de penser à comment me protéger

Après quelque chose est arrivé le pire moment pour envisager cela.

Que pouvons-nous apprendre de cela?

  1. Les sauvegardes sauvegardent les données. Éventuellement des carrières.
  2. Si vous avez un outil et ne savez pas si ce qu'il peut faire, c'est dangereux. Un jedi peut faire des choses incroyables avec un sabre laser. Une salle remplie de chimpanzés au sabre laser ... serait en désordre.
  3. Ne jamais exécuter 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 est préférable de réparer 1 ou 10 machines plutôt que 100 ou 1000.

  4. Double et triple contrôle des commandes. Il n’est pas honteux de demander à un collègue de revérifier "hé, je suis sur le point de conduire un lecteur, pourriez-vous vérifier cela afin que je ne finisse pas par essuyer un lecteur?". Un emballage peut également aider, mais rien ne vaut un regard moins fatigué.

Que pouvez-vous faire maintenant? Envoyez un courrier électronique aux clients. Dites-leur qu'il y a des temps d'arrêt et des défaillances catastrophiques. Parlez à vos supérieurs hiérarchiques, aux services juridiques, aux ventes, etc., et voyez comment vous pouvez limiter les dégâts. Commencez à planifier la récupération et, au besoin, vous devrez au mieux engager des mains supplémentaires. Au pire, prévoyez dépenser beaucoup d’argent pour la reprise. A ce stade, vous allez travailler à atténuer les retombées et à apporter des correctifs techniques.


219
2018-04-11 08:02



@MarcoMarsala Si vous avez monté quoi que ce soit avant d'utiliser rsync, vous ne le faisiez pas correctement. Vous devriez utiliser rsync sur ssh. - Michael Hampton♦
J'ajouterais à cette excellente réponse: Éloignez-vous de l'ordinateur. N'essayez pas de réparer quoi que ce soit tant que vous n'êtes pas calmé. Vous envisagez déjà des temps d'arrêt sérieux; prendre le temps de réfléchir au lieu de détruire encore plus vos systèmes (comme dans le dd question ci-dessus) ne va pas aggraver les choses. - Jenny D
Une idée de pourquoi la commande a réellement couru? Si $foo et $bar étaient tous deux indéfinis, rm -rf / aurait dû errer avec le --no-preserve-root message. La seule façon dont je peux penser que cela aurait effectivement fonctionné sur une machine CentOS7 est si $bar évalué à *, alors ce qui a été couru était rm -rf /*. - terdon
J'adore le stylisme dans "Accidentellement quelque chose?". Cela doit signifier que le mot "supprimé" a été "supprimé" ou "supprimé" accidentellement. - sehe
@MarcoMarsala bien au moins vous êtes célèbre maintenant independent.co.uk/life-style/gadgets-and-tech/news/… - Martin Smith


Lorsque vous supprimez des éléments avec rm -rf --no-preserve-root, il est presque impossible de récupérer. Il est très probable que vous ayez perdu tous les fichiers importants.

Comme @ Faker Dans sa réponse, la meilleure solution consiste à transférer les fichiers dans un emplacement sûr, puis à redéployer le serveur.

Pour éviter des situations similaires à l'avenir, je vous suggère:

  • Faire des sauvegardes hebdomadaire ou au moins deux fois par semaine. Cela vous aiderait à restaurer le service concerné avec le moins possible de MTTR.

  • Ne fonctionne pas en tant que root quand il n'est pas nécessaire. Et toujours réfléchir à deux fois avant de faire quoi que ce soit. Je vous suggère également d'installer coffre-fort.

  • Ne tapez pas les options que vous n'avez pas l'intention d'invoquer, tel que --no-preserve-root ou --permission-to-kill-kittens-explicitly-granted, d'ailleurs.


90
2018-04-07 07:57



De même, à moins que vous ne le pensiez VRAIMENT, n’ajoutez pas le --please-destroy-my-driveparamètre à hdparm. - MikeyB
J'aimerais ajouter; "Vérifiez trois fois vos arguments (et options) lorsque vous travaillez en tant que root", "Vérifiez votre CurrentWorkingDirectory (avant de faire quelque chose comme rm -rf *)" et "Utilisez des chemins complets pour les commandes (ne pas relayer sur $ PATH). - Baard Kopperud


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 ça va être utile mais ne rien installer, ne pas écraser vos données, vous devez monter vos disques durs et lancer des outils d’informatique judiciaire tels que l’autopsie, photorec, Testdisk.

Je recommande fortement Testdisk, avec quelques commandes de base, vous pouvez récupérer vos données si vous ne les écrasez pas.


47
2018-04-11 08:17



Je recommanderais sans hésiter le stockage hors ligne, dans la mesure du possible, et le remontage en lecture seule si vous le pouvez. Que ce soit avec une instance de livesisk ou une autre instance de serveur. - mhouston100
J'envisagerais même de faire une copie bitdd du disque d'origine sur un nouveau disque à partir d'un montage en lecture seule du disque d'origine, par sécurité. - Jim
«Ces outils ne récupèrent pas le nom de fichier et le chemin» Oui. Sur les 3 outils mentionnés, un seul (Photorec) effectue la gravure. - Andrea Lazzarotto


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" comportant une barre oblique dans la liste des arguments. (Mettre de telles commandes dans un script shell avec de très bonnes routines de validation / santé mentale pour vous protéger de quelque chose de stupide est différent.)

Juste ne le fais pas.
Déjà. Si vous pensez avoir besoin de le faire, vous ne réfléchissez pas assez.

À la place, changez votre répertoire de travail en parent du répertoire à partir duquel vous souhaitez lancer la suppression, de sorte que la cible de la commande rm ne nécessite pas de barre oblique:

cd / mnt

sudo rm -rf hetznerbackup


33
2018-04-07 21:22



Je mets toujours le -rf à la fin de la liste d'arguments, donc rm /bla/foo/bar -rf. Au moins, je n’ai pas trop de problèmes lorsque j’appuie sur retour après avoir tapé le mot rm / partie. - Jens Timmerman
De même, lors de la suppression des fichiers "* ~", je tape d'abord le tilde, puis ajoute l'astérisque. - tekknolagi
Vous préférez donc supprimer votre maison plutôt que tout ce qui se trouve dans le répertoire actuel?!? - greg0ire
@ greg0ire Non, je pense qu'il voulait dire que dans /mnt/hetznerbackup, il a dû utiliser "/" pour marquer tout ce qui se trouve dans ce dossier .. mais du parent, seulement hetznerbackup est suffisant, sans barres obliques. - T.Todua
@tazotodua: je faisais référence au commentaire de tekknolagi - greg0ire


Je voudrais essayer de récupérer la machine de sauvegarde, où toutes les copies ont été stockées:

  • 1ère étape - Faites une sauvegarde de cette "machine de sauvegarde" effacée avec dd comand.
  • 2ème étape - Utilisation testdisk pour récupérer des fichiers.

Supposons donc que vous souhaitiez 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 (2ème étape).

J'ai fait la même erreur avec alias rm -fr [téléphone sonné] et cd dans un répertoire précieux. Maintenant, je pense toujours à deux fois et revérifier quelques fois avant d’utiliser la commande rm ou dd.


16
2018-04-11 00:32



En gros, votre disque a été mis à zéro. Cela rend vraiment beaucoup plus difficile de récupérer. Il existe une bonne raison pour que l'OP suggère d'essayer testdisk et de récupérer en premier, et bien que la syntaxe de dd puisse être un peu étrange, c'est une bonne raison de vérifier deux ou trois fois avant d'exécuter la commande. Vous avez seulement essuyé un serveur, non? - Journeyman Geek
Vous pouvez toujours récupérer, dépend de combien de temps vous avez permis dd pour effacer votre dernière chance. - Abc Xyz
désolé de dire ça, mais je me sens énormément troll dans cette question ... - tymik
espérons que vous vous sentirez petit troll dans la réponse :) - Abc Xyz
Pour être honnête. Je ne suis pas sûr que tu sois réel. Si vous êtes, vous êtes probablement dans le mauvais travail ... - leftcase


Comme mentionné dans une autre réponse, Hetzner a un système de sauvetage. Il inclut à la fois une option netboot avec accès ssh et 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 sur 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 marcher:

ssh root@host cat /dev/sda > server.img

Bien sûr, la coque est redirigée avant que la commande ssh ne soit invoquée, 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.


7
2018-04-07 07:54



pourrait peut-être être: ssh root@host cat /dev/sda | gzip -c - > /path/to/dir_on_huge_partition/server.img.gz (le gzip à la volée va ou ne va pas aider en fonction du contenu du système de fichiers ...) - Olivier Dulac
@OlivierDulac En utilisant cette méthode, gzip enverrait les données non compressées sur le réseau, puis les compresserait du côté de la réception. Je suppose que le résultat que vous souhaitiez obtenir était de compresser les données tout en les transférant. L'image locale peut être stockée compressée ou non, mais les outils que vous souhaitez appliquer à cette image ultérieurement ne fonctionneront pas avec la version compressée. Si vous souhaitez uniquement compresser les données en transit, vous pouvez utiliser la fonctionnalité de compression dans ssh. Il peut être activé avec -C s'il n'est pas déjà activé dans votre configuration. - kasperd
J'essayais plus de réduire la taille du fichier. Mais si vous voulez économiser de la bande passante (bonne idée): ajoutez simplement des guillemets: ssh root@host "cat /dev/sda | gzip -c - " > /path/to/dir_on_huge_partition/server.img.gz (l'option -c de ssh est généralement bonne aussi, mais vous aurez toujours besoin de compresser à la fin, car ssh compressera uniquement à l'entrée de son tunnel et se décompressera avant l'envoi à stdout) - Olivier Dulac