월요일 오전 실수 : 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 또는 일부 파일 시스템 특정 복구 도구를 사용하는 것이 좋습니다 . 하나의 시스템을 시도하고 작동하는지 확인하십시오. 프로세스를 자동화하는 실제 방법은 없지만 일괄 적으로 신중하게 처리 할 수 있습니다 .

즉, 질문과 의견에는 사후 조치 보고서에 포함되어야 할 몇 가지 매우 무서운 것들이 있습니다.

먼저, 먼저 확인하지 않고 어디에서나 명령을 실행했습니다. 한 상자에서 명령을 실행하십시오. 그런 다음 몇 가지 더. 기본적으로 문제가 발생하면 모든 시스템이 아닌 몇 가지에 영향을 미치는 것이 좋습니다.

둘째로

@ 서버에 원격 드라이브를 마운트하지 않고 백업하는 방법은 무엇입니까?

나를 무섭게한다. 파일 수준 단방향 백업은 해결 된 문제 입니다. Rsync를 사용하여 권한을 유지하고 파일을 한 방향 으로 백업 사이트로 복사 할 수 있습니다 . 실수로 뭔가요? rsync back을 다시 설치 (바람직하게는 자동으로)하면 문제가 해결됩니다. 나중에 btrfs 또는 zfs 스냅 샷과 함께 파일 시스템 레벨 스냅 샷을 사용하고 시스템 레벨 백업용으로 제공 할 수 있습니다. 실제로 응용 프로그램 서버, 데이터베이스 및 스토리지를 분리하고 최소 권한의 원칙을 도입하여 이와 같은 위험을 분할했습니다.

내가 할 수있는 일이 있다는 것을 알고 있습니다. 이제 자신을 보호하는 방법을 생각해야합니다

무언가가 일어난 후 이것을 고려해야하는 최악의 시간입니다.

우리는 이것으로부터 무엇을 배울 수 있습니까?

1. 백업은 데이터를 저장합니다. 아마도 경력.
2. 당신이 도구를 가지고 있고 그것이 무엇을 할 수 있는지 알지 못하면 위험합니다. 제다이는 광선 검으로 놀라운 일을 할 수 있습니다. 광선 검이 달린 방대한 침팬지가 지저분해질 것입니다.

3. 한 번에 어디에서나 명령을 실행하지 마십시오. 테스트 및 생산 기계를 분리하고 생산 기계를 단계적으로 수행하는 것이 좋습니다. 100 대 또는 1000 대가 아닌 1 대 또는 10 대의 기계를 수정하는 것이 좋습니다.

4. 이중 및 삼중 검사 명령. 동료 직원에게 "이봐 요, 드라이브를하려고하는데, 드라이브를 지우지 않기 위해 이걸 점검 할 수 있을까요?" 랩퍼도 도움이 될 수 있지만 덜 피곤한 눈은 없습니다.

지금 무엇을 할 수 있습니까? 고객에게 이메일을 보내십시오. 가동 중지 시간과 치명적인 오류가 있음을 알리십시오. 상급 업, 합법적, 판매 등에 게 이야기하고 피해를 완화 할 수있는 방법을 알아보십시오. 회복 계획을 시작하고 필요한 경우 추가 인원을 고용해야합니다. 최악의 경우, 복구에 많은 돈을 쓸 계획입니다. 이 단계에서는 기술 수정뿐만 아니라 오류를 완화하기 위해 노력할 것입니다.

로 항목을 삭제하면 rm -rf --no-preserve-root복구 할 수 없습니다. 중요한 파일을 모두 잃어 버렸을 가능성이 큽니다.

으로 @faker는 그의 대답에서 말했다, 최선의 조치는 안전한 위치에 파일을 전송하고 이후에 서버를 재배치하는 것입니다.

앞으로 비슷한 상황을 피하기 위해 다음과 같이 제안합니다.

• 매주 또는 적어도 2 주마다 백업을 수행하십시오 . 이를 통해 영향을받는 서비스를 최소한의 MTTR로 백업 할 수 있습니다.

• 필요하지 않은 경우 루트로 작동하지 마십시오 . 그리고 무엇이든하기 전에 항상 두 번 생각하십시오. 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 [phone rang] 및 cd를 소중한 디렉토리에 비슷한 실수를했습니다. 이제 rm 또는 dd 명령을 사용하기 전에 항상 두 번 생각하고 몇 번 다시 확인하십시오.

다른 답변에서 언급했듯이 Hetzner에는 구조 시스템이 있습니다. 여기에는 ssh 액세스가 가능한 netboot 옵션과 가상 서버의 화면 및 키보드를 제공하는 Java 애플릿이 모두 포함됩니다.

가능한 한 많이 복구하려면 서버를 netboot 시스템으로 재부팅 한 다음 적절한 장치 inode에서 파일 시스템의 이미지를 로그인하여 다운로드하십시오.

나는 이와 같은 것이 효과가 있다고 생각한다.

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하지만 대부분의 경우 별칭을 사용하지 않도록 지시합니다.

:( 사실

이 경우 조언은 unmount and debugfs 사용 하며 lsdel의 도움으로 저널에서 정리하지 않은 최근에 제거 된 모든 파일을 나열 한 다음 필요한 파일 을 덤프 할 수 있습니다. 동일한 빠른 검색 링크 : http://www.linuxvoodoo.com/resources/howtos/debugfs

누군가에게 도움이되기를 바랍니다. ;)

그리고 네, 제안의 일단은 묶음의 이동 스크립트를 만드는 것입니다 RM을 위해 real.rm 및 symlinc의 MV 하는 RM은 );

모든 서버 프로세스와 디스크 i / o를 일으킬 수있는 모든 것을 중지 한 다음 testdisk를 실행하십시오. 소프트웨어 스택에 있어야합니다. 물리적으로 액세스 할 수있는 경우 testdisk와 함께 livecd를 사용하십시오.