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

146

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'avais 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 nagerai 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.

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

Réponses:

95

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.

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

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 une science et même les outils de base les plus courants 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érerais 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 vraiment de moyen d'automatiser le processus, mais vous pouvez probablement le faire avec précaution 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écutez une commande sur une boîte. Puis quelques-uns, puis plus. Fondamentalement, si quelque chose ne va pas, il est préférable de l’affecter à quelques - uns plutôt qu’à 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 un problème résolu . Rsync peut être utilisé pour conserver les autorisations et copier les fichiers d' 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 à leur livraison pour les 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. Peut-être 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 morts 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 votre rétablissement et, au besoin, vous devrez au mieux engager des mains supplémentaires. Au pire, prévoyez dépenser beaucoup d’argent pour la reprise. À ce stade, vous allez travailler à atténuer les retombées et à apporter des correctifs techniques.

Compagnon geek
la source
9
@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
67
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 ddcas précédent), ne va pas aggraver les choses.
Jenny D
22
Avez-vous une idée de la raison pour laquelle la commande a été exécutée? Si $fooet $barétaient tous deux indéfinis, rm -rf /aurait dû se tromper avec le --no-preserve-rootmessage. La seule façon dont je peux penser que cela aurait fonctionné sur une machine CentOS7 est si elle est $barévaluée *, ce qui a été exécuté rm -rf /*.
terdon
9
J'adore le stylisme dans "Accidentellement quelque chose?". Cela doit signifier que le mot "supprimé" a été "supprimé" ou "supprimé" accidentellement.
Voir
20
@MarcoMarsala bien au moins vous êtes célèbre maintenant independent.co.uk/life-style/gadgets-and-tech/news/…
Martin Smith
92

Lorsque vous supprimez des éléments rm -rf --no-preserve-root, il est presque impossible de les 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 dans un emplacement sûr, puis à redéployer le serveur.

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

  • Effectuez des sauvegardes hebdomadaires ou au moins toutes les deux semaines. Cela vous aiderait à restaurer le service concerné avec le moins possible de MTTR.

  • Ne travaillez pas en tant que root quand vous n'en avez pas besoin . Et réfléchissez toujours à deux fois avant de faire quoi que ce soit. Je vous suggère également d'installer safe-rm .

  • N'entrez pas d'options que vous n'avez pas l'intention d'invoquer , telles que --no-preserve-rootou --permission-to-kill-kittens-explicitly-grantedd'ailleurs.

Amal Murali
la source
18
De même, à moins que vous n'y pensiez VRAIMENT, ne pas ajouter le --please-destroy-my-driveparamètre à hdparm.
MikeyB
3
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
47

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 cela vous sera utile, mais n'installez rien , n'écrivez pas vos données , vous devez monter vos disques durs et lancer des outils d'investigation, 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.

Octo
la source
8
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
2
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
3
«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
34

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

Monty Harder
la source
31
Je mets toujours le -rf à la fin de la liste d'arguments, donc rm /bla/foo/bar -rf. Au moins, de cette façon, je ne me pose pas beaucoup de problèmes lorsque je clique volontiers sur retour après avoir tapé la rm /partie.
Jens Timmerman
5
De même, lors de la suppression des fichiers "* ~", je tape d'abord le tilde, puis ajoute l'astérisque.
Tekknolagi
4
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, à l'intérieur /mnt/hetznerbackup, il devait utiliser "/" pour marquer tout ce qui se trouve dans ce dossier .. mais de parent, hetznerbackupc'est suffisant, sans barre oblique.
T.Todua
1
@tazotodua: Je faisais référence au commentaire de
tekknolagi
16

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 la commande dd.
  • 2ème étape - Utilisez testdiskpour récupérer des fichiers.

Disons 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 (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.

Abc Xyz
la source
6
En gros, votre disque a été mis à zéro. Cela rend vraiment beaucoup plus difficile de récupérer. Il y a 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
1
Vous pouvez toujours récupérer, cela dépend du temps que vous avez laissé ddpour effacer votre dernière chance.
Abc Xyz
129
désolé de dire ça, mais je me sens énormément troll dans cette question ...
tymik
3
espérons que vous vous sentirez un petit troll dans la réponse :)
Abc Xyz
5
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 ...
valise gauche
7

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 un écran et un 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-le sdaen sda3supposant que vous utilisez la même image que moi.

Kasperd
la source
pourrait ê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 selon le 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 tout ce que vous voulez réaliser est la compression des données en transit, vous pouvez utiliser la fonctionnalité de compression dans ssh. Il peut être activé avec -Cs'il n'est pas déjà activé dans votre configuration.
Kasperd
2
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 auriez quand même besoin de compresser à la fin, car ssh ne se compressera qu'à l'entrée de son tunnel et décompressez avant d'envoyer sur stdout)
Olivier Dulac
2

Comment voulez-vous avancer à partir d'ici?

Je jurerais de l'utiliser rmpour le reste de ma vie et penserais qu'il 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 rmque les utilisateurs doivent l'utiliser à la trash-cliplace. Il inclurait également une note sur un autre alias qui fonctionne réellement, /bin/rmmais leur dit d'éviter de l'utiliser dans la plupart des cas.

:( Histoire vraie

Gerry
la source
2
D'après mon expérience, ces types d'outils constituent davantage une nuisance qu'une aide réelle - tôt ou tard, et après quelques jurons, vous les supprimerez. Cela peut convenir à un poste de travail, mais dans beaucoup, voire la plupart des situations, lorsque vous effectuez un travail administratif sur un serveur, vous devez réellement supprimer les données, et non simplement les déplacer ailleurs (et si tel était le cas, utilisez simplement mv. au lieu). De plus, le déplacement automatique des données vers un dossier de corbeille peut entraîner de graves problèmes en soi (par exemple, la corbeille ne se trouve pas sur le même système de fichiers, la sécurité).
vendredi
@maetthu Oh, bien sûr, les choses sont supprimées après avoir été à la poubelle pendant un certain nombre de jours. Ubuntu Desktop s’applique aux articles qui ont été jetés à la corbeille plus de 30 jours. Sur un serveur, vous voudrez peut-être quelque chose de plus court, par exemple. trash-empty 5dans un cron. Le but est de vous accorder un délai de grâce, car les humains font des erreurs.
Gerry
N’est-il pas préférable d’avoir un plan de reprise après sinistre opérationnel au lieu de bannir les outils essentiels du système?
user292812
@ user292812 Je n'ai pas suggéré d'interdire / bin / rm, mais simplement que ce ne soit pas la première option dans la plupart des cas (notez l'alias / bin / rm). Votre question suggère également un faux choix entre la reprise après sinistre et une option de suppression conviviale. Vous devriez avoir les deux.
Gerry
1
Un processus de suppression en deux étapes peut éviter beaucoup de problèmes: 1. déplacez-vous dans la corbeille (verbalement), 2. videz la corbeille. J'appelle un tel script "rm" et cela m'a évité de supprimer accidentellement des choses importantes plusieurs fois.
Sam Watkins
1

Je conseillerais 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 dump des fichiers nécessaires. Lien de recherche rapide pour les mêmes: http://www.linuxvoodoo.com/resources/howtos/debugfs

espérons que cela aidera quelqu'un. ;)

Et oui, une fois de suggestions est de faire un script, ce qui a déplacé ream rm à real.rm et symlinc mv à rm ;)

BiG_NoBoDy
la source
-2

Arrêtez tous les processus de serveur et tout ce qui peut causer une entrée / sortie sur disque ... puis lancez testdisk, il devrait se trouver dans la pile de logiciels. Si vous avez un accès physique, utilisez un livecd avec testdisk.

Saint Crusty
la source
1
Je ne comprends pas vraiment pourquoi vous pensez que trois réponses fournissant exactement la même suggestion ne suffisent pas?
Kasperd