rm -rf மூலம் நீக்கப்பட்ட கோப்புகளை மீட்பது எப்படி?

முதல் அறுபது வினாடிகளில் செய்ய வேண்டியவை

rm -rf மூலம் நீக்கப்பட்ட கோப்புகளை நீங்கள் மீட்டெடுக்க முடியுமா என்பதை இரண்டு விஷயங்கள் தீர்மானிக்கின்றன. தேடுபொறியைத் திறப்பதற்கு முன்பே இந்த இரண்டு நடவடிக்கைகளையும் நீங்கள் எடுக்க வேண்டும். அந்த filesystem-ல் தரவுகளை எழுதுவதை நிறுத்துங்கள். பின், அதை unmount செய்வதன் மூலமோ அல்லது read-only முறையில் remount செய்வதன் மூலமோ பயன்பாட்டிலிருந்து நீக்குங்கள்.

rm எதையும் அழிப்பதில்லை. இது directory entry-ஐ நீக்கிவிட்டு, inode மற்றும் கோப்பின் data blocks-ஐ காலியாகக் குறிக்கிறது. அந்த bytes இன்னும் சாதனத்திலேயே இருக்கும். block allocator அந்தத் தொகுதிகளை வேறொரு பயன்பாட்டிற்கு வழங்கி, அதில் புதிய தரவுகள் எழுதப்படும் வரை அவை அங்கேயே இருக்கும். filesystem mounted நிலையில் இருந்து, பயன்பாட்டில் இருக்கும் ஒவ்வொரு நொடியும், ஒரு daemon log கோப்பை எழுதலாம் அல்லது ஒரு database ஒரு பக்கத்தை (page) புதுப்பிக்கலாம். இந்த இரண்டு செயல்களில் எது நடந்தாலும், நீங்கள் மீட்டெடுக்க விரும்பும் தரவுகள் மேலெழுதப்படலாம் (overwrite).

எனவே, கோப்புகளை மீட்டெடுக்கும் கட்டளைகளை விட, தரவுகள் எழுதப்படுவதைத் தடுக்கும் கட்டளைகளே முதலில் முக்கியமானவை.

sudo systemctl stop nginx postgresql
sudo umount /mnt/data

umount கட்டளை umount: /mnt/data: target is busy. என்று பதிலளித்தால், எந்தச் செயல்முறை (process) அந்த filesystem-ஐத் திறந்து வைத்துள்ளது என்பதைக் கண்டறியவும்.

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

அதை விடுவிக்க முடியவில்லை என்றால், அதற்குப் பதிலாக அதை read-only முறையில் remount செய்யவும். read-only mount புதிய ஒதுக்கீடுகளைத் (allocations) தடுக்கும்; இதுவே உங்களுக்குத் தேவையான மிக முக்கியமான பாதுகாப்பு.

sudo mount -o remount,ro /mnt/data

நீக்கப்பட்ட கோப்பு root filesystem-ல் இருந்தால், இது கடினமானது. sudo mount -o remount,ro / கட்டளை பெரும்பாலும் mount: /: cannot remount /dev/vda1 read-only. பிழையுடன் தோல்வியடையும். ஏனெனில், இயங்கிக்கொண்டிருக்கும் process-கள் கோப்புகளைத் திறந்து வைத்திருக்கும், kernel அவற்றை வலுக்கட்டாயமாக மூடாது. ஒரு VPS-ல் இதற்கான நடைமுறைத் தீர்வு, உங்கள் சேவை வழங்குநரின் rescue அல்லது recovery mode-ஐப் பயன்படுத்துவதாகும். இது உங்கள் வட்டை (disk) இணைத்து, ஆனால் mount செய்யாமல், ஒரு தனி live system-ஐத் தொடங்கும். அதன் பிறகு கீழே உள்ள ஒவ்வொரு கட்டளையும் யாரும் எழுதாத ஒரு சாதனத்தில் இயங்கும்.

இந்த வழிகாட்டி முழுமைக்கும் ஒரு விதி பொருந்தும். மீட்டெடுக்கப்பட்ட கோப்புகள், disk image அல்லது புதிதாக நிறுவப்பட்ட கருவிகள் எதையும் நீங்கள் தரவுகளை மீட்டெடுக்கும் அதே filesystem-ல் எழுத வேண்டாம். இரண்டாவது volume-ஐ இணைக்கவும் அல்லது SSH வழியாக வெளியீட்டை வேறொரு கணினிக்கு அனுப்பவும்.

ext4-ல் rm -rf செய்த கோப்புகளை மீட்பது ஏன் பெரும்பாலும் இயலாத காரியம்

எந்தவொரு மென்பொருளையும் நிறுவும் முன் உங்கள் எதிர்பார்ப்புகளைச் சரியாக வைத்துக்கொள்ளுங்கள். நீங்கள் எந்த filesystem-ஐப் பயன்படுத்துகிறீர்கள் என்பதை உறுதிப்படுத்தவும்:

lsblk -f

பெரும்பாலான VPS images-ல் இயல்பாக இருக்கும் ext4-ல், ஒரு கோப்பின் தரவு இருக்கும் இடம் அதன் inode-ல் ஒரு extent tree-ஆகச் சேமிக்கப்படும். ஒரு extent என்பது, ஒரு கோப்பின் logical block N, physical block M-ல் தொடங்கி L blocks வரை நீள்கிறது என்று கூறும் ஒரு பதிவாகும். சிறிய கோப்புகள் நான்கு பதிவுகள் வரை inode-க்குள்ளேயே வைத்திருக்கும். பெரிய கோப்புகள், மீதமுள்ள tree-ஐக் கொண்டிருக்கும் கூடுதல் blocks-ஐச் சுட்டிக்காட்டும்.

ஒரு கோப்பிற்கான கடைசி link நீக்கப்படும்போது, ext4 அந்த tree-ஐச் சென்று, ஒவ்வொரு extent-ஐயும் block allocator-க்குத் திருப்பி அனுப்பி, inode-லிருந்து அந்த tree-ஐ அழித்துவிடும். பின்னர் அந்த inode காலியாகக் குறிக்கப்பட்டு, நீக்கப்பட்ட நேரம் அதில் பதியப்படும். தரவு அப்படியே இருக்கும், ஆனால் அந்தத் தரவு எங்கே இருந்தது என்பதற்கான ஒரே பதிவும் அழிக்கப்பட்டுவிடும்.

இது ext3-லிருந்து மாறுபட்டது; ext3-ல் நீக்கப்பட்ட inode-ல் ext3grep போன்ற ஒரு கருவி பின்தொடரத் தேவையான தகவல்கள் இருக்கும். ext4-ல் நீக்கப்பட்ட inode-களை உங்களால் இன்னும் பட்டியலிட முடியும்:

sudo debugfs -R lsdel /dev/vdb1

debugfs, -w-ஐ நீங்கள் பயன்படுத்தாதவரை device-ஐ read-only முறையிலேயே திறக்கும். எனவே, unmount செய்யப்பட்ட device-ல் இதைச் செய்வது பாதுகாப்பானது மற்றும் முயற்சிப்பதில் இழப்பில்லை. inode-கள் பட்டியலிடப்படும். ஆனால், அந்த inode வைத்திருந்த block map அழிக்கப்பட்டுவிட்டதால், dump-க்குத் தொடர வழியில்லை; எனவே ஒரு inode-ஐ dump செய்வதோடு உங்கள் முயற்சி முடிந்துவிடும்.

இரண்டு கருவிகள் journal-ஐ வாசிப்பதன் மூலம் இதைச் சரிசெய்ய முயல்கின்றன. journal என்பது ext4 பயன்படுத்தும் ஒரு நிலையான அளவு கொண்ட ring ஆகும். இது ஒரு crash-ன் போது metadata-வைச் சீராக வைத்திருக்க உதவுகிறது. நீக்கப்படுவதற்கு முந்தைய inode-ன் பழைய நகல் இதில் இருக்கலாம். extundelete மற்றும் ext4magic ஆகிய இரண்டும் இதைத் தேடும். நீங்கள் கையாளும் அளவு என்ன என்பதைச் சரிபார்க்கவும்:

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

journal metadata-வை மட்டுமே வைத்திருக்கும் மற்றும் அது சிறியது, எனவே சாதாரண write செயல்பாடுகள் அதை விரைவாகச் சுழற்சி முறையில் கடந்துவிடும். இயங்கிக்கொண்டிருக்கும் ஒரு server-ல், நீக்கப்படுவதற்கு முந்தைய inode இருக்கும் கால அளவு சில நிமிடங்கள் மட்டுமே. இந்த இரண்டு கருவிகளும் தற்போது பராமரிக்கப்படுவதில்லை, மேலும் எல்லா distribution-களிலும் இவை தொகுக்கப்படுவதில்லை (packaged). இரண்டையுமே மிகக் குறைந்த வாய்ப்புள்ள முயற்சியாகக் கருதுங்கள். இவற்றை unmount செய்யப்பட்ட device அல்லது disk image-ல் மட்டும் இயக்குங்கள். இவை எதையும் கண்டறியவில்லை என்றால் ஆச்சரியப்பட வேண்டாம்.

lsblk -f, xfs என்று காட்டினால், நிலைமை இன்னும் மோசமானது, ஏனெனில் XFS-லும் கோப்புகளை மீட்பதற்கான ஆதரவு இல்லை. கீழே உள்ள விருப்பங்களின் வரிசை மாறாது.

இயங்கும் process ஒன்றில் கோப்பு இன்னும் திறந்திருக்கிறதா?

இந்த பக்கத்தில் உள்ள மீட்பு முறைகளில் இதுவே அதிக வெற்றி வாய்ப்புள்ள முறையாகும். கோப்பைப் பயன்படுத்திக் கொண்டிருந்த service-ஐ நீங்கள் restart செய்யக்கூடாது என்பதற்கு இதுவே காரணம்.

ஒரு கோப்பின் inode-ஐக் குறிக்கும் directory entries எண்ணிக்கை மற்றும் திறந்திருக்கும் file descriptors எண்ணிக்கை ஆகிய இரண்டு கணக்குகளும் பூஜ்ஜியத்தை அடையும் போது மட்டுமே அந்த கோப்பு முழுமையாக நீக்கப்பட்டதாகக் கருதப்படும். rm கட்டளையானது முதல் கணக்கை பூஜ்ஜியமாக்குகிறது. ஒரு process இன்னும் அந்த கோப்பைத் திறந்து வைத்திருந்தால், இரண்டாவது கணக்கு பூஜ்ஜியமாகாது. எனவே, inode மற்றும் அதன் blocks இன்னும் ஒதுக்கீடு செய்யப்பட்டிருக்கும், மேலும் தரவுகளை இன்னும் படிக்க முடியும்.

Link count பூஜ்ஜியமாகக் குறைந்த திறந்த கோப்புகளைக் கண்டறியவும்:

sudo lsof +L1

+L1 என்பது 1-க்கும் குறைவான link count கொண்ட திறந்த கோப்புகளைப் பட்டியலிடுவதைக் குறிக்கிறது. ஒவ்வொரு முடிவும் அந்த process, file descriptor எண், NLINK-ன் 0 மற்றும் (deleted)-ல் முடியும் பாதையைக் காட்டும். PID மற்றும் descriptor எண்ணைப் பயன்படுத்தி /proc செய்யவும்:

sudo ls -l /proc/1234/fd

ஒரு பதிவு 3 -> /var/log/app/events.log (deleted) என்பது போல இருக்கும். அந்த link இன்னும் தரவைச் சென்றடையும். அதை வேறொரு filesystem-க்கு நகலெடுக்கவும்:

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

mv-ஐப் பயன்படுத்தாமல், cp-ஐப் பயன்படுத்தவும். /proc/1234/fd/3-ஐத் திறப்பது, அதே inode-ல் offset பூஜ்ஜியத்திலிருந்து தொடங்கும் புதிய handle-ஐ உங்களுக்கு வழங்கும். இதனால், writer-ன் தற்போதைய நிலைக்குப் பிந்தைய பகுதியை மட்டும் பெறாமல், முழு கோப்பையும் பெற முடியும்.

தெரிந்துகொள்ள வேண்டிய இரண்டு வரம்புகள் உள்ளன. நீக்கப்பட்ட directory tree-ஐ இந்த முறையில் மீட்டெடுக்க முடியாது, ஏனெனில் process திறந்து வைத்திருந்த தனிப்பட்ட கோப்புகள் மட்டுமே தக்கவைக்கப்படுகின்றன. மேலும், database engine எழுதும் பணியில் இருக்கும்போது நகலெடுக்கப்பட்ட database கோப்பு, crash-consistent நகலாகவே இருக்கும். எனவே, அதைச் சுத்தமான கோப்பாகக் கருதாமல், அந்த engine-ன் சொந்த மீட்பு முறையை (recovery) இயக்குவதைத் திட்டமிடுங்கள். lsof கட்டளையில் descriptor எண்ணுக்குப் பதிலாக mem என்று காட்டப்படும் பதிவுகள் memory mapped செய்யப்பட்டவை. அவற்றுக்கு நகலெடுப்பதற்கு /proc/<pid>/fd பதிவு எதுவும் இருக்காது.

உங்களிடம் btrfs, ZFS அல்லது LVM-ல் snapshot உள்ளதா?

கோப்பு முறைமை (filesystem) snapshot-களை எடுத்தால், நீக்கப்பட்ட கோப்புகள் ஏற்கனவே அதில் மாற்றமில்லாமல் இருக்கும். நீக்குவதற்கு முன்பே snapshot எடுக்கப்பட்டிருந்தால் மட்டுமே இது உதவும். இப்போது நீங்கள் உருவாக்கும் எதுவும் கடந்த காலத்திற்குச் செல்லாது.

btrfs, snapshot-களை subvolumes-ஆக வைத்திருக்கும்:

sudo btrfs subvolume list /

Snapshot-ஐ உலாவவும், உங்களுக்குத் தேவையான பாதைகளை cp -a மூலம் நகலெடுக்கவும். முழு subvolume-ஐயும் rollback செய்வதை விட, தனிப்பட்ட பாதைகளை நகலெடுப்பதே சிறந்தது. ஏனெனில், rollback செய்தால் snapshot எடுக்கப்பட்ட பிறகு எழுதப்பட்ட அனைத்து தரவுகளும் அழிந்துவிடும்.

ZFS ஒவ்வொரு snapshot-ஐயும் read-only கோப்பகமாக (directory) காட்டும்:

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

.zfs கோப்பகம் மறைக்கப்பட்டிருக்கும், இது dataset root-ன் சாதாரண ls-ல் தெரியாது. ஆனால், அதன் பெயரை உள்ளிட்டு நீங்கள் நுழையலாம். அங்கிருந்து கோப்புகளை நகலெடுக்கவும். zfs rollback முழு dataset-ஐயும் பின்னோக்கி நகர்த்தி, நீங்கள் குறிப்பிடும் snapshot-க்கு பிறகுள்ள அனைத்து snapshot-களையும் அழித்துவிடும். எனவே, இதை இறுதி முயற்சியாக மட்டும் பயன்படுத்தவும்.

LVM snapshot-கள் நிலையான அளவு கொண்ட copy-on-write volumes ஆகும்:

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

அதை read-only முறையில் mount செய்து கோப்புகளை நகலெடுக்கவும். அதை நம்புவதற்கு முன் lvs-ஐ சரிபார்க்கவும். ஏனெனில், LVM snapshot-க்கு ஒதுக்கப்பட்ட இடம் நிரம்பிவிட்டால், அது kernel-ஆல் செல்லாததாக்கப்படும். அவ்வாறு நடந்தால், அதன் உள்ளடக்கங்கள் அழிந்துவிடும்.

Snapshot என்பது backup அல்ல. அது அசல் தரவு இருக்கும் அதே வட்டில் (disk) அல்லது pool-ல் இருப்பதால், அசல் தரவு எதிர்கொள்ளும் அனைத்து தோல்விகளையும் இதுவும் எதிர்கொள்ளும். இரண்டு நிமிடங்களுக்கு முன் செய்த தவறைச் சரிசெய்ய இது மிகவும் பயனுள்ளது, இந்தச் சூழலுக்கு அதுவே சரியான தீர்வாகும்.

PhotoRec மூலம் தரவுகளை மீட்டெடுத்தல் (Carving), நேரடி disk-ல் அல்லாமல் image கோப்பில் மட்டும் பயன்படுத்தவும்

மேலே உள்ள முறைகள் எதுவும் பலனளிக்கவில்லை என்றால், carving முறையே எஞ்சியுள்ளது: ஒரு கோப்பின் தொடக்கத்தைக் குறிக்கும் byte patterns-ஐ raw device-ல் தேடி, அதைத் தொடர்ந்து வரும் தரவுகளை மட்டும் தனியாகப் பிரித்தெடுப்பதே இதன் பணி. Carving கோப்பின் தரவுகளை மட்டுமே வாசிக்கும். கோப்புப் பெயர்கள், directory அமைப்பு, timestamps மற்றும் உரிமையாளர் விவரங்கள் அனைத்தும் filesystem metadata ஆகும்; அந்த metadata-வைத்தான் rm அழித்துவிட்டது, எனவே அவற்றை மீண்டும் பெற முடியாது. நீங்கள் பெறும் கோப்புகள் f0384512.jpg என்ற பெயரில் எண்ணிடப்பட்ட output directory-ல் சேமிக்கப்படும், அவற்றை நீங்கள் கைமுறையாக வரிசைப்படுத்த வேண்டும்.

இந்த முறை செயல்படுவதற்கு இரண்டு விதிகள் உள்ளன.

முதலாவதாக, வேறு எதையும் செய்வதற்கு முன் அந்த device-ன் image-ஐ உருவாக்கவும். Debian மற்றும் Ubuntu-வில் இதற்கான package gddrescue ஆகும், இது நிறுவும் binary 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 வேறொரு device-ல் இருக்க வேண்டும், அந்த partition-ல் உள்ள அளவுக்கேற்ப போதுமான காலி இடம் அதில் இருக்க வேண்டும். lsblk -b கோப்பின் அளவை bytes-ல் துல்லியமாகக் காட்டும். இந்த map கோப்பு, இடையில் தடைபட்டால் மீண்டும் முதலிலிருந்து தொடங்காமல், நின்ற இடத்திலிருந்து நகலெடுக்க உதவும். நீங்கள் image-ஐ உருவாக்கிவிட்டால், அதே bytes-ஐ வைத்துக்கொண்டு வேறொரு கருவியையும் முயற்சி செய்யலாம்; முதல் கருவி நேரடியாக disk-ல் மாற்றங்களைச் செய்திருந்தால் இது சாத்தியமில்லை.

இரண்டாவதாக, recovery கருவியை அந்த image கோப்பின் மீது மட்டும் பயன்படுத்தவும்.

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

photorec ஒரு text menu-வைத் திறக்கும். அதில் partition-ஐத் தேர்ந்தெடுக்கவும், பின் filesystem வகை, தேட வேண்டிய file signatures, மற்றும் சேமிக்க வேண்டிய destination directory ஆகியவற்றைத் தேர்வு செய்யவும். தேடலைத் தொடங்கும் முன், உங்களுக்குத் தேவையான கோப்பு வகைகளை மட்டும் signature பட்டியலில் தேர்வு செய்யவும்; ஏனெனில், default பட்டியலில் உள்ள அனைத்தையும் தேடினால், ஆயிரக்கணக்கான தேவையற்ற துண்டுகள் உங்களுக்குக் கிடைக்கும்.

அதே package-ல் உள்ள testdisk, தனியாக undelete வசதியைக் கொண்டுள்ளது; இது FAT, exFAT, NTFS மற்றும் ext2 ஆகியவற்றுக்கு மட்டுமே பொருந்தும். ext4-க்கு photorec மட்டுமே உள்ளது.

துண்டிக்கப்பட்ட (fragmented) கோப்புகள் சிதைந்தே கிடைக்கும் என்பதை நினைவில் கொள்ளவும். ஒரு கோப்பின் blocks அனைத்தும் அடுத்தடுத்து இருப்பதாகவே carving கருதுகிறது; எனவே, disk-ன் வெவ்வேறு இடங்களில் சிதறிக்கிடக்கும் கோப்புகள் தவறாக இணைக்கப்படலாம் அல்லது விடுபடலாம். Media கோப்புகள் வலுவான headers-ஐக் கொண்டிருப்பதால், அவற்றை ஓரளவுக்குச் சரியாக மீட்க முடியும். Plain text, configuration கோப்புகள் மற்றும் source code ஆகியவற்றை மீட்க முடியாது, ஏனெனில் ஒரு shell script-ன் தொடக்கத்தைக் குறிக்கும் byte signature எதுவும் இல்லை.

தவறான இடைவெளி: தவறான path எவ்வாறு நீக்கப்பட்டது

ஒவ்வொரு rm -rf விபத்தும் ஒரு shell சிக்கலால் ஏற்படுகிறது. rm பல path-களின் பட்டியலைப் பெற்று, ஒவ்வொன்றாக நீக்குகிறது. நீங்கள் எதைக் குறிப்பிட விரும்பினீர்கள் என்பதை அது அறியாது.

ஒரு சிறிய இடைவெளிதான் இதற்கு பொதுவான காரணம்:

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

முதல் வரியில் இரண்டு arguments உள்ளன. இது முதலில் application-ஐ நீக்குகிறது, பிறகு /old-ஐ நீக்குகிறது. /old இல்லை என்றால், rm எதையும் அச்சிடாது, ஏனெனில் -f விடுபட்ட கோப்பு குறித்த பிழையை மறைத்துவிடும். அமைதி என்பது உறுதிப்படுத்தல் அல்ல.

இரண்டாவது வடிவம், ஒரு இடைவெளியைக் கொண்ட மேற்கோள் காட்டப்படாத variable ஆகும்:

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

Shell அந்த மதிப்பை whitespace அடிப்படையில் பிரிக்கிறது, எனவே rm ஆனது /srv/my மற்றும் app ஆகியவற்றை இரண்டு தனித்தனி path-களாகப் பெறுகிறது. rm -rf "$dir" என்று எழுதப்பட்டால் மட்டுமே அது ஒரே path-ஆகக் கருதப்படும்.

மூன்றாவது, காலியான variable ஆகும்; பொதுவாக அதை நிரப்ப வேண்டிய command தோல்வியடைந்தால் இது நிகழும்:

rm -rf "$TARGET"/*

TARGET அமைக்கப்படாத நிலையில், அது rm -rf /* என விரிவடையும். GNU rm அதன் அடிப்படை வடிவத்தை ஏற்க மறுக்கிறது: rm -rf / ஆனது rm: it is dangerous to operate recursively on '/' என்று அச்சிட்டு நின்றுவிடும். Glob வடிவம் இத்தகைய பாதுகாப்பைப் பெறுவதில்லை, ஏனெனில் rm இயங்குவதற்கு முன்பே shell ஆனது /*-ஐ உண்மையான top-level path-களின் பட்டியலாக மாற்றிவிடுகிறது. / அவற்றில் ஒன்றாக இல்லாததால், பாதுகாப்பு அம்சம் செயல்படாது.

அடுத்த பிழையைத் தடுக்கும் பழக்கவழக்கங்கள்

• பாதையாகப் பயன்படுத்தப்படும் ஒவ்வொரு மாறியையும் மேற்கோள் குறியீட்டிற்குள் (quote) வைக்கவும். சோதனைகள் மற்றும் சுழற்சிகளுக்குள் (loops) கூட ஒவ்வொரு முறையும் "$dir"-ஐப் பயன்படுத்தவும்.
• காலியாக இருந்தால் செயலை நிறுத்தவும். TARGET அமைக்கப்படாமல் இருந்தாலோ அல்லது காலியாக இருந்தாலோ, rm தொடங்குவதற்கு முன்பே உங்கள் செய்தியுடன் ஷெல்லை நிறுத்த rm -rf "${TARGET:?TARGET is not set}"/* உதவுகிறது. நீக்கும் செயல்களைக் கொண்ட எந்தவொரு ஸ்கிரிப்ட்டின் தொடக்கத்திலும் set -euo pipefail-ஐச் சேர்க்கவும்.
• --one-file-system-ஐச் சேர்க்கவும். நீங்கள் கொடுத்த ஆர்குமெண்டிலிருந்து வேறுபட்ட கோப்பு முறைமையில் (filesystem) உள்ள எந்தவொரு கோப்பகத்தையும் தவிர்க்குமாறு இது rm-க்குக் கட்டளையிடுகிறது. இதனால், ஒரு recursive delete செயல்பாடு, மவுண்ட் செய்யப்பட்ட பேக்கப் வால்யூமிற்குள் அல்லது bind mount-க்குள் தற்செயலாகச் சென்றுவிடாது.
• root பயனராக நீக்க வேண்டாம். ஒரு service account தனக்குச் சொந்தமானவற்றை மட்டுமே அழிக்க முடியும். ஒவ்வொரு சேவையையும் தனித்தனி சலுகையற்ற பயனராக இயக்குவதற்கான அடிப்படை காரணமே இதுதான். ஒரு குறிப்பிட்ட கணக்கினால் எவற்றை அணுக முடியும் என்பதில் உங்களுக்குத் தெளிவில்லை என்றால், ls பட்டியலிடலில் உள்ள அனுமதி பிட்களைப் படிப்பது ஒரே கட்டளையில் அதற்கு விடையளிக்கும்.
• செயல்படுவதற்கு முன்பு பட்டியலை அச்சிடவும். ஒரு ஸ்கிரிப்ட்டில், பாதைகளை உருவாக்கி, அவற்றை printf '%s\n' செய்து, வெளியீட்டைப் படித்து, அதன் பிறகு இரண்டாவது சுற்றில் நீக்கவும்.
• ஒரு trash கட்டளையை எப்போதும் கைவசம் வைத்திருக்கவும். sudo apt install trash-cli உங்களுக்கு trash-put, trash-list, trash-restore மற்றும் trash-empty ஆகியவற்றை வழங்குகிறது. நீக்கப்பட்ட கோப்புகள் ~/.local/share/Trash-க்கு நகர்த்தப்படும், மேலும் trash-empty 30 முப்பது நாட்களுக்கு மேல் பழமையான எதையும் நீக்கிவிடும்.

rm-ஐ trash-put-க்கு alias செய்வது எளிதான அடுத்த கட்டமாகத் தோன்றலாம், ஆனால் அது ஒரு பொறி. இந்த alias, அது இல்லாத அடுத்த சர்வரில் தோல்வியடையும் ஒரு பழக்கத்தை உருவாக்குகிறது. மேலும், ஸ்கிரிப்ட்களுக்குள் alias-கள் செயல்படாது, அங்குதான் அதிக பாதிப்பை ஏற்படுத்தும் தவறுகள் நடக்கின்றன. அதற்குப் பதிலாக, trash-put-ஐத் தட்டச்சு செய்வதை வழக்கமாக்கிக் கொள்ளுங்கள்.

எப்போதும் செயல்படும் ஒரே மீட்பு முறை

மேலே உள்ள அனைத்தும் ஒரு வாய்ப்பு மட்டுமே. ஆனால், பேக்கப் (backup) என்பது வாய்ப்பல்ல.

இரண்டு விஷயங்கள் ஒரு பேக்கப்பை உண்மையானதாக்குகின்றன. ஒன்று, நீங்கள் நினைவில் கொள்ளாமலேயே அது ஒரு கால அட்டவணையின்படி இயங்க வேண்டும். மற்றொன்று, அதிலிருந்து நீங்கள் குறைந்தது ஒரு முறையாவது தரவை மீட்டெடுத்திருக்க வேண்டும். யாராலும் மீட்டெடுக்கப்படாத ஒரு களஞ்சியம் (repository) என்பது வெறும் நம்பிக்கை மட்டுமே. ஏனெனில், ஒரு பேக்கப்பை பயனற்றதாக்கும் காரணிகள் (உதாரணமாக, include பட்டியலில் உள்ள தவறான பாதை அல்லது யாரும் எழுதி வைக்காத களஞ்சிய கடவுச்சொல்) நீங்கள் அதை அவசரமாக எதிர்பார்க்கும் நாளில்தான் வெளிப்படும்.

restic-ஐப் பொறுத்தவரை, மீட்பு என்பது இரண்டு கட்டளைகள் மட்டுமே.

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

நேரடியாக இயங்கும் பாதையில் (live path) தரவை மீட்டெடுப்பதற்குப் பதிலாக, ஒரு காலி கோப்பகத்தில் (empty directory) மீட்டெடுக்கவும். அப்போதுதான் எதையும் மாற்றுவதற்கு முன் இரண்டையும் ஒப்பிட்டுப் பார்க்க முடியும். VPS-ல் restic பேக்கப்களை அமைத்தல் பகுதியில் களஞ்சிய அமைப்பு மற்றும் அதை இயக்கும் systemd timer பற்றிய தகவல்கள் உள்ளன.

Borg-ஐப் பொறுத்தவரை:

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

Borg ஆவணத்தில் உள்ள பாதைகள் தொடக்க ஸ்லாஷ் (leading slash) இல்லாமல் சேமிக்கப்படுகின்றன. எனவே, srv/appdata என்பது பொருந்தும், ஆனால் /srv/appdata என்பது எதனுடனும் பொருந்தாது. borg extract தற்போதைய பணி கோப்பகத்தில் எழுதும், எனவே முதலில் cd மூலம் ஒரு தற்காலிக கோப்பகத்திற்குச் செல்லவும்.

நீங்கள் இன்னும் எதைத் தேர்ந்தெடுப்பது என்று முடிவெடுக்கவில்லை என்றால், restic மற்றும் Borg ஒப்பீடு பகுதியில் deduplication மற்றும் append-only களஞ்சியங்கள் பற்றிப் பார்க்கலாம். இதுவே, ஒரு compromised server தனது சொந்த பேக்கப் வரலாற்றை அழிப்பதைத் தடுக்கும் பண்பாகும். எந்தக் கருவியைப் பயன்படுத்தினாலும் சரி, எதையும் பயன்படுத்தாமல் இருப்பதே தவறான முடிவாகும்.

ஒரு புதிய server-ல் தரவுகள் இழப்பதற்கு ஏதுவான சூழல் உருவாவதற்கு முன்பே, இதை அமைப்பதே மிகச் சிறந்த தருணமாகும். புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்ற பகுதியில், SSH மற்றும் firewall அமைப்புடன் இதையும் சேர்த்துச் செய்ய வேண்டும்.

பிறகு, உங்கள் காலெண்டரில் ஒரு தொடர் நிகழ்வைச் சேர்க்கவும்: ஒவ்வொரு மாதமும் களஞ்சியத்திலிருந்து ஒரு கோப்பகத்தை /tmp-க்கு மீட்டெடுத்து, அந்தக் கோப்புகளைச் சரிபார்க்கவும். இந்தப் பழக்கம் மட்டுமே இந்தப் பக்கத்தில் உள்ள அனைத்துக் கருவிகளை விடவும் அதிக மதிப்புடையது.

FAQ

ext4-ல் நீக்கப்பட்ட கோப்பை என்னால் மீட்டெடுக்க முடியுமா?

பொதுவாக முடியாது. ஒரு கோப்பிற்கான கடைசி link நீக்கப்படும்போது, ext4 அதன் inode-லிருந்து extent tree-ஐ அழித்துவிடும். எனவே, அந்தத் தரவு வட்டில் எங்கு இருந்தது என்பதைப் பதிவு செய்யும் தரவுகள் எதுவும் இருக்காது. extundelete மற்றும் ext4magic ஆகியவை ext4 journal-ல் அந்த inode-ன் பழைய நகலைத் தேடும். கோப்பு நீக்கப்பட்டு சில நிமிடங்கள் மட்டுமே ஆகியிருந்து, கோப்பு முறைமை (filesystem) அமைதியாக இருந்திருந்தால் மட்டுமே இது உதவும். இந்த இரண்டு திட்டங்களும் தற்போது பராமரிக்கப்படுவதில்லை. இவற்றை unmount செய்யப்பட்ட சாதனம் அல்லது disk image-ல் மட்டுமே இயக்க வேண்டும்; mount செய்யப்பட்ட கோப்பு முறைமையில் ஒருபோதும் இயக்கக்கூடாது. முதலில் sudo dumpe2fs -h /dev/vdb1 | grep -i journal பயன்படுத்தி நீங்கள் எதில் வேலை செய்கிறீர்கள் என்பதைச் சரிபார்க்கவும்.

ஒரு service இன்னும் நீக்கப்பட்ட கோப்பைத் திறந்து வைத்துள்ளது. அதை என்னால் திரும்பப் பெற முடியுமா?

ஆம், இதுவே சிறந்த சூழல். ஒரு process கோப்பைத் திறந்து வைத்திருக்கும் வரை, அதன் inode மற்றும் தரவுத் தொகுதிகள் (data blocks) ஒதுக்கீடு செய்யப்பட்டிருக்கும், எனவே தரவை இன்னும் படிக்க முடியும். அந்த service-ஐ restart செய்ய வேண்டாம், ஏனெனில் கடைசி descriptor-ஐ மூடுவது நீக்குதல் செயல்பாட்டை முழுமையாக்கிவிடும். link count 0 ஆக உள்ள திறந்த கோப்புகளைப் பட்டியலிட sudo lsof +L1-ஐ இயக்கவும். PID மற்றும் file descriptor எண்ணைக் குறித்துக்கொண்டு, sudo cp /proc/1234/fd/3 /mnt/rescue/events.log மூலம் /proc வழியாக நகலெடுக்கவும். இந்த நகலை வேறொரு கோப்பு முறைமையில் சேமிக்கவும். descriptor எண்ணிற்குப் பதிலாக mem என்று காட்டப்படும் உள்ளீடுகள் memory mapped செய்யப்பட்டவை, அவற்றிலிருந்து நகலெடுக்க /proc/<pid>/fd பாதை எதுவும் இருக்காது.

மீட்பு கருவியை (recovery tool) வட்டில் நேரடியாக இயக்குவதற்குப் பதிலாக, ஏன் disk image எடுக்க வேண்டும்?

ஏனெனில் ஒவ்வொரு கருவியும் அதன் வெளியீட்டை எங்காவது எழுத வேண்டும். நீங்கள் தரவை மீட்க முயற்சிக்கும் கோப்பு முறைமையில் ஏதேனும் எழுதினால், அது உங்கள் தரவு இன்னும் இருக்கும் free blocks-ன் மேல் எழுதப்பட வாய்ப்புள்ளது. முதலில் sudo ddrescue -n /dev/vdb1 /mnt/rescue/vdb1.img /mnt/rescue/vdb1.map மூலம் partition-ஐ வேறொரு சாதனத்திற்கு நகலெடுக்கவும், பின்னர் photorec-ஐ அந்த image கோப்பின் மீது பயன்படுத்தவும். அசல் வட்டில் தரவு எழுதப்பட்ட பிறகு அதை மாற்ற முடியாது, ஆனால் image கோப்பு இருந்தால், அதே தரவுத் தொகுதிகளை வைத்து வேறொரு கருவியைப் பயன்படுத்தி மீண்டும் முயற்சிக்க முடியும்.

rm -rf / கட்டளை இன்னும் Linux அமைப்பை அழிக்குமா?

வெறும் கட்டளை மட்டும் அழிக்காது. GNU rm அதை மறுத்து rm: it is dangerous to operate recursively on '/' என்ற செய்தியை அச்சிடும். ஆபத்தான வடிவங்கள் வேறு வழிகளில் வருபவை. TARGET unset செய்யப்பட்ட நிலையில் rm -rf "$TARGET"/* கட்டளை rm -rf /* என விரிவடையும். அப்போது shell, rm-க்கு உண்மையான top-level கோப்பகங்களின் பட்டியலை வழங்கும். அதில் / இல்லாததால், பாதுகாப்புத் தடுப்பு (guard) செயல்படாது. அதற்குப் பதிலாக "${TARGET:?TARGET is not set}" என்று எழுதினால், rm இயங்குவதற்கு முன்பே shell நின்றுவிடும்.

கோப்பு முறைமை snapshot என்பது ஒரு backup-ஆ?

இல்லை. btrfs அல்லது ZFS snapshot என்பது அது பாதுகாக்கும் தரவு இருக்கும் அதே pool-ல் தான் அமர்ந்திருக்கும். எனவே, ஒரு disk செயலிழந்தாலோ அல்லது pool அழிந்தாலோ இரண்டுமே ஒரே நேரத்தில் அழிந்துவிடும். LVM snapshot-க்கு நிலையான அளவு (fixed size) என்ற கூடுதல் சிக்கல் உள்ளது: அது நிரம்பியவுடன், kernel அதைச் செல்லாததாக்கிவிடும், அதன் உள்ளடக்கங்களும் அழிந்துவிடும். இரண்டு நிமிடங்களுக்கு முன்பு செய்த தவறைத் திருத்த snapshot-கள் மிகச் சிறந்தவை. மற்ற அனைத்துத் தேவைகளுக்கும், தனி வன்பொருளில் (separate hardware) ஒரு repository-ஐப் பராமரிக்கவும்.