Błąd w poniedziałek rano: sudo rm -rf --no-preserve-root /

Uwaga: odpowiedzi i komentarze do tego pytania zawierają treść z innego, podobnego pytania, które spotkało się z dużym zainteresowaniem ze strony mediów zewnętrznych, ale okazało się, że jest to mistyfikacja w jakimś programie marketingu wirusowego. Ponieważ nie zezwalamy na nadużywanie ServerFault w taki sposób, oryginalne pytanie zostało usunięte, a odpowiedzi zostały scalone z tym pytaniem.

Oto zabawna tragedia. Dziś rano przeprowadziłem trochę konserwacji na moim serwerze produkcyjnym, gdy przez pomyłkę wykonałem następujące polecenie:

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

Nie zauważyłem poprzedniej przestrzeni /i kilka sekund później, gdy ostrzeżenia zalewały moją linię poleceń, zdałem sobie sprawę, że właśnie nacisnąłem przycisk samozniszczenia. Oto trochę tego, co wypaliło mi oczy:

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

Zatrzymałem zadanie i poczułem ulgę, gdy odkryłem, że usługa produkcyjna nadal działa. Niestety serwer nie akceptuje już mojego klucza publicznego ani hasła dla żadnego użytkownika za pośrednictwem SSH.

Jak posunąłbyś się stąd? Popłynę oceanem z drutu kolczastego, żeby odzyskać dostęp do SSH.

Serwer działa Ubuntu-12.04 i jest hostowany w Hetzner.

Uruchom system ratunkowy dostarczony przez Hetznera i sprawdź, jakie szkody wyrządziłeś.
Przenieś wszystkie pliki do bezpiecznej lokalizacji, a następnie ponownie wdróż serwer.

Obawiam się, że to najlepsze rozwiązanie w twoim przypadku.

Faktem jest? W tym momencie nie ma prostej / łatwej automatycznej naprawy tego problemu. Odzyskiwanie danych to nauka, a nawet podstawowe, powszechne narzędzia potrzebują kogoś, kto usiądzie i zapewni dane. Jeśli spodziewasz się, że wyjdziesz z tego bez ogromnych przestojów, będziesz rozczarowany.

Sugeruję użycie testdisk lub jakiegoś narzędzia do odzyskiwania specyficznego dla systemu plików. Wypróbuj jeden system, sprawdź, czy działa i tak dalej. Nie ma prawdziwego sposobu na zautomatyzowanie tego procesu, ale prawdopodobnie możesz to zrobić ostrożnie partiami.

To powiedziawszy, jest kilka bardzo przerażających rzeczy w pytaniach i komentarzach, które powinny być częścią raportów po akcji.

Po pierwsze, uruchomiłeś polecenie wszędzie, nie sprawdzając go najpierw. Uruchom polecenie na jednym polu. Potem kilka, potem więcej. Zasadniczo, jeśli coś pójdzie nie tak, lepiej wpłynąć na kilka, a nie na wszystkie systemy.

Po drugie

@Tim, jak wykonać kopię zapasową bez montowania zdalnego napędu na serwerze?

Przeraża mnie. Kopie zapasowe jednokierunkowe na poziomie plików są rozwiązanym problemem . Rsync może służyć do zachowania uprawnień i kopiowania plików w jeden sposób na stronę kopii zapasowej. Przypadkowo coś? Ponownie zainstaluj (najlepiej automatycznie) rsync i wszystko działa. W przyszłości możesz używać migawek na poziomie systemu plików z migawkami btrfs lub zfs i przesyłać je do kopii zapasowych na poziomie systemu. Właściwie bym się rozdzielił serwery aplikacji, bazy danych i pamięć masową i wprowadziłem zasadę najmniejszych uprawnień, abyś podzielił ryzyko takiego czegoś ...

Wiem, że mogę coś zrobić. Teraz muszę pomyśleć, jak się chronić

Po tym, jak coś się wydarzyło, jest to najgorszy moment na rozważenie tego.

Czego możemy się z tego nauczyć?

1. Kopie zapasowe zapisują dane. Prawdopodobnie kariery.
2. Jeśli masz narzędzie i nie wiesz, co on może zrobić, jest to niebezpieczne. Jedi może robić niesamowite rzeczy za pomocą miecza świetlnego. Pokój szympansów z mieczami świetlnymi ... bałagan.

3. Nigdy nie uruchamiaj polecenia wszędzie jednocześnie. Oddziel maszyny testowe i produkcyjne, a najlepiej produkuj maszyny etapami. Lepiej jest naprawić 1 lub 10 maszyn niż 100 lub 1000.

4. Komendy podwójnego i potrójnego sprawdzania. Nie ma się czego wstydzić, prosząc współpracownika o podwójne sprawdzenie: „hej, mam zamiar zrobić dysk, czy możesz to sprawdzić, żeby nie wyczyścić dysku?”. Opakowanie może również pomóc, ale nic nie przebije mniej zmęczonego zestawu oczu.

Co możesz teraz zrobić? Wyślij wiadomość e-mail do klientów. Poinformuj ich, że są przestoje i katastrofalne awarie. Porozmawiaj ze swoimi wyższymi awansami, działami prawnymi, sprzedażą itp. I zobacz, jak możesz zmniejszyć szkody. Rozpocznij planowanie odzyskiwania, aw razie potrzeby będziesz musiał w najlepszym razie zatrudnić dodatkowe ręce. W najgorszym przypadku planujesz wydać dużo pieniędzy na regenerację. Na tym etapie będziesz pracował nad złagodzeniem skutków awarii oraz poprawkami technicznymi.

Po usunięciu rzeczy rm -rf --no-preserve-rootprawie nie można odzyskać. Jest bardzo prawdopodobne, że straciłeś wszystkie ważne pliki.

Jak powiedział @faker w swojej odpowiedzi, najlepszym sposobem jest przeniesienie plików do bezpiecznej lokalizacji, a następnie ponowne wdrożenie serwera.

Aby uniknąć podobnych sytuacji w przyszłości, sugeruję:

• Rób kopie zapasowe co tydzień lub co najmniej co dwa tygodnie. Pomoże to w przywróceniu usługi, której dotyczy problem, przy możliwie najniższym MTTR.

• Nie pracuj jako root, gdy nie jest potrzebny . I zawsze pomyśl dwa razy, zanim cokolwiek zrobisz. Sugeruję również zainstalowanie safe-rm .

• Nie wpisuj opcji, których nie zamierzasz wywoływać , na przykład --no-preserve-rootlub --permission-to-kill-kittens-explicitly-granted.

Miałem ten sam problem, ale po prostu testowałem na dysku twardym, wszystko straciłem. Nie wiem, czy będzie to przydatne, ale niczego nie instaluj , nie nadpisuj danych , musisz zamontować dyski twarde i uruchomić niektóre narzędzia kryminalistyczne, takie jak autopsja, photorec, Testdisk.

Zdecydowanie polecam Testdisk, z kilkoma podstawowymi poleceniami możesz odzyskać swoje dane, jeśli ich nie zastąpisz.

Najlepszym sposobem na rozwiązanie takiego problemu jest nie zajmowanie się nim w pierwszej kolejności.

Nie wprowadzaj ręcznie polecenia „rm -rf” z ukośnikiem na liście argumentów. (Umieszczenie takich poleceń w skrypcie powłoki z naprawdę dobrymi procedurami sprawdzania poprawności / poprawiania higieny, aby uchronić cię przed zrobieniem czegoś głupiego, jest inne.)

Po prostu nie rób tego.
Zawsze. Jeśli uważasz, że musisz to zrobić, nie myślisz wystarczająco mocno.

Zamiast tego zmień katalog roboczy na katalog nadrzędny katalogu, z którego chcesz rozpocząć usuwanie, aby cel polecenia rm nie wymagał ukośnika:

cd / mnt

sudo rm -rf hetznerbackup

Spróbowałbym odzyskać komputer z kopią zapasową, na której były przechowywane wszystkie kopie:

• Pierwszy krok - Wykonaj kopię zapasową skasowanych dysków „maszyny kopii zapasowej” za pomocą polecenia dd.
• Drugi krok - służy testdiskdo odzyskiwania plików.

Powiedzmy, że chcesz odzyskać 1 TB, będziesz potrzebować dodatkowych 2 TB, 1 TB na kopię zapasową (1. krok) plus 1 TB na odzyskiwanie (2. krok).

Zrobiłem podobny błąd z aliasem rm -fr [telefon zadzwonił] i cd do cennego katalogu. Teraz zawsze myślę dwa razy i sprawdzam kilka razy, zanim użyję polecenia rm lub dd.

Jak wspomniano w innej odpowiedzi, Hetzner ma system ratunkowy. Zawiera zarówno opcję netboot z dostępem ssh, jak i aplet java, który udostępnia ekran i klawiaturę na serwerze vserver.

Jeśli chcesz odzyskać jak najwięcej, zrestartuj serwer w systemie netboot, a następnie zaloguj się i pobierz obraz systemu plików, czytając z odpowiedniego i-węzła urządzenia.

Myślę, że coś takiego powinno działać:

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

Oczywiście przekierowanie jest wykonywane przez powłokę przed wywołaniem polecenia ssh, więc server.img jest plikiem lokalnym. Jeśli chcesz tylko główny system plików, a nie pełny dysk, zastąp sdago, sda3zakładając, że używasz tego samego obrazu co ja.

Jak posunąłbyś się stąd?

Przysiągłbym używać rmdo końca życia i uważam, że szaleństwem jest to, że trash-cli nie jest domyślną komendą usuwania w systemach nix.

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

Chciałbym upewnić się, że jest to pierwsza rzecz, którą instaluję na nowym systemie i alias rmcoś, co mówi ludziom, aby trash-clizamiast tego korzystali . Zawierałaby także notatkę o innym alidzie, który faktycznie działa, /bin/rmale mówi im, aby w większości przypadków nie korzystali z niego.

:( Prawdziwa historia

Radziłbym w takim przypadku odmontować i użyć debugfs , a przy pomocy lsdel możesz wyświetlić listę wszystkich ostatnio usuniętych plików, które nie zostały usunięte z czasopism, a następnie zrzuciły potrzebne pliki. Link do szybkiego wyszukiwania tego samego: http://www.linuxvoodoo.com/resources/howtos/debugfs

mam nadzieję, że to komuś pomoże. ;)

I tak, jedną z sugestii jest wykonanie skryptu, który przeniósł ryzę rm na real.rm i symlinc mv na rm ;)

Zatrzymaj wszystkie procesy serwera i wszystko, co może powodować dyskowe operacje we / wy ..., a następnie uruchom testdisk, powinien on znajdować się na stosie oprogramowania. Jeśli masz fizyczny dostęp, użyj płyty live z dyskiem testowym.