Vraag Fout maandagochtend: sudo rm -rf --no-preserve-root /


Let op: de antwoorden en opmerkingen bij deze vraag bevatten inhoud van een andere, soortgelijke vraag die veel aandacht heeft gekregen van externe media, maar die een hoax-vraag bleek te zijn in een soort van virale marketingstrategie. Aangezien we niet toestaan ​​dat ServerFault op een dergelijke manier wordt misbruikt, is de oorspronkelijke vraag verwijderd en zijn de antwoorden samengevoegd met deze vraag.


Hier is een vermakelijke tragedie. Vanmorgen deed ik wat onderhoud aan mijn productieserver, toen ik ten onrechte het volgende commando uitvoerde:

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

Ik heb de laatste ruimte niet eerder gezien / en een paar seconden later, toen waarschuwingen mijn opdrachtregel overspoelden, besefte ik dat ik net de zelfvernietigingsknop had geraakt. Hier is een beetje van wat in mijn ogen is gebrand:

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

Ik stopte de taak en was opgelucht toen ik ontdekte dat de productiedienst nog steeds draaide. Helaas accepteert de server mijn openbare sleutel of wachtwoord voor elke gebruiker niet meer via SSH.

Hoe zou je verder gaan vanaf hier? Ik zwem in een oceaan van prikkeldraad om die SSH-toegang terug te krijgen.

De server draait Ubuntu-12.04 en wordt gehost bij Hetzner.


142
2018-04-07 06:39


oorsprong


Herstellen van back-ups. Eerlijk gezegd, dit is een van die niet-gemakkelijke scenario's. - MadHatter
Hoe typ je zelfs? --no-preserve-root per ongeluk?! :-O - ThatGraemeGuy
Greame, de toetsen staan ​​net naast elkaar. - MadHatter
Werk op dinsdag: zoek een nieuwe baan;) Neem het als een les waarom back-ups nodig zijn. - TomTom
Dit lijkt me zeker te trollen. Je kunt niet per ongeluk --i-really-mean-delete-my-whole-root typen. - psusi


antwoorden:


Start het reddingsysteem van Hetzner op en kijk wat voor schade je hebt aangericht.
Breng alle bestanden over naar een veilige locatie en voer de server daarna opnieuw in.

Ik ben bang dat dit de beste oplossing is in jouw geval.


92
2018-04-07 07:00



zie er goed uit, hij heeft in elk geval geen problemen met heartbleed! - metacom


Feit is? Op dit moment is er geen eenvoudige / eenvoudige automatische oplossing hiervoor. Gegevensherstel is een wetenschap en zelfs de basis, algemene hulpmiddelen hebben iemand nodig om te gaan zitten en ervoor te zorgen dat de gegevens er zijn. Als je verwacht dit te herstellen zonder enorme downtime, zul je teleurgesteld zijn.

Ik zou voorstellen om een ​​testdisk te gebruiken of enkele bestandssysteem specifieke herstel tool. Probeer één systeem, kijk of het werkt, enzovoort. Er is geen echte manier om het proces te automatiseren maar je kunt waarschijnlijk voorzichtig doe het in batches.

Dat gezegd hebbende, er zijn een paar zeer enge dingen in de vragen en opmerkingen die deel zouden moeten uitmaken van uw verslagen van na de actie.

Ten eerste hebt u het commando overal uitgevoerd zonder het eerst te controleren. Voer een opdracht uit op één vak. Dan een paar, dan nog meer. Kortom, als er iets misgaat, is het beter om het te beïnvloeden a weinig in plaats van al uw systemen.

ten tweede

@Tim hoe een back-up te doen zonder een externe schijf op de server te monteren?

Ik ben bang. Back-ups op bestandsniveau op één manier zijn een opgelost probleem. Rsync kan worden gebruikt om machtigingen te behouden en bestanden te kopiëren een manier naar een back-upsite. Per ongeluk iets? Installeer (bij voorkeur automatisch) rsync terug en alles werkt. In de toekomst kunt u momentopnamen op bestandsniveau gebruiken met btrfs of zfs snapshots en deze verzenden voor back-ups op systeemniveau. Ik speel eigenlijk met het scheiden van applicatieservers, databases en opslag en introduceer het principe van least privilege, zodat je het risico van zoiets zou opsplitsen ..

Ik weet dat ik alles kan doen. Ik moet nu nadenken hoe ik mezelf kan beschermen

Nadat er iets is gebeurd, is dit de slechtste tijd om dit te overwegen.

Wat kunnen we hiervan leren?

  1. Back-ups slaan gegevens op. Mogelijk loopbaan.
  2. Als u een hulpmiddel heeft en niet weet wat het kan doen, is het gevaarlijk. Een jedi kan verbazingwekkende dingen doen met een lichtzwaard. Een kamer vol chimpansees met lichtzwaarden zou rommelig worden.
  3. Voer nooit tegelijkertijd een opdracht uit. Afzonderlijke test- en productiemachines, en bij voorkeur productiemachines in fasen. Het is beter om 1 of 10 machines te repareren in plaats van 100 of 1000.

  4. Dubbele en drievoudige controle-opdrachten. Het is geen schande om een ​​co-medewerker te vragen om dubbel te controleren "hey, ik sta op het punt om een ​​schijf te rijden, zou je dit kunnen controleren, zodat ik niet een schijf hoef af te vegen?". Een wikkel kan ook helpen, maar er gaat niets boven een minder vermoeide reeks ogen.

Wat kun je nu doen? Ontvang een e-mail naar klanten. Laat hen weten dat er downtime is en dat er catastrofale mislukkingen zijn. Praat met je hogere ups, legaal, verkoop en dergelijke en kijk hoe je de schade kunt beperken. Begin met plannen voor herstel en indien nodig moet je op zijn best extra handen aannemen. In het slechtste geval is van plan om veel geld uit te geven aan herstel. In deze fase ga je werken aan het verminderen van de uitval en technische oplossingen.


219
2018-04-11 08:02



@MarcoMarsala Als je iets hebt gerangschikt voordat rsync werd gebruikt, deed je het niet goed. Je zou rsync over ssh moeten gebruiken. - Michael Hampton♦
Ik zou aan dit uitstekende antwoord toevoegen: Stap weg van de computer. Probeer niets te repareren voordat je bent gekalmeerd. U kijkt al naar een aantal ernstige downtime; de tijd nemen om dingen te overdenken in plaats van je systemen nog verder te vernielen (zoals in het dd hierboven) zal het niet erger maken. - Jenny D
Enig idee waarom het commando eigenlijk liep? Als $foo en $bar waren beide niet gedefinieerd, rm -rf / had moeten zijn fout gemaakt met de --no-preserve-root bericht. De enige manier waarop ik kan bedenken dat dit echt zou hebben gewerkt aan een CentOS7-machine is als $bar geëvalueerd naar *, dus wat werd uitgevoerd was rm -rf /*. - terdon
Ik hou van de stilistiek in "Per ongeluk iets?". Dat betekent dat het woord 'verwijderd' per ongeluk is 'verwijderd' of 'verwijderd'. - sehe
@MarcoMarsala, je bent nu tenminste beroemd independent.co.uk/life-style/gadgets-and-tech/news/... - Martin Smith


Wanneer je dingen verwijdert met rm -rf --no-preserve-root, het is bijna onmogelijk om te herstellen. Je hebt waarschijnlijk alle belangrijke bestanden verloren.

Zoals @faker zei in zijn antwoord, de beste manier is om de bestanden over te brengen naar een veilige locatie en daarna de server opnieuw in te zetten.

Om in de toekomst soortgelijke situaties te voorkomen, zou ik u willen voorstellen:

  • Maak back-ups wekelijks, of minstens tweewekelijks. Dit zou u kunnen helpen om de betreffende service terug te halen met zo min mogelijk MTTR.

  • Werk niet als root wanneer dit niet nodig is. En altijd denk twee keer na voordat je iets doet. Ik zou willen voorstellen dat je ook installeert safe-rm.

  • Typ geen opties die u niet van plan bent op te roepen, zoals --no-preserve-root of --permission-to-kill-kittens-explicitly-granted, wat dat betreft.


90
2018-04-07 07:57



Op dezelfde manier, behalve als u HET ECHT BETEKENT, mag u het niet toevoegen --please-destroy-my-drive parameter naar hdparm. - MikeyB
Ik zou willen toevoegen; "Controleer uw argumenten (en opties) driemaal wanneer u als root werkt", "Controleer uw CurrentWorkingDirectory (voordat u iets als rm -rf *) doet", en "Volledige paden gebruiken voor opdrachten (niet doorgeven op $ PATH). - Baard Kopperud


Ik heb hetzelfde probleem gehad, maar alleen met een harde schijf testen, ik ben alles kwijt. Ik weet niet of het nuttig zal zijn, maar installeer niets, overschrijf uw gegevens niet, je moet je harde schijven monteren en een aantal forensische tools starten zoals autopsie, photorec, testdisk.

Ik raad ten zeerste aan om Testdisk te gebruiken, met een aantal basiscommando's kunt u uw gegevens herstellen als u deze niet overschreef.


47
2018-04-11 08:17



Ik zou zeker aanraden om de opslag offline te zetten als het enigszins mogelijk is en opnieuw te monteren als 'alleen-lezen' als je dat überhaupt wel kunt. Of het nu een lifetimeisk of een andere server-instance is. - mhouston100
Ik zou er zelfs over nadenken om een ​​dd-bit kopie van de originele schijf naar een nieuwe schijf te doen vanuit een alleen-lezen koppeling van de originele schijf om veilig te zijn. - Jim
«Deze tools zullen de bestandsnaam en het pad niet herstellen» Ja, dat doen ze. Van de 3 genoemde gereedschappen voert slechts één (Photorec) snijwerk uit. - Andrea Lazzarotto


De beste manier om een ​​probleem als dit op te lossen, is door het niet op de eerste plaats te hebben.

Voer niet handmatig een "rm -rf" -opdracht in die een schuine streep in de argumentlijst heeft. (Het plaatsen van dergelijke commando's in een shellscript met echt goede validatie / sanity routines om je te beschermen tegen iets dommers is anders.)

Doe het gewoon niet.
Ooit. Als je denkt dat je het moet doen, denk je niet hard genoeg na.

Wijzig in plaats daarvan uw werkdirectory in de bovenliggende map van waaruit u de verwijdering wilt starten, zodat het doel van de opdracht rm geen schuine streep vereist:

cd / mnt

sudo rm -rf hetznerbackup


33
2018-04-07 21:22



Ik zet altijd de -rf aan het einde van de argumentlijst, dus rm /bla/foo/bar -rf. Zo ben ik tenminste niet in de problemen als ik na het typen van het bericht op de retourknop druk rm / een deel. - Jens Timmerman
Op dezelfde manier typ ik bij het verwijderen van "* ~" bestanden eerst de tilde en daarna het sterretje. - tekknolagi
Dus je zou liever je huis verwijderen dan alles in de huidige map?!? - greg0ire
@ greg0ire Nee, ik denk dat hij dat wilde zeggen, binnenin /mnt/hetznerbackup, hij moest "/" gebruiken om alles in die map te markeren .. maar alleen van ouder hetznerbackup is genoeg, zonder slashes. - T.Todua
@tazotodua: ik doelde op de opmerking van tekknolagi - greg0ire


Ik zou proberen de back-upmachine te herstellen, waar alle exemplaren zijn opgeslagen:

  • 1e stap - Maak een back-up van deze gewiste "backup machine" schijven met dd comand.
  • 2e stap - Gebruik testdisk om bestanden te herstellen.

Dus laten we zeggen dat je 1TB wilt herstellen, je hebt extra 2 TB nodig, 1 TB voor back-up (1e stap) plus 1 TB voor herstel (2e stap).

Ik deed een soortgelijke fout met alias rm -fr [phone rang] en cd naar precious directory. Nu denk ik altijd twee keer na en controleer ik het paar opnieuw voordat ik de opdracht rm of dd gebruik.


16
2018-04-11 00:32



Vrijwel nul op je schijf door dat te doen. Dat maakt het veel moeilijker om te herstellen. Er is een goede reden dat het OP stelde voor dat je probeerde testdisk te gebruiken en als eerste herstelde, en terwijl de syntaxis van dd een beetje raar kan zijn, is dat een goede reden om het te verdubbelen en drie keer te controleren voordat je het commando uitvoert. Je hebt maar één server weggeveegd, toch? - Journeyman Geek
Je kunt nog steeds herstellen, afhankelijk van hoe lang je het hebt toegestaan dd om je laatste kans te wissen. - Abc Xyz
sorry om dat te zeggen, maar ik voel me enorm trollen in deze vraag ... - tymik
hoop dat je kleine trol voelt in het antwoord :) - Abc Xyz
Om eerlijk te zijn. Ik weet niet zeker of je echt bent. Als dat zo is, zit u waarschijnlijk in de verkeerde baan ... - leftcase


Zoals vermeld in een ander antwoord, heeft Hetzner een reddingsysteem. Het bevat zowel een netboot-optie met ssh-toegang als een Java-applet om je scherm en toetsenbord op je vserver te geven.

Als u zoveel mogelijk wilt herstellen, start u de server opnieuw op in het netboot-systeem en meldt u zich vervolgens aan en downloadt u een afbeelding van het bestandssysteem door de juiste inode van het apparaat te lezen.

Ik denk dat zoiets als dit zou moeten werken:

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

Natuurlijk wordt de omleiding gedaan door de shell voordat de ssh-opdracht wordt aangeroepen, dus server.img is een lokaal bestand. Als je alleen het root-bestandssysteem en niet de volledige schijf wilt, vervang je sda door sda3 ervan uitgaande dat u dezelfde afbeelding gebruikt als ik.


7
2018-04-07 07:54



kan misschien zijn: ssh root@host cat /dev/sda | gzip -c - > /path/to/dir_on_huge_partition/server.img.gz (de on-the-fly gzip zal wel of niet helpen, afhankelijk van wat de inhoud van het bestandssysteem is ...) - Olivier Dulac
@OlivierDulac Door gzip op die manier te gebruiken, worden de gegevens ongecomprimeerd over het netwerk verzonden en vervolgens gecomprimeerd aan de ontvangende kant. Ik neem aan dat het resultaat dat je wilde bereiken was om de gegevens te comprimeren tijdens de overdracht. De lokale afbeelding kan gecomprimeerd of niet worden opgeslagen, maar gereedschappen die u later op die afbeelding wilt toepassen, werken niet met de gecomprimeerde versie. Als u alleen gegevens wilt comprimeren terwijl u onderweg bent, kunt u gebruikmaken van de compressiefunctie in ssh. Het kan worden ingeschakeld met -C als dit nog niet is ingeschakeld in uw configuratie. - kasperd
Ik probeerde de grootte van het bestand te verkleinen. Maar als u bandbreedte wilt besparen (goed idee): voeg gewoon offertes toe: ssh root@host "cat /dev/sda | gzip -c - " > /path/to/dir_on_huge_partition/server.img.gz (de optie -c van ssh is meestal ook goed, maar je zou nog steeds aan het einde moeten comprimeren, omdat ssh alleen bij de ingang van de tunnel comprimeert en decomprimeert voordat het naar stdout wordt gestuurd) - Olivier Dulac


Hoe zou je verder gaan vanaf hier?

Ik zou zweren het gebruik af te schaffen rm voor de rest van mijn leven en denk dat het gek is dat trash-cli niet het standaardverwijderingscommando is op nix-systemen.

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

Ik zou ervoor zorgen dat dit het eerste is dat ik op een geheel nieuw systeem installeer en alias rm naar iets dat mensen vertelt om te gebruiken trash-cli in plaats daarvan. Het bevat ook een opmerking over een andere alias die daadwerkelijk wordt uitgevoerd /bin/rm maar vertelt hen om het in de meeste gevallen te vermijden om het te gebruiken.

:( Waargebeurd verhaal


2
2018-04-15 09:51



In mijn ervaring zijn dit soort hulpmiddelen meer als hinderlijk dan als een echte hulp - vroeg of laat, en na wat scheldwoorden, verwijder je het. Het is misschien ok voor een werkstation, maar in veel, zo niet de meeste situaties, wanneer u administratief werk op een server doet, moet u de gegevens echt verwijderen en niet alleen ergens anders naartoe verplaatsen (en als dat het geval is, gebruikt u gewoon mv in plaats daarvan). Bovendien kan het automatisch verplaatsen van gegevens naar een prullenbak op zichzelf ernstige problemen opleveren (bijvoorbeeld vuilnis niet op hetzelfde bestandssysteem, beveiliging). - maetthu
@maetthu Oh natuurlijk worden dingen verwijderd nadat ze een bepaald aantal dagen in de prullenbak zijn geweest. Ubuntu-desktop doet dit voor items die meer dan 30 dagen in de prullenbak zijn geplaatst. Op een server wil je misschien iets korters, bijvoorbeeld trash-empty 5 in een cron. Het punt is om je wat gratieperiode te geven omdat mensen fouten maken. - Gerry
Is het niet beter om een ​​plan voor werkend herstelplan te hebben in plaats van essentiële systeemtools te verbannen? - user292812
@ user292812 Ik heb niet voorgesteld om / bin / rm te verbannen, alleen dat het in de meeste gevallen niet de eerste optie zou moeten zijn (let op de / bin / rm alias). Uw vraag suggereert ook een valse keuze tussen noodherstel en een optie voor mensvriendelijke verwijdering. Je zou allebei moeten hebben. - Gerry
Een verwijderingsproces in twee stappen kan veel problemen besparen: 1. verplaats naar prullenbak (verbaal), 2. maak prullenbak leeg. Ik heb zo'n script gebruikt om te "rm" en het heeft me gered van het per ongeluk verwijderen van belangrijke dingen vele malen. - Sam Watkins


Ik zou adviseren in een dergelijk geval is unmount en gebruik debugfsen met behulp van lsdel u kunt een lijst maken van alle recentelijk verwijderde bestanden, die niet zijn opgeruimd uit tijdschriften en vervolgens stortplaats benodigde bestanden. Snelle zoeklink voor hetzelfde: http://www.linuxvoodoo.com/resources/howtos/debugfs 

hoop dat het iemand zal helpen. ;)

En ja, eenmaal suggesties zijn om een ​​script te maken, dat verschoven is rm naar real.rm en symlinc mv naar rm ;)


1
2018-04-18 14:46





Stop alle serverprocessen en alles wat schijf-i / o kan veroorzaken ... en voer dan testdisk uit, het zou in uw softwarestack moeten zitten. Als u fysieke toegang hebt, gebruikt u een livecd met een testdisk.


-2
2018-04-17 17:35



Ik begrijp niet helemaal waarom je denkt dat drie antwoorden die exact dezelfde suggestie geven niet voldoende waren? - kasperd