Jinsi ya kurejesha faili zilizofutwa kwa rm -rf

Nini cha kufanya katika sekunde sitini za kwanza

Mambo mawili huamua kama utarejesha faili zilizofutwa kwa rm -rf, na yote mawili hutokea kabla hujafungua injini ya utafutaji. Acha kuandika kwenye mfumo huo wa faili (filesystem). Kisha uondoe kwenye matumizi, kwa ku-unmount au kwa ku-remount kwa hali ya read-only.

rm haifuti chochote. Inaondoa ingizo la saraka (directory entry), kisha inaashiria inode na vizuizi vya data (data blocks) vya faili hiyo kama nafasi huru. Baiti hizo bado zipo kwenye kifaa. Zinakaa hapo hadi kigawa vizuizi (block allocator) kitakapokabidhi vizuizi hivyo kwa kitu kingine na kitu hicho kikaandika juu yake. Kila sekunde mfumo wa faili unapobaki umewekwa (mounted) na kuwa na shughuli, daemon huandika mstari wa logi au database hufuta ukurasa, na kila uandishi unaweza kutua kwenye vizuizi unavyotaka kuvirejesha.

Kwa hiyo, amri za kwanza ni zile zinazosimamisha uandishi, si zile zinazorejesha faili.

sudo systemctl stop nginx postgresql
sudo umount /mnt/data

Kama umount itajibu umount: /mnt/data: target is busy., tafuta nini kinachoshikilia mfumo wa faili ukiwa wazi.

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

Kama huwezi kuifungua, i-remount kwa hali ya read-only badala yake. Mount ya read-only husimamisha ugawaji mpya, ambayo ndiyo sehemu kubwa ya unachohitaji.

sudo mount -o remount,ro /mnt/data

Kama njia iliyofutwa ilikuwa kwenye mfumo wa faili wa root, hii ni ngumu zaidi. sudo mount -o remount,ro / kwa kawaida itafeli kwa mount: /: cannot remount /dev/vda1 read-only., kwa sababu michakato inayoendelea (running processes) hushikilia faili zikiwa wazi kwa ajili ya kuandika na kernel haitazilazimisha kufungwa. Kwenye VPS, jibu la kivitendo ni hali ya rescue au recovery ya mtoa huduma wako: inawasha mfumo tofauti wa live ukiwa na diski yako iliyounganishwa lakini haijawekwa (mounted). Kila amri hapa chini kisha huendeshwa dhidi ya kifaa ambacho hakuna mtu anayeandika kwacho.

Kanuni moja inatumika kwa mwongozo huu wote. Usiandike kamwe faili zilizorejeshwa, picha ya diski (disk image), au zana iliyosakinishwa upya kwenye mfumo wa faili unaoufanyia urejeshaji. Unganisha volume ya pili, au tuma matokeo kwenye mashine nyingine kupitia SSH.

Kwa nini rm -rf kwenye ext4 mara nyingi hairejesheki

Weka matarajio yako sawa kabla ya kusakinisha chochote. Thibitisha mfumo wa faili (filesystem) unaotumia:

lsblk -f

Kwenye ext4, ambayo ni chaguo-msingi katika karibu kila VPS image, eneo la data ya faili huhifadhiwa kwenye inode yake kama mti wa extent. Extent ni rekodi moja inayosema kuwa logical block N ya faili hii inaanza kwenye physical block M na inaendelea kwa L blocks. Faili ndogo huhifadhi hadi rekodi nne kati ya hizo ndani ya inode yenyewe. Faili kubwa huelekeza kwenye blocks za ziada zinazoshikilia sehemu iliyobaki ya mti huo.

Wakati link ya mwisho ya faili inapofutwa, ext4 hupitia mti huo, hurudisha kila extent kwenye block allocator, na kufuta mti huo kutoka kwenye inode. Inode hiyo kisha huwekwa alama kama huru na kupewa muda wa kufutwa (deletion time). Data yenyewe haiguswi. Rekodi pekee ya mahali data hiyo ilipokuwa imefutwa.

Hiyo ndiyo tofauti na ext3, ambapo inode iliyofutwa ilibakiza taarifa za kutosha kwa zana kama ext3grep kufuata. Bado unaweza kuorodhesha inodes zilizofutwa kwenye ext4:

sudo debugfs -R lsdel /dev/vdb1

debugfs hufungua kifaa kwa kusoma pekee (read-only) isipokuwa ukiweka -w, kwa hivyo hii ni salama kwenye kifaa ambacho hakijapachikwa (unmounted) na haina gharama kujaribu. Inodes zitaorodheshwa. Kutoa maelezo ya inode moja ndipo mwisho unapofika, kwa sababu ramani ya block (block map) ambayo inode hiyo ilikuwa ikitumia imefutwa, kwa hivyo dump haina cha kufuata.

Zana mbili hujaribu kukwepa hili kwa kusoma journal. Journal ni mzunguko wa ukubwa maalum ambao ext4 hutumia kuhakikisha metadata inabaki thabiti wakati wa crash, na inaweza bado kushikilia nakala ya zamani ya inode kabla ya kufutwa. extundelete na ext4magic zote hutafuta humo. Angalia ukubwa unaofanyia kazi:

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

Journal hushikilia metadata pekee na ni ndogo, kwa hivyo shughuli za kawaida za kuandika data (write activity) hupita humo haraka. Kwenye seva inayofanya kazi, muda ambao inode ya kabla ya kufutwa bado ipo hupimwa kwa dakika. Hakuna zana kati ya hizo inayodumishwa kikamilifu, na hakuna inayopatikana kwenye kila distribution. Zichukulie zote kama njia ya kubahatisha, ziendeshe dhidi ya kifaa ambacho hakijapachikwa au dhidi ya disk image, na usishangae zikikosa kurejesha chochote.

Ikiwa lsblk -f itaripoti xfs, hali si bora zaidi, kwa sababu hakuna njia inayoungwa mkono ya kurejesha faili zilizofutwa (undelete) kwa XFS pia. Mpangilio wa chaguzi hapa chini haubadiliki.

Je, faili bado imefunguliwa katika mchakato unaoendelea?

Hii ndiyo njia pekee ya kurejesha data kwenye ukurasa huu yenye nafasi nzuri ya kufanikiwa, na ndiyo sababu hupaswi kuanzisha upya huduma iliyokuwa ikitumia faili hiyo.

Faili hupotea kikamilifu pale hesabu mbili zinapofika sifuri: idadi ya viingizo vya saraka (directory entries) vinavyoelekeza kwenye inode yake, na idadi ya file descriptors zilizofunguliwa. rm huifanya hesabu ya kwanza kuwa sifuri. Ikiwa mchakato bado unashikilia faili hiyo ikiwa wazi, hesabu ya pili si sifuri, kwa hivyo inode na vizuizi vyake (blocks) bado vimetengwa na data bado inaweza kusomeka.

Tafuta faili zilizofunguliwa ambazo idadi ya viungo (link count) imeshuka hadi sifuri:

sudo lsof +L1

+L1 inamaanisha orodhesha faili zilizofunguliwa zenye idadi ya viungo chini ya 1. Kila matokeo huonyesha mchakato, namba ya file descriptor, NLINK ya 0, na njia (path) inayoishia na (deleted). Chukua PID na namba ya descriptor ili kwenda kwenye /proc:

sudo ls -l /proc/1234/fd

Kiingizo kinaonekana kama 3 -> /var/log/app/events.log (deleted). Kiungo hicho bado kinafikia data hiyo. Icopy kwenye mfumo wa faili (filesystem) tofauti:

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

Tumia cp, si mv. Kufungua /proc/1234/fd/3 kunakupa kishikio (handle) kipya kwenye inode ileile kuanzia mwanzo (offset zero), kwa hivyo unapata faili nzima badala ya sehemu iliyobaki baada ya nafasi ya sasa ya mwandishi.

Kuna mipaka miwili unayopaswa kuijua. Mti wa saraka (directory tree) uliyofutwa haurudi kwa njia hii, kwa sababu ni faili binafsi tu ambazo mchakato ulikuwa umezifungua ndizo zinazoshikiliwa. Na faili ya database iliyokopiwa wakati injini iko katikati ya kuandika ni nakala ya "crash-consistent", kwa hivyo panga kuendesha mchakato wa kurejesha data wa injini hiyo yenyewe badala ya kuichukulia kama faili safi. Viingizo ambavyo lsof huonyesha na mem badala ya namba ya descriptor vimechorwa kwenye kumbukumbu (memory mapped), na hivyo havina kiingizo cha /proc/<pid>/fd cha kukopi kutoka kwacho.

Je, una snapshot kwenye btrfs, ZFS au LVM?

Ikiwa mfumo wa faili unachukua snapshots, faili zilizofutwa tayari zipo ndani ya snapshot moja, bila kubadilika. Hii inasaidia tu ikiwa snapshot ilikuwepo kabla ya ufutaji. Hakuna unachounda sasa kitakachoweza kurudisha nyuma wakati.

btrfs huhifadhi snapshots kama subvolumes:

sudo btrfs subvolume list /

Vinjari snapshot hiyo na unakili njia unazohitaji kwa kutumia cp -a. Ni vyema kunakili njia moja moja badala ya kurudisha nyuma (rollback) subvolume nzima, kwa sababu rollback pia hufuta kila kitu kilichoandikwa tangu snapshot hiyo ichukuliwe.

ZFS huonyesha kila snapshot kama saraka (directory) inayoweza kusomwa tu (read-only):

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

Saraka ya .zfs imefichwa na haitaonekana kwenye ls ya kawaida ya mzizi wa dataset, lakini unaweza kuiingia kwa jina lake. Nakili faili kutoka hapo. zfs rollback hurudisha dataset nzima nyuma na kuharibu kila snapshot mpya zaidi ya ile unayoitaja, kwa hivyo itumie kama suluhisho la mwisho.

Snapshots za LVM ni volume za aina ya copy-on-write zenye ukubwa maalum:

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

Iweke (mount) kama read-only na unakili faili. Kagua lvs kabla ya kuiamini, kwa sababu snapshot ya LVM inayojaza nafasi yake iliyotengwa hubatilishwa na kernel, na mara hilo linapotokea, yaliyomo ndani yake hupotea.

Snapshot si backup. Inaishi kwenye diski ileile au pool ileile kama faili asilia, kwa hivyo inashiriki kila hitilafu inayoweza kuipata faili asilia. Ni nzuri sana katika kutengua makosa yaliyofanyika dakika mbili zilizopita, ambayo ndiyo kazi inayohitajika hapa.

Urejeshaji wa data kwa kutumia PhotoRec, dhidi ya image na si diski inayotumika

Ikiwa hakuna njia iliyotajwa hapo juu inayofaa, kilichobaki ni carving: kuchanganua kifaa kibichi (raw device) kutafuta mifumo ya baiti (byte patterns) inayoashiria mwanzo wa aina ya faili inayojulikana, kisha kuandika kila kitu kinachofuata. Carving husoma data ya faili pekee. Majina ya faili, muundo wa saraka (directory structure), mihuri ya muda (timestamps) na umiliki ni metadata ya mfumo wa faili, na metadata hiyo ndiyo iliyoharibiwa na rm, kwa hivyo hakuna kitakachorejea. Utapata faili zinazoitwa f0384512.jpg ndani ya saraka ya matokeo yenye namba, na utazipanga wewe mwenyewe kwa mkono.

Kanuni mbili huamua kama njia hii itafanya kazi.

Kwanza, tengeneza image ya kifaa kabla ya kuelekeza kitu kingine chochote kwacho. Kwenye Debian na Ubuntu, kifurushi hicho ni gddrescue na binary inayowekwa ni 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 lazima iwe kwenye kifaa tofauti, chenye nafasi ya kutosha angalau sawa na ukubwa wa partition hiyo. lsblk -b huchapisha ukubwa kamili katika baiti. Faili ya ramani (map file) inaruhusu nakala iliyokatizwa kuendelea badala ya kuanza upya. Mara tu unapokuwa na image, unaweza kujaribu zana ya pili baadaye dhidi ya baiti zilezile, jambo ambalo huwezi kufanya ikiwa zana ya kwanza iliandika juu ya diski.

Pili, elekeza zana ya urejeshaji kwenye faili ya image.

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

photorec hufungua menyu ya maandishi. Chagua partition, kisha aina ya mfumo wa faili, kisha saini za faili (file signatures) za kutafuta, kisha saraka ya lengo. Punguza orodha hiyo ya saini ili iwe na aina za faili ulizopoteza kweli kabla ya kuanza, kwa sababu orodha chaguo-msingi hupata kila kitu na kukuachia maelfu ya vipande vya kuchuja.

testdisk, kutoka kwenye kifurushi hicho hicho, ina kazi yake ya kufuta (undelete), na inashughulikia FAT, exFAT, NTFS na ext2 pekee. Kwenye ext4, hiyo inakuacha na photorec.

Tarajia faili zilizogawanyika (fragmented) kurejea zikiwa zimeharibika. Carving hudhani kuwa vitalu (blocks) vya faili vimeunganishwa, kwa hivyo faili ambayo allocator iligawanya kwenye diski ama itajengwa upya vibaya au itakosekana kabisa. Faili za midia hurejeshwa vizuri kwa sababu zina vichwa (headers) imara. Maandishi ya kawaida, usanidi (configuration) na msimbo wa chanzo (source code) hurejeshwa vibaya, kwa sababu hakuna saini ya baiti inayoashiria mwanzo wa shell script.

Nafasi isiyo sahihi: jinsi njia isiyo sahihi ilivyofutwa

Karibu kila ajali ya rm -rf ni tatizo la shell. rm hupokea orodha ya njia na kufuta kila moja kwa zamu. Haiwezi kujua ulichokusudia.

Mfano wa kawaida ni nafasi moja:

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

Mstari wa kwanza una hoja mbili. Inafuta programu, kisha inafuta /old. Ikiwa /old haipo, rm haichapi chochote, kwa sababu -f inazuia kosa la faili kukosekana. Ukimya si uthibitisho.

Umbo la pili ni variable isiyo na alama za kunukuu iliyo na nafasi:

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

Shell hugawa thamani hiyo kwenye nafasi nyeupe, kwa hivyo rm hupokea /srv/my na app kama njia mbili tofauti. Ikiandikwa kama rm -rf "$dir" inakuwa njia moja.

La tatu ni variable tupu, kwa kawaida kwa sababu amri iliyopaswa kuijaza imefeli:

rm -rf "$TARGET"/*

Pamoja na TARGET kutowekwa, hiyo inapanuka kuwa rm -rf /*. GNU rm hukataa umbo tupu: rm -rf / huchapa rm: it is dangerous to operate recursively on '/' na kusimama. Umbo la glob halipati ulinzi huo, kwa sababu shell hubadilisha /* na orodha ya njia halisi za ngazi ya juu kabla ya rm kuendeshwa, na / si mojawapo, kwa hivyo ulinzi haufanyi kazi.

Mazoea yanayozuia makosa ya baadaye

• Weka kila variable inayotumika kama njia kwenye alama za kunukuu. Andika "$dir" kila wakati, ikijumuisha ndani ya majaribio na loops.
• Sitisha operesheni ikiwa variable haina thamani. rm -rf "${TARGET:?TARGET is not set}"/* huifanya shell kusimama na ujumbe wako kabla ya rm kuanza, wakati wowote TARGET inapokuwa haijawekwa au haina thamani. Weka set -euo pipefail juu ya script yoyote inayofuta faili.
• Ongeza --one-file-system. Hii inaiambia rm kuruka saraka yoyote iliyo kwenye mfumo wa faili (filesystem) tofauti na ile uliyoiweka, ili ufutaji wa recursive usivuke kuingia kwenye backup volume iliyopachikwa (mounted) au bind mount.
• Usifute faili ukiwa kama root. Akaunti ya huduma inaweza kuharibu tu kile inachokimiliki, ambayo ndiyo hoja kuu ya kuendesha kila huduma kama mtumiaji wake asiye na upendeleo. Ikiwa huna uhakika na kile akaunti fulani inaweza kufikia, kusoma permission bits kwenye orodha ya ls kunajibu swali hilo kwa amri moja.
• Chapisha orodha kabla ya kuifanyia kazi. Kwenye script, jenga njia za faili, zifanye printf '%s\n', soma matokeo, kisha ufute kwenye hatua ya pili.
• Weka amri ya takataka (trash) karibu. sudo apt install trash-cli inakupa trash-put, trash-list, trash-restore na trash-empty. Faili zilizofutwa huhamishiwa kwenye ~/.local/share/Trash, na trash-empty 30 husafisha chochote kilichozidi siku thelathini.

Kufanya alias ya rm kuwa trash-put inaonekana kama hatua inayofuata ya wazi, lakini ni mtego. Alias hiyo hujenga mazoea ambayo hushindwa kwenye seva inayofuata ambayo haina usanidi huo, na alias hazifanyi kazi ndani ya scripts, ambapo makosa ya gharama kubwa hutokea. Andika trash-put kwa makusudi badala yake.

Urejeshaji pekee unaofanya kazi kila wakati

Kila kitu kilichotajwa hapo juu ni uwezekano tu. Backup si uwezekano.

Mambo mawili hufanya backup kuwa ya kweli. Inajiendesha kwa ratiba bila wewe kuhitaji kukumbuka, na umewahi kuirejesha angalau mara moja. Hifadhi ambayo haijawahi kurejeshwa ni imani tu, kwa sababu mambo yanayoifanya kutokuwa na manufaa (njia isiyo sahihi kwenye orodha ya kujumuisha, au nenosiri la hifadhi ambalo hakuna aliyeandika) hujitokeza tu siku unayohitaji.

Ukiwa na restic, urejeshaji ni amri mbili.

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

Rejesha kwenye saraka tupu badala ya kuandika juu ya njia inayotumika sasa, ili uweze kulinganisha zote mbili kabla ya kitu chochote kuhamishwa. Kusanidi backups za restic kwenye VPS inashughulikia usanidi wa hifadhi na timer ya systemd inayoiendesha.

Ukiwa na Borg:

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

Njia ndani ya kumbukumbu ya Borg huhifadhiwa bila mkwaju wa mwanzo (leading slash), kwa hivyo srv/appdata inafanana na /srv/appdata haifanani na chochote. borg extract huandika kwenye saraka ya sasa ya kazi, kwa hivyo cd kwenye saraka ya muda kwanza.

Ikiwa bado hujachagua kati yao, ulinganisho wa restic na Borg unashughulikia deduplication na hifadhi za append-only, ambayo ni sifa inayozuia seva iliyoathiriwa kufuta historia yake ya backup. Zana yoyote kati ya hizi ni nzuri. Jibu lisilo sahihi ni kutotumia yoyote kati yao.

Seva mpya ndiyo wakati wa bei nafuu zaidi wa kusanidi hili, kabla ya kuwa na kitu chochote chenye thamani ya kupoteza. Dakika kumi za kwanza kwenye VPS mpya ndipo kazi hiyo inapaswa kufanyika, sambamba na usanidi wa SSH na firewall.

Kisha weka ingizo la mara kwa mara kwenye kalenda yako: rejesha saraka moja kutoka kwenye hifadhi kwenda /tmp kila mwezi na usome faili hizo. Tabia hiyo moja ina thamani zaidi kuliko kila zana kwenye ukurasa huu.

FAQ

Je, ninaweza kurejesha faili iliyofutwa kwenye ext4?

Kwa kawaida hapana. Kiungo cha mwisho cha faili kinapofutwa, ext4 huondoa extent tree kutoka kwenye inode, hivyo hakuna rekodi yoyote kwenye diski inayoeleza mahali data hiyo ilipokuwa. extundelete na ext4magic hutafuta kwenye journal ya ext4 kwa ajili ya nakala ya zamani ya inode hiyo, jambo ambalo husaidia tu ikiwa ufutaji ulitokea dakika chache zilizopita na mfumo wa faili haujatumika sana tangu wakati huo. Hakuna mradi wowote kati ya hiyo miwili unaoendelezwa kikamilifu. Endesha mojawapo kwenye kifaa ambacho hakijapachikwa (unmounted) au kwenye disk image, usiwahi kuendesha kwenye mfumo wa faili uliopachikwa, na kwanza hakikisha unachokifanyia kazi kwa kutumia sudo dumpe2fs -h /dev/vdb1 | grep -i journal.

Huduma bado ina faili iliyofutwa ikiwa wazi. Je, ninaweza kuirejesha?

Ndiyo, na hii ndiyo hali bora zaidi. Wakati mchakato (process) unapoishikilia faili ikiwa wazi, inode yake na data blocks zake hubaki zimetengwa, hivyo data bado inaweza kusomeka. Usianzishe upya (restart) huduma hiyo, kwa sababu kufunga descriptor ya mwisho kutakamilisha ufutaji. Endesha sudo lsof +L1 ili kuorodhesha faili zilizo wazi zenye link count ya 0, kumbuka PID na namba ya file descriptor, kisha nakili kupitia /proc kwa kutumia sudo cp /proc/1234/fd/3 /mnt/rescue/events.log. Andika nakala hiyo kwenye mfumo wa faili tofauti. Faili zinazoonyeshwa na mem badala ya namba ya descriptor zimepangwa kwenye kumbukumbu (memory mapped) na hazina njia ya /proc/<pid>/fd ya kunakili kutoka humo.

Kwa nini niweke image ya diski badala ya kuendesha zana ya kurejesha moja kwa moja kwenye diski hiyo?

Kwa sababu kila zana lazima iandike matokeo yake mahali fulani, na uandishi kwenye mfumo wa faili unaojaribu kuurejesha unaweza kuandika juu ya free blocks ambazo bado zina data yako. Nakili partition kwenye kifaa kingine kwanza kwa kutumia sudo ddrescue -n /dev/vdb1 /mnt/rescue/vdb1.img /mnt/rescue/vdb1.map, kisha elekeza photorec kwenye faili ya image. Image hiyo pia inakuwezesha kujaribu zana ya pili baadaye kwenye bytes zilezile, jambo ambalo haliwezekani mara tu kitu kinapoandikwa juu ya data asilia.

Je, rm -rf / bado huharibu mfumo wa Linux?

Amri hiyo yenyewe haiharibu. GNU rm huikataa na kuchapisha rm: it is dangerous to operate recursively on '/'. Maumbo hatari ni yale yanayotokea kupitia njia nyingine. rm -rf "$TARGET"/* ikiwa na TARGET haijawekwa (unset) hupanuka na kuwa rm -rf /*, na shell humpa rm orodha ya saraka kuu (top-level directories), ambazo hakuna hata moja iliyo /, hivyo ulinzi haufanyi kazi. Andika "${TARGET:?TARGET is not set}" badala yake na shell itasimama kabla rm haijaanza kufanya kazi.

Je, snapshot ya mfumo wa faili ni backup?

Hapana. Snapshot ya btrfs au ZFS hukaa kwenye pool moja na data inayolindwa, hivyo diski iliyoharibika au pool iliyoharibiwa itachukua vyote kwa wakati mmoja. Snapshot ya LVM ina tatizo la ziada la ukubwa uliopangwa: ikijaa, kernel huifuta na yaliyomo hupotea. Snapshots ni bora kwa ajili ya kutengua ufutaji uliotokea dakika mbili zilizopita. Kwa mambo mengine yote, weka hifadhi (repository) kwenye vifaa tofauti.