Kesalahan Senin pagi: sudo rm -rf --no-preserve-root /

146

Harap dicatat: Jawaban dan komentar untuk pertanyaan ini berisi konten dari yang lain, pertanyaan serupa yang telah menerima banyak perhatian dari media luar tetapi ternyata menjadi pertanyaan bohong dalam beberapa jenis skema pemasaran viral. Karena kami tidak mengizinkan ServerFault disalahgunakan sedemikian rupa, pertanyaan asli telah dihapus dan jawaban digabungkan dengan pertanyaan ini.

Ini tragedi yang menghibur. Pagi ini saya melakukan sedikit pemeliharaan pada server produksi saya, ketika saya keliru mengeksekusi perintah berikut:

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

Saya tidak melihat ruang terakhir sebelum /dan beberapa detik kemudian, ketika peringatan membanjiri baris perintah saya, saya menyadari bahwa saya baru saja menekan tombol penghancuran diri. Inilah sedikit dari apa yang membakar mataku:

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

Saya menghentikan tugas dan merasa lega ketika saya menemukan bahwa layanan produksi masih berjalan. Sayangnya, server tidak lagi menerima kunci publik atau kata sandi saya untuk pengguna mana pun melalui SSH.

Bagaimana Anda bergerak maju dari sini? Saya akan berenang di lautan kawat berduri untuk mendapatkan akses SSH itu kembali.

Server menjalankan Ubuntu-12.04 dan di-host di Hetzner.

ubuntu-12.04 disaster-recovery hetzner

— Jonas Nielsen
sumber

48

Pulihkan dari cadangan. Sejujurnya, ini adalah salah satu dari skenario tanpa jalan keluar yang mudah.

— MadHatter

310

Bagaimana Anda mengetik --no-preserve-rootsecara tidak sengaja ?! : -o

— ThatGraemeGuy

144

Greame, kuncinya seperti di sebelah kanan satu sama lain.

— MadHatter

38

Pekerjaan hari Selasa: Cari pekerjaan baru;) Ambillah sebagai pelajaran mengapa cadangan diperlukan.

— TomTom

43

Ini benar-benar terasa seperti mengolok-olok saya. Anda tidak dapat secara tidak sengaja mengetik --i-really-mean-delete-my-whole-root.

— psusi

95

Boot ke sistem penyelamatan yang disediakan oleh Hetzner dan periksa kerusakan apa yang telah Anda lakukan.
Transfer semua file ke lokasi yang aman dan gunakan kembali server setelahnya.

Saya khawatir itu adalah solusi terbaik dalam kasus Anda.

— pemalsu
sumber

102

lihat sisi baiknya, setidaknya dia tidak punya masalah dengan patah hati!

— metacom

222

Faktanya adalah? Pada titik ini, tidak ada perbaikan otomatis sederhana / mudah untuk ini. Pemulihan data adalah ilmu dan bahkan dasar, alat umum membutuhkan seseorang untuk duduk dan memastikan data ada di sana. Jika Anda berharap untuk pulih dari ini tanpa downtime dalam jumlah besar, Anda akan kecewa.

Saya sarankan menggunakan testdisk atau alat pemulihan khusus sistem file. Coba satu sistem, lihat apakah itu berfungsi, dan sebagainya. Tidak ada cara nyata untuk mengotomatiskan proses tetapi Anda mungkin dapat melakukannya dengan hati - hati dalam batch.

Yang mengatakan, ada beberapa hal yang sangat menakutkan dalam pertanyaan dan komentar yang seharusnya menjadi bagian dari laporan setelah tindakan Anda.

Pertama, Anda menjalankan perintah di mana-mana tanpa memeriksanya terlebih dahulu. Jalankan perintah pada satu kotak. Lalu beberapa, lalu lebih banyak. Pada dasarnya jika terjadi kesalahan, lebih baik memengaruhi beberapa daripada semua sistem Anda.

Kedua

@Tim cara melakukan pencadangan tanpa memasang drive jarak jauh di server?

Membuatku takut. Pencadangan tingkat satu arah file adalah masalah yang terpecahkan . Rsync dapat digunakan untuk mempertahankan izin dan menyalin file satu arah ke situs cadangan. Sesuatu yang tidak sengaja? Instal ulang (sebaiknya secara otomatis) kembali rsync, dan semuanya berfungsi. Di masa depan, Anda mungkin menggunakan snapshot tingkat sistem file dengan snapshot btrf atau zfs dan mengirimkannya untuk cadangan tingkat sistem. Saya benar-benar bermain-main dengan memisahkan aplikasi server, database dan penyimpanan dan memperkenalkan prinsip privilege paling tidak sehingga Anda akan membagi risiko sesuatu seperti ini ..

Saya tahu ada yang bisa saya lakukan. Sekarang saya perlu berpikir bagaimana melindungi diri saya sendiri

Setelah sesuatu terjadi adalah waktu terburuk untuk mempertimbangkan ini.

Apa yang bisa kita pelajari dari ini?

Cadangan menyimpan data. Mungkin karier.
Jika Anda memiliki alat dan tidak tahu apa yang bisa dilakukan, itu berbahaya. Jedi dapat melakukan hal-hal menakjubkan dengan lightsaber. Satu ruangan penuh simpanse dengan lightsabers ... akan berantakan.
Jangan pernah menjalankan perintah di mana pun sekaligus. Pisahkan mesin uji dan produksi, dan sebaiknya lakukan mesin produksi secara bertahap. Lebih baik memperbaiki 1 atau 10 mesin daripada 100 atau 1000.
Perintah periksa dua dan tiga. Tidak ada salahnya meminta rekan kerja untuk mengecek "hei, saya akan melakukan drive, bisakah Anda waras memeriksa ini sehingga saya tidak berakhir dengan menghapus drive?". Pembungkus mungkin membantu juga, tetapi tidak ada yang mengalahkan mata yang kurang lelah.

Apa yang bisa kamu lakukan sekarang? Kirim email ke pelanggan. Biarkan mereka tahu ada waktu henti dan ada kegagalan besar. Bicaralah dengan atasan Anda, legal, penjualan dan semacamnya dan lihat bagaimana Anda dapat mengurangi kerusakan. Mulailah merencanakan pemulihan, dan jika perlu, Anda harus, paling-paling, menyewa tangan tambahan. Paling buruk, rencanakan untuk menghabiskan banyak uang untuk pemulihan. Pada tahap ini, Anda akan bekerja untuk mengurangi kejatuhan serta perbaikan teknis.

— Journeyman Geek
sumber

9

@MarcoMarsala Jika Anda memasang sesuatu sebelum menggunakan rsync, Anda tidak melakukannya dengan benar. Anda harus menggunakan rsync di atas ssh.

— Michael Hampton

67

Saya akan menambahkan jawaban yang sangat bagus ini: Menjauhlah dari komputer. Jangan mencoba memperbaiki apa pun sampai Anda sudah tenang. Anda sudah melihat beberapa downtime yang serius; meluangkan waktu untuk memikirkan segalanya alih-alih merusak sistem Anda lebih jauh (seperti dalam ddmasalah di atas) tidak akan memperburuknya.

— Jenny D

22

Adakah yang tahu mengapa perintah itu benar-benar dijalankan? Jika $foodan $barkeduanya tidak terdefinisi, rm -rf /seharusnya ada kesalahan dengan --no-preserve-rootpesan. Satu-satunya cara saya bisa memikirkan bahwa ini akan benar-benar bekerja pada mesin CentOS7 adalah jika $bardievaluasi *, jadi apa yang dijalankan rm -rf /*.

— terdon

9

Saya suka gaya dalam "Kebetulan sesuatu?". Itu berarti kata "dihapus" telah "dihapus" atau "dijatuhkan" secara tidak sengaja.

— sehe

20

@ MarscoMarsala setidaknya Anda terkenal sekarang independent.co.uk/life-style/gadgets-and-tech/news/…

— Martin Smith

92

Ketika Anda menghapus barang dengan rm -rf --no-preserve-root, hampir tidak mungkin untuk pulih. Sangat mungkin Anda kehilangan semua file penting.

Seperti @faker katakan dalam jawabannya, tindakan terbaik adalah mentransfer file ke lokasi yang aman dan memindahkan server setelahnya.

Untuk menghindari situasi serupa di masa mendatang, saya sarankan Anda:

Ambil cadangan setiap minggu, atau setidaknya setiap dua minggu. Ini akan membantu Anda mendapatkan kembali layanan yang terpengaruh dengan MTTR seminimal mungkin.
Jangan bekerja sebagai root saat tidak diperlukan . Dan selalu berpikir dua kali sebelum melakukan sesuatu. Saya sarankan Anda juga menginstal safe-rm .
Jangan mengetikkan opsi yang tidak ingin Anda panggil , seperti --no-preserve-rootatau --permission-to-kill-kittens-explicitly-granted, dalam hal ini.

— Amal Murali
sumber

18

Demikian pula, kecuali Anda BENAR-BENAR BERARTI, jangan tambahkan --please-destroy-my-driveparameter hdparm.

— MikeyB

3

Saya ingin menambahkan; "Periksa tiga kali argumen Anda (dan opsi) ketika bekerja sebagai root", "Periksa CurrentWorkingDirectory Anda (sebelum melakukan sesuatu seperti rm -rf *)", dan "Gunakan jalur-penuh untuk perintah (jangan menyampaikan $ PATH).

— Baard Kopperud

47

Saya memiliki masalah yang sama tetapi hanya menguji dengan hard drive, saya telah kehilangan segalanya. Saya tidak tahu apakah itu akan berguna tetapi tidak menginstal apa pun , jangan menimpa data Anda, Anda perlu memasang hard drive Anda dan meluncurkan beberapa alat forensik seperti otopsi, photorec, Testdisk.

Saya sangat merekomendasikan Testdisk, dengan beberapa perintah dasar Anda dapat memulihkan data Anda jika Anda tidak menimpanya.

— Octo
sumber

8

Saya pasti akan merekomendasikan takign penyimpanan offline jika memungkinkan dan menginstal ulang sebagai 'hanya baca' jika Anda bisa. Baik dengan liveisk atau instance server lain.

— mhouston100

2

Saya bahkan akan mempertimbangkan untuk melakukan bitcopy dd dari disk asli ke disk baru dari mount read-only dari disk asli hanya untuk aman.

— Jim

3

«Alat-alat ini tidak akan memulihkan nama dan jalur file» Ya, benar. Dari 3 alat yang disebutkan, hanya satu (Photorec) yang melakukan ukiran.

— Andrea Lazzarotto

34

Cara terbaik untuk memperbaiki masalah seperti ini adalah dengan tidak memilikinya sejak awal.

Jangan secara manual memasukkan perintah "rm -rf" yang memiliki garis miring dalam daftar argumen. (Menempatkan perintah tersebut dalam skrip shell dengan rutinitas validasi / kewarasan yang sangat baik untuk melindungi Anda dari melakukan sesuatu yang bodoh berbeda.)

Tapi jangan lakukan itu.
Pernah. Jika Anda merasa perlu melakukannya, Anda tidak berpikir cukup keras.

Alih-alih, ubah direktori kerja Anda menjadi induk dari direktori tempat Anda bermaksud memulai penghapusan, sehingga target perintah rm tidak memerlukan garis miring:

cd / mnt

sudo rm -rf hetznerbackup

— Monty Harder
sumber

31

Saya selalu meletakkan -rf di akhir daftar argumen, jadi rm /bla/foo/bar -rf. Setidaknya dengan cara itu saya tidak mendapat banyak masalah ketika saya tekan kembali dengan sengaja setelah mengetik rm /bagian.

— Jens Timmerman

5

Demikian pula, saat menghapus file "* ~", saya ketik tilde terlebih dahulu, lalu tambahkan tanda bintang.

— tekknolagi

4

Jadi Anda lebih suka menghapus rumah Anda daripada semua yang ada di direktori saat ini?

— greg0ire

@ greg0ire Tidak, saya pikir dia ingin mengatakan, bahwa di dalam /mnt/hetznerbackup, dia harus menggunakan "/" untuk menandai semua yang ada di dalam folder itu .. tetapi dari orangtua, hanya hetznerbackupcukup, tanpa garis miring.

— T.Todua

1

@tazotodua: Saya merujuk pada komentar

— tekknolagi

16

Saya akan mencoba memulihkan mesin cadangan, tempat semua salinan disimpan:

Langkah 1 - Buat cadangan drive "mesin cadangan" yang terhapus ini dengan ddperintah.
Langkah 2 - Gunakan testdiskuntuk memulihkan file.

Jadi katakanlah Anda ingin memulihkan 1TB, Anda akan membutuhkan 2TB tambahan, 1TB untuk cadangan (langkah 1) ditambah 1TB untuk pemulihan (langkah 2).

Saya melakukan kesalahan yang sama dengan alias rm -fr [telepon berdering] dan cd ke direktori berharga. Sekarang saya selalu berpikir dua kali dan periksa kembali beberapa kali sebelum saya menggunakan perintah rm atau dd.

— Abc Xyz
sumber

6

Cukup banyak memusatkan disk Anda dengan melakukan itu. Itu serius membuat jauh lebih sulit untuk pulih. Ada alasan bagus OP menyarankan Anda mencoba menggunakan testdisk, dan memulihkan terlebih dahulu, dan sementara sintaks dd bisa sedikit aneh, itu alasan yang baik untuk memeriksa dua kali dan tiga kali sebelum Anda menjalankan perintah. Anda hanya menghapus satu server, bukan?

— Journeyman Geek

1

Anda masih bisa pulih, tergantung berapa lama Anda diizinkan dduntuk menghapus peluang terakhir Anda.

— Abc Xyz

129

maaf mengatakan itu, tetapi saya merasa troll besar dalam pertanyaan ini ...

— tymik

3

harap Anda merasakan troll kecil dalam jawabannya :)

— Abc Xyz

5

Sejujurnya. Saya tidak yakin Anda nyata. Jika ya, Anda mungkin berada di pekerjaan yang salah ...

— leftcase

7

Seperti disebutkan dalam jawaban lain, Hetzner memiliki sistem penyelamatan. Ini mencakup opsi netboot dengan akses ssh serta java applet untuk memberi Anda layar dan keyboard di vserver Anda.

Jika Anda ingin memulihkan sebanyak mungkin, reboot server ke sistem netboot dan kemudian login dan unduh gambar sistem file dengan membaca dari inode perangkat yang sesuai.

Saya pikir sesuatu seperti ini seharusnya bekerja:

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

Tentu saja pengalihan dilakukan oleh shell sebelum perintah ssh dipanggil, jadi server.img adalah file lokal. Jika Anda hanya menginginkan sistem file root dan bukan disk lengkap, ganti sdadengan sda3menganggap Anda menggunakan gambar yang sama dengan saya.

— kasperd
sumber

mungkin bisa: ssh root@host cat /dev/sda | gzip -c - > /path/to/dir_on_huge_partition/server.img.gz(the gzip on-the-fly akan atau tidak akan membantu tergantung pada apa isi dari filesystem itu ...)

— Olivier Dulac

@OlivierDulac Menggunakan gzip dengan cara itu akan mengirim data yang tidak terkompresi melalui jaringan dan kemudian kompres di sisi penerima. Saya berasumsi bahwa hasil yang ingin Anda capai adalah mengompres data saat sedang ditransfer. Gambar lokal dapat disimpan terkompresi atau tidak, tetapi alat yang ingin Anda terapkan ke gambar itu nanti tidak akan berfungsi dengan versi terkompresi. Jika semua yang ingin Anda capai adalah kompresi data saat dalam perjalanan, Anda dapat menggunakan fitur kompresi di ssh. Ini dapat diaktifkan dengan -Cjika belum diaktifkan di konfigurasi Anda.

— kasperd

2

Saya lebih berusaha mengurangi ukuran file. Tetapi jika Anda ingin menghemat bandwidth (ide bagus): cukup tambahkan tanda kutip: ssh root@host "cat /dev/sda | gzip -c - " > /path/to/dir_on_huge_partition/server.img.gz(opsi -c dari ssh biasanya juga bagus, tetapi Anda masih harus mengompres pada akhirnya, karena ssh hanya akan mengompres di pintu masuk terowongannya) dan uncompress sebelum mengirim ke stdout)

— Olivier Dulac

2

Bagaimana Anda bergerak maju dari sini?

Saya akan bersumpah menggunakan rmselama sisa hidup saya dan berpikir bahwa itu gila bahwa trash-cli bukan perintah penghapusan default pada sistem nix.

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

Saya akan memastikan itu adalah hal pertama yang saya instal pada sistem baru dan alias rmuntuk sesuatu yang memberitahu orang untuk menggunakannya trash-cli. Itu juga akan mencakup catatan tentang alias lain yang benar-benar berjalan /bin/rmtetapi memberitahu mereka untuk tidak menggunakannya dalam banyak kasus.

:( Kisah nyata

— Gerry
sumber

2

Dalam pengalaman saya, alat semacam ini lebih seperti gangguan daripada bantuan yang sebenarnya - cepat atau lambat, dan setelah bersumpah, Anda akan menghapusnya. Mungkin ok untuk workstation, tetapi dalam banyak situasi jika tidak sebagian besar ketika Anda melakukan pekerjaan administrasi di server, Anda benar-benar perlu menghapus data, tidak hanya memindahkannya di tempat lain (dan jika itu masalahnya, gunakan saja mv sebagai gantinya). Selain itu, memindahkan data secara otomatis ke folder tempat sampah dapat menyebabkan masalah serius dengan sendirinya (mis. Sampah bukan pada sistem file yang sama, keamanan).

— maetthu

@maetthu Oh tentu saja hal-hal dihapus setelah mereka berada di tempat sampah selama beberapa hari. Desktop Ubuntu melakukan ini pada item yang telah berada di tempat sampah lebih dari 30 hari. Di server Anda mungkin menginginkan sesuatu yang lebih pendek, misalnya. trash-empty 5dalam cron. Intinya adalah untuk memberi Anda masa tenggang karena manusia membuat kesalahan.

— Gerry

Bukankah lebih baik memiliki rencana pemulihan desaster yang berhasil daripada melarang alat sistem penting?

— user292812

@ user292812 Saya tidak menyarankan pelarangan / bin / rm, hanya saja itu seharusnya tidak menjadi pilihan pertama dalam banyak kasus (perhatikan alias / bin / rm). Pertanyaan Anda juga menyarankan pilihan yang salah antara pemulihan bencana dan opsi penghapusan ramah manusia. Anda harus memiliki keduanya.

— Gerry

1

Proses penghapusan dua langkah dapat menghemat banyak masalah: 1. pindah ke tempat sampah (secara lisan), 2. tempat sampah kosong. Saya alias skrip untuk "rm" dan itu menyelamatkan saya dari sengaja menghapus hal-hal penting berkali-kali.

— Sam Watkins

1

Saya ingin saran dalam hal ini adalah unmount dan gunakan debugfs , dan dengan bantuan lsdel Anda dapat membuat daftar semua file yang baru saja dihapus, yang mana tidak dibersihkan dari jurnal dan kemudian membuang file yang diperlukan. Tautan pencarian cepat untuk hal yang sama: http://www.linuxvoodoo.com/resources/howtos/debugfs

berharap itu akan membantu seseorang. ;)

Dan ya, salah satu saran adalah membuat skrip, yang memindahkan rim rm ke real.rm dan symlinc mv ke rm ;)

— BiG_NoBoDy
sumber

-2

Hentikan semua proses server dan segala sesuatu yang dapat menyebabkan disk i / o ... kemudian jalankan testdisk, seharusnya ada di tumpukan perangkat lunak Anda. Jika Anda memiliki akses fisik, gunakan livecd dengan testdisk.

— Saint Crusty
sumber

1

Saya tidak mengerti mengapa Anda berpikir tiga jawaban memberikan saran yang sama persis tidak cukup?

— kasperd