月曜日の朝の間違い：sudo rm -rf --no-preserve-root /

注：この質問への回答とコメントには、外部メディアから多くの注目を集めているが、ある種のバイラルマーケティングスキームではデマの質問であることが判明した別の同様の質問のコンテンツが含まれています。このような方法でServerFaultを悪用することは許可されていないため、元の質問は削除され、回答はこの質問に統合されました。

ここに面白い悲劇があります。今朝、実稼働サーバーで少しメンテナンスを行っていたときに、誤って次のコマンドを実行しました。

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

前の最後のスペースを見つけられず/、数秒後に警告がコマンドラインをあふれさせたとき、私はちょうど自己破壊ボタンを押しただけだと気づきました。これが私の目に焼き付いたものです。

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

タスクを停止し、運用サービスがまだ実行中であることを発見したときは安心しました。悲しいことに、サーバーはSSH経由でユーザーの公開鍵またはパスワードを受け入れなくなりました。

ここからどのように前進しますか？その有刺鉄線の海を泳ぎ、そのSSHアクセスを取り戻します。

サーバーはUbuntu-12.04を実行しており、Hetznerでホストされています。

Hetznerが提供するレスキューシステムを起動し、どのような損害を与えたかを確認します。
ファイルを安全な場所に転送し、その後サーバーを再展開します。

それがあなたの場合の最善の解決策だと思います。

事実は？この時点では、これに対する単純/簡単な自動修正はありません。データ回復は科学であり、基本的な一般的なツールでさえ、データを確実に保持するために誰かが座る必要があります。大量のダウンタイムなしでこれから回復することを期待している場合、あなたは失望するでしょう。

testdisk またはファイルシステム固有の回復ツールを使用することをお勧めします。1つのシステムを試して、それが機能するかどうかなどを確認します。そこのプロセスを自動化する本当の方法はませんが、あなたはおそらくすることができます慎重にバッチでそれを行います。

とはいえ、質問やコメントには、アクション後のレポートに含めるべき非常に恐ろしいものがいくつかあります。

最初に、最初にチェックせずにコマンドをどこでも実行しました。1つのボックスでコマンドを実行します。それからいくつか、それからもっと。基本的に何かがうまくいかない場合、すべてのシステムではなく、いくつかのシステムに影響を与える方が良いです。

第二に

@Timサーバーにリモートドライブをマウントせずにバックアップを行う方法

私を怖がらせます。ファイルレベルの一方向バックアップは、解決された問題です。Rsyncを使用して、アクセス許可を保持し、バックアップサイトへの1つの方法でファイルをコピーできます。偶然何か？（できれば自動的に）rsyncを再インストールすると、動作します。将来、ファイルシステムレベルのスナップショットをbtrfsまたはzfsスナップショットとともに使用し、システムレベルのバックアップ用に出荷する可能性があります。実際に、アプリケーションサーバー、データベース、ストレージを分離し、最小特権の原則を導入して、このようなリスクを分散させます。

私にできることは何でもあります。私は今、自分を守る方法を考える必要があります

何かが起こった後、これを検討する最悪の時期です。

これから何を学ぶことができますか？

1. バックアップはデータを保存します。おそらくキャリア。
2. あなたがツールを持っていて、それが何ができるかを知らないなら、それは危険です。ジェダイはライトセーバーで素晴らしいことをすることができます。ライトセーバーを備えた部屋いっぱいのチンパンジー...面倒になります。

3. 一度にどこでもコマンドを実行しないでください。テストマシンと生産マシンを分離し、できれば生産マシンを段階的に実行してください。100または1000ではなく、1または10台のマシンを修正することをお勧めします。

4. ダブルおよびトリプルチェックコマンド。同僚にダブルチェックを依頼するのは恥ずかしくない。ラッパーも役立つかもしれませんが、それほど疲れない目を打つものはありません。

今何ができますか？顧客にメールを送ります。ダウンタイムが発生し、致命的な障害が発生していることを伝えます。上層部、法律、販売などに相談して、被害を軽減する方法を確認してください。回復の計画を開始します。必要に応じて、せいぜい余分な手を雇う必要があります。最悪の場合、復旧に多額の費用をかける計画を立ててください。この段階では、技術的な修正だけでなく、フォールアウトの軽減にも取り組みます。

を使用してアイテムを削除するとrm -rf --no-preserve-root、回復することはほぼ不可能です。すべての重要なファイルを失った可能性が非常に高いです。

@fakerが答えで言ったように、最善のアクションは、ファイルを安全な場所に転送し、その後サーバーを再展開することです。

今後同様の状況を回避するために、次のことをお勧めします。

• 毎週、または少なくとも2週間はバックアップを取ります。これは、影響を受けるサービスを可能な限り最小のMTTRでバックアップするのに役立ちます。

• 不要なときはrootとして働いてはいけません。そして、何かをする前に常によく考えてください。safe-rmもインストールすることをお勧めします。

• あなたが呼び出すために意図していないオプションは入力しないでくださいように、--no-preserve-rootまたは--permission-to-kill-kittens-explicitly-grantedそのことについては、。

私は同じ問題を抱えていましたが、ハードドライブでテストしただけで、すべてを失いました。私はそれが役に立つだろうかどうかを知りませんが、何もインストールしないでください、あなたのデータを上書きしない、TestDiskはを、あなたのハードドライブをマウントし、剖検たちなど、いくつかのフォレンジックツールを起動する必要があり、PhotoRecを。

Testdiskを強くお勧めします。いくつかの基本的なコマンドを使用すると、上書きしなかった場合にデータを回復できます。

このような問題を修正する最善の方法は、そもそもそれを持たないことです。

引数リストにスラッシュがある「rm -rf」コマンドを手動で入力しないでください。（このようなコマンドを、非常に優れた検証/健全性ルーチンを使用してシェルスクリプトに入れて、愚かなことをするのを防ぎます。）

しないでください。
今まで。あなたがそれをする必要があると思うならば、あなたは十分に一生懸命に考えていません。

代わりに、rmコマンドのターゲットがスラッシュを必要としないように、削除を開始する予定のディレクトリの親に作業ディレクトリを変更します。

cd / mnt

sudo rm -rf hetznerbackup

すべてのコピーが保存されているバックアップマシンを回復しようとします。

• 最初のステップ- ddコマンドでこの消去された「バックアップマシン」ドライブのバックアップを作成し ます。
• 2番目のステップ- testdiskファイルの回復に使用します。

つまり、1TBを回復したいとしましょう。追加の2TB、バックアップ用に1TB（第1ステップ）、回復用に1TB（第2ステップ）が必要になります。

エイリアスrm -fr [電話が鳴った]で同様の間違いをし、貴重なディレクトリにcdしました。今、私はいつも二度考えて、rmまたはddコマンドを使用する前に数回再確認します。

別の回答で述べたように、ヘッツナーには救助システムがあります。これには、sshアクセスを備えたnetbootオプションと、vserverの画面とキーボードを提供するjavaアプレットの両方が含まれています。

可能な限り回復したい場合は、サーバーをネットブートシステムに再起動し、ログインして、適切なデバイスiノードから読み取ってファイルシステムのイメージをダウンロードします。

私はこのような何かがうまくいくと思う：

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

もちろん、リダイレクトはsshコマンドが呼び出される前にシェルによって行われるため、server.imgはローカルファイルです。あなただけのルートファイルシステムではなく、完全なディスクが必要な場合は、交換するsdaことにより、sda3あなたは私と同じ画像を使用していると仮定。

ここからどのように前進しますか？

私はこれからのrm人生で使うことを誓って、nixシステムでtrash-cliがデフォルトの削除コマンドではないのは狂気だと思うでしょう。

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

私はそれが真新しいシステムに最初にインストールするものであり、代わりalias rmに使用するよう人々に伝えるものであることを確認しますtrash-cli。また、実際には実行される/bin/rmが、ほとんどの場合は使用しないように指示する別のエイリアスに関するメモも含まれます。

：（ 実話

私はアンマウントされ、このような場合にはアドバイスや使用するdebugfsのを、との助けを借りてlsdelあなたが雑誌からクリーンアップされないすべての最近削除されたファイルを一覧表示して、できるダンプ必要なファイルを。同じものの高速検索リンク：http : //www.linuxvoodoo.com/resources/howtos/debugfs

それが誰かを助けることを願っています。;）

そして、はい、提案の1つはスクリプトを作成することです。これは、ream rmをreal.rmに、symlinc mvをrmに移動しました ;）

すべてのサーバープロセスとディスクI / Oを引き起こす可能性のあるすべてを停止してから、testdiskを実行します。これはソフトウェアスタックにあるはずです。物理的にアクセスできる場合は、testdiskでlivecdを使用してください。