1.名無しAtoZ：2016年04月15日 22:15  ▽このコメントに返信

日本でも10年くらい前にあったね

2.名無しAtoZ：2016年04月15日 22:27  ▽このコメントに返信

MSが某大学のデータふっ飛ばしたんたのもあったな
あれはlinuxじゃなかったけど

3.名無しAtoZ：2016年04月15日 22:32  ▽このコメントに返信

うっかり夢に見そうだなこれ

4.名無しAtoZ：2016年04月15日 22:35  ▽このコメントに返信

スレにもあるけど、なんでバックアップが同じルート配下にあるんだよ…
そんなんだからこんな事態が起きるんじゃね？

5.名無しAtoZ：2016年04月15日 22:38  ▽このコメントに返信

こういうのが怖いから俺はITから足洗った

6.名無しAtoZ：2016年04月15日 22:39  ▽このコメントに返信

バックアップフォルダもマウントしてたんだなww
笑うしかない

7.名無しAtoZ：2016年04月15日 22:46  ▽このコメントに返信

仕事でやってる奴がこんな低レベルなミスしたらダメだろｗ
実行実績もないスクリプトをいきなり本サーバーでバックアップもなしに動かす時点でもうダメやん
rm -rfの意味分かってるのかねぇ
このコマンドを使った事がある奴なら、一度くらいは間違って消す気のないファイルを消してしまって焦りまくった覚えくらいはあるはずやろ
一度やったらその怖さを知ってそんな簡単にホイホイ使えないだろうよ普通は
あまりにお粗末

8.名無しAtoZ：2016年04月15日 22:55  ▽このコメントに返信

find / -name "$bar" -exec rm -rf {} \;

勇者のみ使える伝説の魔法じゃ

9.：2016年04月15日 22:56  ▽このコメントに返信

コレが怖いから、俺はシェル関数でrmやる時はデバッグモード用意して、削除対象1回テキスト出力してチェックしてから消してるわ…。

10.名無しAtoZ：2016年04月15日 22:57  ▽このコメントに返信

なにを言っているのかわからない_(:3 」∠)_

11.名無し：2016年04月15日 22:57  ▽このコメントに返信

バックアップになってないやんw
ちゃんと消えちまった失敗パターンを考えとかないとw

12.名無しAtoZ：2016年04月15日 23:15  ▽このコメントに返信

あー怖い怖い怖い
俺は気をつけようマジで

13.名無しAtoZ：2016年04月15日 23:20  ▽このコメントに返信

ファーストサーバも全消去して
ぐちゃぐちゃになったファイル名の断片データ送ってきたしなぁ

14.名無しAtoZ：2016年04月15日 23:21  ▽このコメントに返信

64のはdとrの間違いかな？
crontab -e(crontabの編集)
crontab -r(crontabの削除)
このオプションに決めたやつ無能すぎ

crontabってのは毎日4時にバックアップ開始とか
定期的に何の処理するか(管理者権限で実行可)が記述してあるリストね
サーバファイルの中でも重要な部類に入る
何がダメかわからない人はキーボード注目

15.名無しAtoZ：2016年04月15日 23:29  ▽このコメントに返信

haltやrebootだって確認も取らずに実行しちゃうからね。仕方ないね。
でも最近のLinuxは/に対する削除は聞き返してきた気がするんだが記憶違いだったか？

16.名無し：2016年04月15日 23:36  ▽このコメントに返信

バックアップは他の媒体に入れとかないんだ...。

17.：2016年04月15日 23:46  ▽このコメントに返信

普通バックアップはテープか他のストレージに保管するだろ
これは単なるコマンドのミスじゃなくて、なるべくしてなった障害だ

18.：2016年04月16日 00:02  ▽このコメントに返信

うわあ…アホだとは思いつつ他人事じゃない……

でもバックアップまで消えるとかありえないでしょ
絶対これとってなかったか、初期に設定だけして運用回してる内に容量不足やら物理故障やらでふた開けて見たらとれてなかったパターンでしょ
ほんとに同じサーバー内にとってたらそもそも設計ミス

お前らも定期的にバックアップ設定見直してリストアテストまでしとけよ…
前任者が立てたやつだし今回ってるから…って放置してるとマジで痛い目見るから