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

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.

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.

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.

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.

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

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.

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.

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

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 ;)

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.