Pazartesi sabahı hatası: sudo rm -rf - no-preserve-root /

Lütfen aklınızda bulundurun: Bu soruya verilen cevaplar ve yorumlar, dış medyadan çok fazla dikkat çeken, ancak bir çeşit viral pazarlama programında aldatmaca olduğu ortaya çıkan benzer bir sorudan daha fazla içeriğe sahiptir. ServerFault'un bu şekilde kötüye kullanılmasına izin vermediğimiz için, orijinal soru silindi ve cevaplar bu soru ile birleştirildi.

İşte eğlenceli bir trajedi. Bu sabah, yanlışlıkla aşağıdaki komutu yerine getirdiğimde, üretim sunucum üzerinde bir miktar bakım yapıyordum:

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

Son boşluğu daha önce /ve birkaç saniye sonra görmedim , uyarılar komut satırımı doldururken, kendimi imha et düğmesine bastığımı fark ettim. İşte gözlerime yakılanların bir kısmı:

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

Görevi durdurdum ve üretim hizmetinin hala çalıştığını öğrendiğimde rahatlamıştım. Ne yazık ki, sunucu artık SSH üzerinden herhangi bir kullanıcı için genel anahtarımı veya şifremi kabul etmiyor.

Buradan nasıl ileriye gidebilirsin? SSH erişimini geri almak için bir dikenli tel okyanusunda yüzeceğim.

Sunucu Ubuntu-12.04 kullanıyor ve Hetzner'de barındırılıyor.

Hetzner tarafından sağlanan kurtarma sistemini devreye alın ve ne gibi bir hasar verdiğinizi kontrol edin.
Herhangi bir dosyayı güvenli bir yere aktarın ve ardından sunucuyu yeniden konuşlandırın.

Korkarım bu, sizin durumunuzdaki en iyi çözüm.

Gerçek? Bu noktada, bunun için basit / kolay bir otomatik düzeltme yoktur. Veri kurtarma bir bilimdir ve temel, ortak araçların bile oturup oturup verinin orada olmasını sağlamak için birine ihtiyacı vardır. Bundan büyük miktarda kesinti olmadan bu durumdan kurtulmayı bekliyorsanız hayal kırıklığına uğrayacaksınız.

Testdisk veya bir dosya sistemine özel kurtarma aracı kullanmanızı öneririm . Bir sistemi deneyin, çalışıp çalışmadığını görün vb. Süreci otomatikleştirmek için gerçek bir yol yoktur, ancak büyük olasılıkla dikkatli bir şekilde gruplar halinde yapabilirsiniz.

Bununla birlikte, aksiyon raporlarınızda yer alması gereken soru ve yorumlarınızda çok korkutucu şeyler var.

İlk önce, komutu kontrol etmeden her yere koştunuz. Bir kutuda bir komut çalıştırın. Sonra birkaç, daha sonra. Temel olarak eğer bir şeyler ters giderse, tüm sistemlerinizi değil bir kaçını etkilemesi daha iyidir.

ikinci olarak

@ Sunucuya uzak bir sürücü takmadan yedekleme nasıl yapılır?

Beni korkutuyor. Dosya seviyesi tek yönlü yedeklemeler çözülmüş bir problemdir . Rsync, izinleri korumak ve dosyaları bir şekilde bir yedekleme sitesine kopyalamak için kullanılabilir . Yanlışlıkla bir şey mi? Yeniden yükleyin (tercihen otomatik olarak) rsync'i geri yükleyin ve işler işe yarayacak. Gelecekte, dosya sistemi düzeyinde anlık görüntüleri btrfs veya zfs anlık görüntüleriyle kullanabilir ve bunları sistem düzeyinde yedeklemeler için gönderebilirsiniz. Aslında uygulama sunucularını, veritabanlarını ve depolamayı ayıran oyuncaklarla oynardım ve en az ayrıcalık ilkesini ortaya koyardım, böylece böyle bir şeyin riskini bölersiniz ..

Yapabileceğim bir şey olduğunu biliyorum. Şimdi kendimi nasıl koruyacağımı düşünmem gerekiyor

Bir şey olduktan sonra bunu düşünmek için en kötü zaman.

Bundan ne öğrenebiliriz?

1. Yedeklemeler veri tasarrufu sağlar. Muhtemelen kariyer
2. Bir aracınız varsa ve ne yapabileceğini bilmiyorsanız, tehlikelidir. Bir jedi ışın kılıcıyla harika şeyler yapabilir. Işın kılıcına sahip bir oda dolusu şempanze ... dağınık olurdu.

3. Asla her yerde aynı anda bir komut çalıştırma. Test ve üretim makinelerini ayırın ve tercihen üretim makinelerini aşama aşama yapın. 100 veya 1000 yerine 1 veya 10 makineyi tamir etmek daha iyidir.

4. İkili ve üçlü kontrol komutları. Bir ortak çalışandan "hey, bir sürücü kullanmak üzereyim, bunu kontrol edebilir misiniz böylece bir sürücüyü silmeye kalmaz mıyım?" Diye iki kez kontrol etmesini istemekten utanç yoktur. Bir sarmalayıcı da yardımcı olabilir, ancak hiçbir şey daha az yorgun bir göze çarpamaz.

Şimdi ne yapabilirsin? Müşterilere bir e-posta gönderin. Arıza süresi ve felaket hataları var. Daha yüksek, yasal, satış ve benzeri şeylerle konuşun ve hasarı nasıl azaltabileceğinizi görün. İyileşmeyi planlamaya başlayın ve gerekirse, en iyi ihtimalle ekstra el kiralamak zorunda kalacaksınız. En kötüsü, iyileşme için çok para harcamayı planlayın. Bu aşamada, teknik düzeltmelerle birlikte düşüşü azaltmak için çalışacaksınız.

rm -rf --no-preserve-rootİle bir şeyler sildiğinizde , kurtarmak hemen hemen imkansızdır. Bütün önemli dosyaları kaybettin.

@ Faker'in cevabında söylediği gibi , en iyi eylem yolu, dosyaları güvenli bir yere aktarmak ve ardından sunucuyu yeniden dağıtmaktır.

Gelecekte benzer durumlardan kaçınmak için size şunu öneririm:

• Yedekleri haftada bir veya en az iki haftada bir alın. Bu, etkilenen hizmetin mümkün olan en az MTTR ile yedeklenmesinde size yardımcı olacaktır.

• Gerekmediğinde kök olarak çalışma . Ve bir şey yapmadan önce daima iki kez düşün. Güvenli rm de yüklemenizi öneririm .

• İstemediğiniz , örneğin --no-preserve-rootveya --permission-to-kill-kittens-explicitly-grantedbunun gibi seçenekleri yazmayın .

Aynı sorunu yaşadım ama sadece bir harddrive ile test ettim, her şeyimi kaybettim. İşe yarayacak mı bilmiyorum ama hiçbir şey yüklemeyin , verilerinizin üzerine yazmayın, sabit disklerinizi monte etmeniz ve otopsi, photorec, Testdisk gibi bazı adli tıp araçlarını başlatmanız gerekir.

Testdisk'i şiddetle tavsiye ediyorum, bazı temel bilgiler komutuyla üzerine yazmadıysanız verilerinizi kurtarabilirsiniz.

Böyle bir sorunu çözmenin en iyi yolu, en başta bunun olmamasıdır.

Bağımsız değişkenler arasında eğik çizgi bulunan bir "rm -rf" komutunu el ile girmeyin. (Böyle komutları, sizi aptalca bir şey yapmaktan korumak için gerçekten iyi doğrulama / akıl yürütme yordamlarına sahip bir kabuk betiğine koymak farklıdır.)

Sadece yapma.
Hiç. Yapman gerektiğini düşünüyorsan, yeterince zor düşünmüyorsun.

Bunun yerine, çalışma dizini, kaldırmayı başlatmak istediğiniz dizinin ebeveyni ile değiştirin, böylece rm komutunun hedefi eğik çizgi gerektirmez:

cd / mnt

sudo rm -rf hetznerbackup

Tüm kopyaların saklandığı yedekleme makinesini kurtarmayı denerdim:

• 1. adım - Silinen bu "yedekleme makinesi" sürücülerinin ddkomutlarını yedekleyin .
• 2. adım - testdiskDosyaları kurtarmak için kullanın .

Yani 1TB'yi kurtarmak istediğinizi varsayalım, Yedekleme için ekstra 2 TB, yedekleme için 1 TB (1. adım) ve kurtarma için 1 TB (2. adım) gerekir.

Rm -fr [phone rang] ve cd ile değerli dizine benzer bir hata yaptım. Şimdi her zaman iki kere düşünüyorum ve rm veya dd komutunu kullanmadan önce birkaç kez tekrar kontrol ediyorum.

Başka bir cevapta belirtildiği gibi, Hetzner bir kurtarma sistemine sahiptir. Hem ssh erişimli bir netboot seçeneği hem de vserver'ınızda ekran ve klavye vermek için bir java uygulaması içerir.

Mümkün olduğu kadar kurtarmak istiyorsanız, sunucuyu netboot sistemine yeniden başlatın ve ardından oturum açarak uygun aygıttan inode'dan okuyarak dosya sisteminin bir görüntüsünü indirin.

Ben böyle bir şey çalışması gerektiğini düşünüyorum:

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

Elbette, yönlendirme ssh komutu çağrılmadan önce kabuk tarafından yapılır, bu nedenle server.img yerel bir dosyadır. Sadece kök dosya sistemini değil, tam diski istiyorsanız, yerine sdagöre sda3sen de benim gibi görüntüyü kullanarak varsayarak.

Buradan nasıl ileriye gidebilirsin?

Hayatımın rmgeri kalanında kullanmaya yemin ederdim ve tix-cli'nin nix sistemlerinde varsayılan kaldırma komutunun olmaması deliliğin olduğunu düşünüyorum.

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

Yepyeni bir sisteme ilk kurduğum şeyin ve bunun yerine alias rminsanlara kullanmalarını söyleyen bir şey olduğundan emin olurdum trash-cli. Ayrıca, gerçekten çalışan /bin/rmancak çoğu durumda kullanmamalarını söyleyen başka bir takma ad hakkında bir not da içerir .

:( Gerçek hikaye

Böyle durumda bağlantısını kesmesine olduğunu tavsiye ve kullanmak debugfs ve yardımıyla lsdel Eğer dergilerden temizlediğini değil tüm yakın zamanda kaldırılan dosyaları, listeleyebilir ve sonra olabilir dökümü gerekli dosyaları. Aynı hızlı arama bağlantısı: http://www.linuxvoodoo.com/resources/howtos/debugfs

Birine yardım edeceğini umuyorum. ;)

Ve evet, öneri kez delmek taşındı senaryoyu, yapmaktır rm için real.rm ve symlinc mv için rm );

Tüm sunucu işlemlerini ve g / ç disklerine neden olabilecek her şeyi durdurun ... sonra testdisk'i çalıştırın, yazılım yığınınızda olmalıdır. Fiziksel erişiminiz varsa testdisk ile bir canlı kullanın.