Bestanden herstellen na rm -rf op Linux

Wat u moet doen in de eerste zestig seconden

Twee factoren bepalen of u bestanden kunt herstellen die zijn verwijderd met rm -rf, en beide spelen zich af voordat u een zoekmachine opent. Stop met het schrijven naar dat bestandssysteem. Haal het vervolgens uit gebruik door het te unmounten of door het opnieuw te mounten als read-only.

rm wist niets. Het verwijdert de directory-vermelding en markeert de inode en de datablokken van het bestand als vrij. De bytes staan nog steeds op het apparaat. Ze blijven daar staan totdat de block allocator deze blokken aan een ander proces toewijst en dat proces ze overschrijft. Elke seconde dat het bestandssysteem gemount en actief blijft, schrijft een daemon een logregel of voert een database een page flush uit; beide acties kunnen de blokken die u wilt terughalen overschrijven.

De eerste commando's zijn daarom de commando's die schrijfacties stoppen, niet de commando's die bestanden herstellen.

sudo systemctl stop nginx postgresql
sudo umount /mnt/data

Als umount antwoordt met umount: /mnt/data: target is busy., zoek dan uit welk proces het bestandssysteem openhoudt.

sudo fuser -vm /mnt/data
sudo lsof +D /mnt/data

Als u het niet kunt vrijgeven, mount het dan opnieuw als read-only. Een read-only mount stopt nieuwe toewijzingen, wat in de meeste gevallen voldoende is.

sudo mount -o remount,ro /mnt/data

Als het verwijderde pad zich op het root-bestandssysteem bevond, is dit lastiger. sudo mount -o remount,ro / zal meestal falen met mount: /: cannot remount /dev/vda1 read-only., omdat actieve processen bestanden openhouden voor schrijven en de kernel deze niet geforceerd zal sluiten. Op een VPS is de praktische oplossing de rescue- of recovery-modus van uw provider: hiermee wordt een apart live-systeem opgestart waarbij uw schijf is gekoppeld, maar niet gemount. Elk onderstaand commando wordt dan uitgevoerd op een apparaat waarnaar niemand schrijft.

Eén regel is van toepassing op deze gehele handleiding. Schrijf nooit herstelde bestanden, een schijfimage of een nieuw geïnstalleerde tool naar het bestandssysteem waar u gegevens van probeert te herstellen. Koppel een tweede volume of stuur de output via SSH naar een andere machine.

Waarom rm -rf herstel op ext4 meestal zinloos is

Stel uw verwachtingen bij voordat u iets installeert. Bevestig met welk bestandssysteem u werkt:

lsblk -f

Op ext4, de standaard op vrijwel elke VPS-image, bevindt de datalocatie van een bestand zich in de inode als een extent-boom. Een extent is een record dat aangeeft dat logisch blok N van dit bestand begint op fysiek blok M en doorloopt gedurende L blokken. Kleine bestanden bewaren maximaal vier van deze records in de inode zelf. Grotere bestanden verwijzen naar extra blokken die de rest van de boom bevatten.

Wanneer de laatste link naar een bestand verdwijnt, doorloopt ext4 die boom, geeft elk extent terug aan de block allocator en wist de boom uit de inode. De inode wordt vervolgens als vrij gemarkeerd en voorzien van een verwijderingstijdstip. De data zelf blijft onaangeroerd. Het enige record van waar die data stond, is gewist.

Dat is het verschil met ext3, waar een verwijderde inode voldoende informatie achterliet voor een tool zoals ext3grep om te volgen. U kunt nog steeds verwijderde inodes op ext4 weergeven:

sudo debugfs -R lsdel /dev/vdb1

debugfs opent het apparaat alleen-lezen, tenzij u -w meegeeft, dus dit is veilig op een niet-aangekoppeld apparaat en het kost niets om te proberen. Inodes worden opgesomd. Het dumpen van een inode is waar het eindigt, omdat de block map die de inode voorheen bevatte is gewist, waardoor dump niets meer heeft om te volgen.

Twee tools proberen dit te omzeilen door het journal te lezen. Het journal is een ring van vaste grootte die ext4 gebruikt om metadata consistent te houden bij een crash, en het kan nog steeds een oudere kopie van de inode bevatten van vóór de verwijdering. extundelete en ext4magic doorzoeken beide het journal. Controleer met welke grootte u werkt:

sudo dumpe2fs -h /dev/vdb1 | grep -i journal

Het journal bevat alleen metadata en is klein, dus normale schrijfactiviteit doorloopt het continu. Op een draaiende server wordt het tijdsvenster waarin de inode van vóór de verwijdering nog bestaat, gemeten in minuten. Geen van beide tools wordt actief onderhouden en ze zijn niet op elke distributie beschikbaar als pakket. Beschouw beide als een kleine kans, voer ze uit op een niet-aangekoppeld apparaat of op een schijf-image, en wees niet verbaasd als ze niets opleveren.

Als lsblk -f de melding xfs geeft, is de situatie niet beter, omdat er ook voor XFS geen ondersteunde undelete-methode bestaat. De volgorde van de onderstaande opties verandert hierdoor niet.

Is het bestand nog geopend in een actief proces?

Dit is de enige herstelmethode op deze pagina met een goede kans van slagen, en het is de reden waarom u de service die het bestand gebruikte niet moet herstarten.

Een bestand is pas echt verdwenen wanneer twee tellers nul bereiken: het aantal directory-verwijzingen naar de inode, en het aantal geopende file descriptors. rm brengt de eerste teller naar nul. Als een proces het bestand nog open heeft, is de tweede teller niet nul; de inode en de bijbehorende blokken blijven dus toegewezen en de data is nog steeds leesbaar.

Zoek geopende bestanden waarvan de link-teller naar nul is gedaald:

sudo lsof +L1

+L1 betekent: lijst geopende bestanden op met een link-teller lager dan 1. Elke overeenkomst toont het proces, het file descriptor-nummer, een NLINK van 0, en een pad dat eindigt op (deleted). Gebruik de PID en het descriptor-nummer om naar /proc te gaan:

sudo ls -l /proc/1234/fd

Een item ziet eruit als 3 -> /var/log/app/events.log (deleted). Die link bereikt nog steeds de data. Kopieer deze naar een ander bestandssysteem:

sudo cp /proc/1234/fd/3 /mnt/rescue/events.log

Gebruik cp, niet mv. Het openen van /proc/1234/fd/3 geeft u een nieuwe handle op dezelfde inode vanaf offset nul, waardoor u het volledige bestand krijgt in plaats van alleen het deel na de huidige positie van de schrijver.

Er zijn twee limieten die het vermelden waard zijn. Een verwijderde directory-structuur kan op deze manier niet worden hersteld, omdat alleen de individuele bestanden die een proces open had staan, nog worden vastgehouden. Een databasebestand dat wordt gekopieerd terwijl de engine midden in een schrijfactie zit, is een crash-consistente kopie; plan daarom om de eigen herstelprocedure van de engine uit te voeren in plaats van het bestand als schoon te beschouwen. Items die lsof toont met mem in plaats van een descriptor-nummer zijn in het geheugen gemapt (memory mapped), en daarvoor is geen /proc/<pid>/fd-item beschikbaar om van te kopiëren.

Beschikt u over een snapshot op btrfs, ZFS of LVM?

Als het bestandssysteem snapshots ondersteunt, bevinden de verwijderde bestanden zich al in een ongewijzigde staat in een snapshot. Dit is alleen nuttig als er een snapshot bestond vóór de verwijdering. Alles wat u nu aanmaakt, werkt niet met terugwerkende kracht.

btrfs bewaart snapshots als subvolumes:

sudo btrfs subvolume list /

Doorzoek het snapshot en kopieer de benodigde paden met cp -a. Geef de voorkeur aan het kopiëren van individuele paden boven het terugdraaien van een volledig subvolume, omdat een rollback ook alles verwijdert wat is geschreven sinds het snapshot is gemaakt.

ZFS stelt elk snapshot beschikbaar als een alleen-lezen map:

zfs list -t snapshot
ls /tank/data/.zfs/snapshot/

De map .zfs is verborgen en verschijnt niet in een standaard ls van de dataset-root, maar u kunt deze wel op naam openen. Kopieer de bestanden daaruit. zfs rollback zet de volledige dataset terug en vernietigt elk snapshot dat nieuwer is dan het snapshot dat u opgeeft; gebruik dit dus alleen als laatste redmiddel.

LVM-snapshots zijn copy-on-write volumes met een vaste grootte:

sudo lvs
sudo mount -o ro /dev/vg0/data-snap /mnt/snap

Koppel het volume als alleen-lezen en kopieer de bestanden. Controleer lvs voordat u het snapshot vertrouwt, omdat een LVM-snapshot dat zijn toegewezen ruimte volledig verbruikt, door de kernel ongeldig wordt gemaakt. Zodra dat is gebeurd, is de inhoud verloren.

Een snapshot is geen back-up. Het bevindt zich op dezelfde schijf of in dezelfde pool als het origineel en deelt dus elk defect dat het origineel kan treffen. Het is zeer effectief voor het ongedaan maken van een fout van twee minuten geleden, wat precies de taak is in dit scenario.

Data recovery met PhotoRec, uitsluitend vanaf een image en nooit vanaf de live schijf

Als niets van het bovenstaande van toepassing is, blijft alleen carving over: het scannen van het raw-device op bytepatronen die het begin van een bekend bestandstype markeren, waarna alles wat volgt wordt weggeschreven. Carving leest alleen bestandsdata. Bestandsnamen, mappenstructuren, tijdstempels en eigendomsrechten zijn bestandssysteem-metadata, en die metadata is wat rm heeft vernietigd, dus deze informatie keert niet terug. U krijgt bestanden genaamd f0384512.jpg in een genummerde uitvoermap, die u handmatig moet sorteren.

Twee regels bepalen of dit proces slaagt.

Ten eerste: maak een image van het device voordat u er andere tools op loslaat. Op Debian en Ubuntu is het pakket gddrescue en het binary dat dit installeert is ddrescue.

sudo apt update && sudo apt install -y gddrescue testdisk
sudo ddrescue -n /dev/vdb1 /mnt/rescue/vdb1.img /mnt/rescue/vdb1.map

/mnt/rescue moet op een ander device staan, met ten minste evenveel vrije ruimte als de partitie groot is. lsblk -b toont de exacte grootte in bytes. Het map-bestand zorgt ervoor dat een onderbroken kopieeractie kan worden hervat in plaats van opnieuw te beginnen. Zodra u de image heeft, kunt u later een tweede tool proberen op exact dezelfde bytes; dit is onmogelijk als de eerste tool de schijf heeft overschreven.

Ten tweede: richt de recovery-tool op het image-bestand.

sudo photorec /d /mnt/rescue/recup /mnt/rescue/vdb1.img

photorec opent een tekstmenu. Kies de partitie, vervolgens het bestandssysteemtype, daarna de bestandssignaturen om naar te zoeken en tot slot de doelmap. Beperk die lijst met signaturen tot de bestandstypen die u daadwerkelijk bent verloren voordat u begint, omdat de standaardlijst alles vindt en u tienduizenden fragmenten bezorgt om door te spitten.

testdisk, uit hetzelfde pakket, heeft een eigen undelete-functie en ondersteunt alleen FAT, exFAT, NTFS en ext2. Op ext4 blijft photorec over.

Verwacht dat gefragmenteerde bestanden beschadigd terugkomen. Carving gaat ervan uit dat de blokken van een bestand aaneengesloten zijn; een bestand dat door de allocator over de schijf is verspreid, wordt dus ofwel verkeerd samengesteld of volledig gemist. Mediabestanden laten zich redelijk goed recoveren omdat ze sterke headers hebben. Platte tekst, configuratiebestanden en broncode recoveren slecht, omdat er geen byte-signatuur is die het begin van een shell-script markeert.

De verdwaalde spatie: hoe het verkeerde pad werd verwijderd

Bijna elk rm -rf-ongeluk is een shell-probleem. rm ontvangt een lijst met paden en verwijdert deze één voor één. Het ziet nooit wat u bedoelde.

De klassieker is een enkele spatie:

rm -rf /home/deploy/app /old
rm -rf /home/deploy/app/old

De eerste regel bevat twee argumenten. Het verwijdert de applicatie en daarna verwijdert het /old. Als /old niet bestaat, geeft rm niets weer, omdat -f de foutmelding voor een ontbrekend bestand onderdrukt. Stilte is geen bevestiging.

De tweede vorm is een variabele zonder aanhalingstekens die een spatie bevat:

dir="/srv/my app"
rm -rf $dir

De shell splitst de waarde op witruimte, dus rm ontvangt /srv/my en app als twee afzonderlijke paden. Geschreven als rm -rf "$dir" is het één pad.

De derde is een lege variabele, meestal omdat het commando dat deze had moeten vullen is mislukt:

rm -rf "$TARGET"/*

Wanneer TARGET niet is ingesteld, expandeert dit naar rm -rf /*. GNU rm weigert de kale vorm: rm -rf / geeft rm: it is dangerous to operate recursively on '/' weer en stopt. De glob-vorm krijgt die bescherming niet, omdat de shell /* vervangt door een lijst met werkelijke paden op het hoogste niveau voordat rm ooit wordt uitgevoerd, en / daar niet bij hoort, waardoor de beveiliging nooit wordt geactiveerd.

Gewoontes die de volgende fout voorkomen

• Plaats elke variabele die als pad wordt gebruikt tussen aanhalingstekens. Schrijf "$dir" elke keer, ook binnen tests en loops.
• Stop bij een lege variabele. rm -rf "${TARGET:?TARGET is not set}"/* zorgt ervoor dat de shell stopt met uw bericht voordat rm begint, wanneer TARGET niet is ingesteld of leeg is. Plaats set -euo pipefail bovenaan elk script dat bestanden verwijdert.
• Voeg --one-file-system toe. Dit vertelt rm om mappen over te slaan die zich op een ander bestandssysteem bevinden dan het argument dat u heeft opgegeven, zodat een recursieve verwijdering niet per ongeluk een aangekoppeld back-upvolume of een bind-mount kan bereiken.
• Verwijder geen bestanden als root. Een service-account kan alleen vernietigen wat het bezit; dit is het hele argument voor het uitvoeren van elke service als een eigen gebruiker zonder privileges. Als u niet zeker weet wat een bepaald account kan bereiken, geeft het lezen van de permissiebits in een ls-lijst het antwoord in één commando.
• Print de lijst voordat u actie onderneemt. Bouw in een script de paden op, printf '%s\n' ze, lees de uitvoer en verwijder ze pas in een tweede ronde.
• Houd een prullenbak-commando bij de hand. sudo apt install trash-cli biedt u trash-put, trash-list, trash-restore en trash-empty. Verwijderde bestanden worden verplaatst naar ~/.local/share/Trash, en trash-empty 30 verwijdert alles wat ouder is dan dertig dagen.

Het aanmaken van een alias van rm naar trash-put lijkt de logische volgende stap, maar het is een valstrik. De alias traint een reflex die faalt op de volgende server die deze niet heeft, en aliassen werken niet binnen scripts, waar de kostbare fouten juist gebeuren. Typ trash-put bewust in plaats daarvan.

De enige herstelmethode die altijd werkt

Alles wat hierboven staat is een kans. Een back-up is geen kans.

Twee zaken maken een back-up echt. Hij draait volgens een schema zonder dat u eraan hoeft te denken, en u heeft er minstens één keer een herstel vanaf uitgevoerd. Een repository waarvan nog nooit is hersteld, is gebaseerd op geloof. De factoren die een back-up onbruikbaar maken (een verkeerd pad in de include-lijst of een repository-wachtwoord dat niemand heeft genoteerd) komen pas aan het licht op de dag dat u de back-up nodig heeft.

Met restic is een herstelactie twee commando's.

restic -r /srv/restic-repo snapshots
restic -r /srv/restic-repo restore latest --target /mnt/rescue --include /srv/appdata

Herstel naar een lege map in plaats van over het actieve pad heen, zodat u beide kunt vergelijken voordat er iets wordt overschreven. Het instellen van restic-back-ups op een VPS behandelt de configuratie van de repository en de systemd-timer die deze uitvoert.

Met Borg:

borg list /srv/borg-repo
borg extract /srv/borg-repo::daily-2026-08-08 srv/appdata

Paden in een Borg-archief worden opgeslagen zonder de voorloop-slash, dus srv/appdata komt overeen en /srv/appdata komt nergens mee overeen. borg extract schrijft naar de huidige werkmap, dus cd eerst naar een tijdelijke map.

Als u nog niet tussen beide heeft gekozen, behandelt de vergelijking tussen restic en Borg deduplicatie en append-only repositories; dit is de eigenschap die voorkomt dat een gecompromitteerde server zijn eigen back-upgeschiedenis kan verwijderen. Beide tools zijn uitstekend. Het verkeerde antwoord is dat er geen van beide draait.

Een nieuwe server is het goedkoopste moment om dit in te stellen, voordat er iets op staat dat het waard is om te verliezen. De eerste tien minuten op een nieuwe VPS is waar dat werk thuishoort, naast de SSH- en firewall-configuratie.

Zet vervolgens een terugkerende afspraak in uw agenda: herstel elke maand één map uit de repository naar /tmp en lees de bestanden. Die ene gewoonte is meer waard dan alle tools op deze pagina.

FAQ

Kan ik een verwijderd bestand op ext4 herstellen?

Doorgaans niet. Wanneer de laatste link naar een bestand verdwijnt, wist ext4 de extent tree uit de inode. Hierdoor is op de schijf niet meer terug te vinden waar de data stond. extundelete en ext4magic doorzoeken het ext4-journal naar een oudere kopie van die inode. Dit werkt alleen als de verwijdering enkele minuten geleden plaatsvond en het bestandssysteem sindsdien niet meer is beschreven. Geen van beide projecten wordt nog actief onderhouden. Voer deze tools uit op een niet-aangekoppeld (unmounted) apparaat of een schijfimage. Gebruik ze nooit op een aangekoppeld bestandssysteem en controleer eerst met sudo dumpe2fs -h /dev/vdb1 | grep -i journal waar u precies mee werkt.

Een service heeft het verwijderde bestand nog open. Kan ik het terugkrijgen?

Ja, dit is de meest gunstige situatie. Zolang een proces het bestand openhoudt, blijven de inode en de datablokken toegewezen, waardoor de data leesbaar blijft. Herstart de service niet, want het sluiten van de laatste descriptor voltooit de verwijdering. Gebruik sudo lsof +L1 om open bestanden met een link count van 0 weer te geven. Noteer het PID en het file descriptor-nummer en kopieer de data vervolgens via /proc met sudo cp /proc/1234/fd/3 /mnt/rescue/events.log. Schrijf de kopie naar een ander bestandssysteem. Inzendingen die worden getoond met mem in plaats van een descriptor-nummer zijn in het geheugen gemapt (memory mapped) en hebben geen /proc/<pid>/fd-pad om vanaf te kopiëren.

Waarom moet ik een image van de schijf maken in plaats van de recovery-tool direct op de schijf uit te voeren?

Omdat elke tool zijn uitvoer ergens moet opslaan. Een schrijfactie naar het bestandssysteem dat u probeert te herstellen, kan terechtkomen op de vrije blokken waar uw data nog staat. Kopieer de partitie eerst naar een ander apparaat met sudo ddrescue -n /dev/vdb1 /mnt/rescue/vdb1.img /mnt/rescue/vdb1.map en laat photorec vervolgens naar het imagebestand wijzen. Met een image kunt u later ook een tweede tool op exact dezelfde bytes uitproberen; dit is onmogelijk zodra er iets over de originele data heen is geschreven.

Vernietigt rm -rf / nog steeds een Linux-systeem?

Het kale commando niet. GNU rm weigert dit en geeft rm: it is dangerous to operate recursively on '/' weer. De gevaarlijke varianten zijn die welke via een andere route binnenkomen. rm -rf "$TARGET"/* met TARGET unset expandeert naar rm -rf /*. De shell geeft rm een lijst met echte top-level mappen, waarvan er geen enkele / is, waardoor de beveiliging nooit wordt geactiveerd. Schrijf in plaats daarvan "${TARGET:?TARGET is not set}"; de shell stopt dan voordat rm wordt uitgevoerd.

Is een snapshot van een bestandssysteem een back-up?

Nee. Een btrfs- of ZFS-snapshot bevindt zich in dezelfde pool als de data die het beschermt. Een defecte schijf of een vernietigde pool neemt dus beide tegelijk mee. Een LVM-snapshot heeft het extra probleem van een vaste grootte: zodra deze vol is, maakt de kernel de snapshot ongeldig en is de inhoud verloren. Snapshots zijn uitstekend om een verwijdering van twee minuten geleden ongedaan te maken. Voor alle andere gevallen dient u een repository op aparte hardware bij te houden.