Errore del lunedì mattina: sudo rm -rf --no-preserv-root /

Nota: le risposte e i commenti a questa domanda contengono contenuti di un'altra domanda simile che ha ricevuto molta attenzione da parte di media esterni ma si è rivelata una bufala domanda in una sorta di schema di marketing virale. Poiché non consentiamo l'abuso di ServerFault in questo modo, la domanda originale è stata eliminata e le risposte si sono unite a questa domanda.

Ecco una tragedia divertente. Questa mattina stavo facendo un po 'di manutenzione sul mio server di produzione, quando ho erroneamente eseguito il seguente comando:

sudo rm -rf --no-preserve-root /mnt/hetznerbackup /

Non ho individuato l'ultimo spazio prima /e pochi secondi dopo, quando gli avvertimenti stavano inondando la mia riga di comando, mi sono reso conto di aver appena premuto il pulsante di autodistruzione. Ecco un po 'di ciò che mi è bruciato negli occhi:

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

Ho interrotto l'attività e sono stato sollevato quando ho scoperto che il servizio di produzione era ancora in esecuzione. Purtroppo, il server non accetta più la mia chiave pubblica o password per nessun utente tramite SSH.

Come andresti avanti da qui? Nuoterò un oceano di filo spinato per riavere quell'accesso SSH.

Il server esegue Ubuntu-12.04 ed è ospitato su Hetzner.

Avvia il sistema di salvataggio fornito da Hetzner e controlla quale danno hai subito.
Trasferisci tutti i file in un luogo sicuro e ridistribuisci il server in seguito.

Temo che sia la soluzione migliore nel tuo caso.

Il fatto è? A questo punto, non esiste una soluzione automatica semplice / facile per questo. Il recupero dei dati è una scienza e anche gli strumenti di base e comuni hanno bisogno di qualcuno per sedersi e assicurarsi che i dati siano lì. Se ti aspetti di recuperare da questo senza enormi quantità di downtime, rimarrai deluso.

Suggerirei di utilizzare testdisk o qualche strumento di recupero specifico del file system. Prova un sistema, vedi se funziona e così via. Non esiste un modo reale per automatizzare il processo, ma probabilmente lo si può fare attentamente in batch.

Detto questo, ci sono alcune cose molto spaventose nelle domande e nei commenti che dovrebbero far parte dei rapporti post-azione.

Innanzitutto, hai eseguito il comando ovunque senza prima verificarlo. Esegui un comando su una casella. Quindi alcuni, poi altri. Fondamentalmente se qualcosa va storto, è meglio che influisca su alcuni piuttosto che su tutti i sistemi.

in secondo luogo

@Tim come fare un backup senza montare un'unità remota sul server?

Mi spaventa. I backup a senso unico a livello di file sono un problema risolto . Rsync può essere utilizzato per conservare le autorizzazioni e copiare i file in un modo in un sito di backup. Per caso qualcosa? Reinstalla (preferibilmente automaticamente) rsync indietro e le cose funzionano. In futuro, è possibile utilizzare snapshot a livello di file system con snapshot btrfs o zfs e spedirli per backup a livello di sistema. In realtà giocherei con la separazione di server delle applicazioni, database e archiviazione e introdurrei il principio del privilegio minimo in modo da dividere il rischio di qualcosa del genere ..

So che c'è qualcosa che posso fare. Ora devo pensare a come proteggermi

Dopo che è successo qualcosa è il momento peggiore per considerare questo.

Cosa possiamo imparare da questo?

1. I backup salvano i dati. Forse carriere.
2. Se hai uno strumento e non sei consapevole di ciò che può fare, è pericoloso. Un jedi può fare cose incredibili con una spada laser. Una stanza piena di scimpanzé con le spade laser ... diventerebbe confusa.

3. Non eseguire mai un comando ovunque contemporaneamente. Separare le macchine di prova e produzione e preferibilmente le macchine di produzione in più fasi. È meglio riparare 1 o 10 macchine anziché 100 o 1000.

4. Comandi di controllo doppio e triplo. Non c'è da vergognarsi nel chiedere a un collega di ricontrollare "ehi, sto per fare un disco, potresti fare un buon controllo, così non finisco per cancellare un disco?". Anche un wrapper può essere d'aiuto, ma nulla batte un paio di occhi meno stanchi.

Cosa puoi fare adesso? Invia un'email ai clienti. Fai sapere loro che c'è tempo morto e che ci sono fallimenti catastrofici. Parla con i tuoi superiori, legali, di vendita e simili e vedi come puoi mitigare il danno. Inizia a pianificare il recupero e, se necessario, dovrai assumere, nella migliore delle ipotesi, mani extra. Nel peggiore dei casi, pianificare di spendere molti soldi per il recupero. In questa fase, lavorerai per mitigare la caduta e per risolvere i problemi tecnici.

Quando elimini le cose con rm -rf --no-preserve-root, è quasi impossibile recuperarle. È molto probabile che tu abbia perso tutti i file importanti.

Come ha affermato @faker nella sua risposta, il miglior modo di agire è trasferire i file in un luogo sicuro e ridistribuire il server in seguito.

Per evitare situazioni simili in futuro, ti suggerisco di:

• Effettua i backup settimanalmente o almeno ogni due settimane. Ciò ti aiuterebbe a ripristinare il servizio interessato con il minor MTTR possibile.

• Non lavorare come root quando non è necessario . E pensaci sempre due volte prima di fare qualsiasi cosa. Suggerirei di installare anche safe-rm .

• Non digitare le opzioni che non intendi invocare , come --no-preserve-rooto --permission-to-kill-kittens-explicitly-granted, del resto.

Ho avuto lo stesso problema ma solo testando con un hard disk, ho perso tutto. Non so se sarà utile, ma non installare nulla , non sovrascrivere i tuoi dati , devi montare i tuoi dischi rigidi e lanciare alcuni strumenti forensi come autopsia, photorec, Testdisk.

Consiglio vivamente Testdisk, con alcuni comandi di base puoi recuperare i tuoi dati se non li hai sovrascritti.

Il modo migliore per risolvere un problema come questo è di non averlo in primo luogo.

Non immettere manualmente un comando "rm -rf" che presenta una barra nell'elenco degli argomenti. (Mettere tali comandi in uno script di shell con routine di validazione / sanità mentale davvero buone per proteggerti dal fare qualcosa di stupido è diverso.)

Basta non farlo.
Mai. Se pensi di doverlo fare, non stai pensando abbastanza.

Invece, cambia la tua directory di lavoro con il genitore della directory da cui intendi avviare la rimozione, in modo che la destinazione del comando rm non richieda una barra:

cd / mnt

sudo rm -rf hetznerbackup

Vorrei provare a ripristinare la macchina di backup, dove sono state memorizzate tutte le copie:

• 1 ° passo: eseguire un backup di questa unità "macchina di backup" cancellata con ddcomando.
• 2 ° passaggio: utilizzare testdiskper ripristinare i file.

Supponiamo quindi che tu voglia recuperare 1 TB, avrai bisogno di 2 TB extra, 1 TB per il backup (1 ° passaggio) più 1 TB per il ripristino (2 ° passaggio).

Ho fatto un errore simile con alias rm -fr [telefono squillato] e cd nella directory preziosa. Ora penso sempre due volte e ricontrollo un paio di volte prima di usare il comando rm o dd.

Come menzionato in un'altra risposta, Hetzner ha un sistema di salvataggio. Include sia un'opzione netboot con accesso ssh che un'applet java per darti schermo e tastiera sul tuo server virtuale.

Se si desidera ripristinare il più possibile, riavviare il server nel sistema netboot, quindi accedere e scaricare un'immagine del file system leggendo dall'inode del dispositivo appropriato.

Penso che qualcosa del genere dovrebbe funzionare:

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

Ovviamente il reindirizzamento viene eseguito dalla shell prima che il comando ssh sia invocato, quindi server.img è un file locale. Se si desidera solo il file system di root e non il disco pieno, sostituire sdada sda3supponendo che si sta utilizzando la stessa immagine come me.

Come andresti avanti da qui?

Vorrei giurare di usarlo rmper il resto della mia vita e pensare che sia follia che trash-cli non sia il comando di rimozione predefinito sui sistemi nix.

https://github.com/andreafrancia/trash-cli

Mi assicurerei che sia la prima cosa che installo su un sistema nuovo di zecca e alias rmsu qualcosa che dice trash-cliinvece alle persone di usare . Includerebbe anche una nota su un altro alias che viene effettivamente eseguito /bin/rmma dice loro di evitare di usarlo nella maggior parte dei casi.

:( Storia vera

Vorrei consigliare in tal caso che è smontare e utilizzare debugfs e con l'aiuto di lsdel è possibile elencare tutti i file rimossi di recente, che non sono stati ripuliti dalle riviste e quindi scaricare i file necessari. Link di ricerca veloce per lo stesso: http://www.linuxvoodoo.com/resources/howtos/debugfs

spero che possa aiutare qualcuno. ;)

E sì, una volta di suggerimenti è fare script, che ha spostato ream rm in real.rm e symlinc mv in rm ;)

Arresta tutti i processi del server e tutto ciò che può causare l'I / O del disco ... quindi esegui testdisk, dovrebbe essere nello stack del tuo software. Se si dispone di accesso fisico, utilizzare un livecd con testdisk.