Диск тўлди: 500 хато, бузилган .htaccess ва базани тиклаш

Хостинг диски тўлиб қолиши кўпчилик ўйлагандан кўра жиддийроқ оқибатларга олиб келади. Бир қарашда ҳаммаси оддий кўринади: жой тугади, кераксиз файлларни ўчирсангиз, сайт яна ишлайди. Амалда эса диск тўлган пайтда сайт ичида ёзилаётган файллар ярим йўлда узилиб қолади. Натижада жой бўшатилгандан кейин ҳам сайт 500 хато беришда давом этади, чунки муҳим файллар аллақачон бузилган бўлади. Ушбу мақолада диск тўлишининг одатий оқибатларини ва уларни кетма-кет тузатиш тартибини кўриб чиқамиз.

Диск тўлганда нима содир бўлади

Дастур файлни ёзиш учун аввал уни очади, эски таркибини тозалайди ва янги маълумотни ёза бошлайди. Агар шу жараён ўртасида диск квотаси тугаса, файл бўш ёки чала ҳолда қолади. WordPress каби тизимлар .htaccess файлини доимий ҳаволалар созламаларини сақлаганда, кеш ёки хавфсизлик плагинлари ишлаганда қайта ёзади. Агар шу пайт жой қолмаган бўлса, файл ярмида узилиб қолади ва Apache уни ўқий олмай бутун сайтга 500 хато қайтаради.

Маълумотлар базаси ҳам зарар кўради. MySQL жадвалга ёзолмаса сўров хато билан тугайди, баъзи ҳолларда эса жадвал бузилган деб белгиланади. Сайт фойдаланувчиси буни Error establishing a database connection ёки бўш оқ саҳифа кўринишида кўради. Бундан ташқари PHP сессия файлларини сақлай олмайди, почта хатлари қабул қилинмайди, кеш файллари 0 байт бўлиб қолади.

Биринчи қадам: диагноз ва жой бўшатиш

Аввал муаммо айнан дискда эканига ишонч ҳосил қилинг. Хостинг панелида диск ҳажми ва унинг чегараси кўрсатилади, сайт хатолар журналида эса одатда No space left on device ёки Disk quota exceeded ёзувлари учрайди. sayt.uz мижозлари ISPmanager панелини кабинетдан очиб, фойдаланувчи ресурслари бўлимида бу маълумотни кўришлари мумкин.

Сўнг жойни бўшатинг. Энг тез натижа берадиган жойлар — эски захира архивлари, катта журнал файллари ва кеш папкалари. SSH орқали энг катта папкаларни қуйидагича топиш мумкин:

du -xh -d 2 ~ 2>/dev/null | sort -h | tail -15

Захира плагинлари, масалан UpdraftPlus, одатда архивларни wp-content ичида сақлайди ва улар бир неча гигабайтгача етиши мумкин. Керакли архивни компьютерингизга юклаб олинг, қолганларини ўчиринг. Журнал файлларини ўчириш ўрнига бўшатиш хавфсизроқ, чунки баъзи дастурлар очиқ файлга ёзишда давом этади:

: > ~/www/example.uz/wp-content/debug.log

Иккинчи қадам: бузилган .htaccess

Жой бўшагандан кейин ҳам 500 хато қолса, биринчи гумон .htaccess файлига тушади. Уни очинг ва охирини текширинг: агар файл ярим қаторда узилган бўлса, <IfModule> блоки ёпилмаган бўлса ёки файл умуман бўш бўлса, у диск тўлганда бузилган. Apache хатолар журналида бундай ҳолатда RewriteRule: bad argument line ёки Invalid command каби хабарлар кўринади.

WordPress сайти учун энг тез ечим — файлнинг нусхасини сақлаб қўйиб, уни стандарт таркиб билан алмаштириш:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Агар файлда хавфсизлик плагини, кеш ёки йўналтириш қоидалари бўлган бўлса, уларни захира нусхадан ёки плагин созламаларини қайта сақлаш орқали тикланг. WordPress бошқарув панелида "Созламалар — Доимий ҳаволалар" саҳифасини очиб "Сақлаш" тугмасини босиш ҳам стандарт қоидаларни қайта ёзади, лекин бунинг учун админ панел очилиши керак.

0 байтли PHP файлларни топиш

Диск тўлган пайтда плагин ёки ядро янгиланаётган бўлса, PHP файллар ҳам бўш қолиши мумкин. Бундай файллар сайтнинг айрим саҳифаларини ёки бутун сайтни ишдан чиқаради. Охирги бир суткада ўзгарган бўш файлларни қуйидагича топасиз:

find ~/www/example.uz -type f -name '*.php' -size 0 -mmin -1440

Топилган файлларни захира нусхадан қайтаринг ёки плагинни қайта ўрнатинг. WordPress ядроси файллари бўш бўлса, худди шу версиядаги расмий архивдан wp-admin ва wp-includes папкаларини алмаштириш мумкин, wp-content ва wp-config.php га эса тегманг.

Учинчи қадам: маълумотлар базасини текшириш

Базани текшириш учун phpMyAdmin'да жадвалларни белгилаб Check table амалини бажаринг ёки SSH орқали mysqlcheck буйруғидан фойдаланинг:

mysqlcheck -u baza_user -p --check baza_nomi

Натижада ҳар бир жадвал ёнида OK ёзилиши керак. MyISAM жадваллари бузилган бўлса, уларни таъмирлаш мумкин:

mysqlcheck -u baza_user -p --auto-repair --check baza_nomi

Ҳозирги WordPress ва бошқа замонавий тизимлар кўпинча InnoDB жадвалларидан фойдаланади. InnoDB учун REPAIR TABLE ишламайди, аммо бу двигатель транзакциялар билан ишлагани учун чала ёзувлардан анча яхши ҳимояланган. Агар InnoDB жадвали ҳақиқатан бузилган бўлса, энг ишончли йўл — базани захира нусхадан тиклаш. Бундай ҳолатда ўзингиз сервер даражасидаги тиклаш режимларини ёқишга уринманг, техник ёрдамга мурожаат қилинг.

Мисол: клиника сайти қандай тикланди

Тошкентдаги хусусий клиниканинг example.uz сайти WordPress'да ишлайди ва онлайн қабулга ёзилиш формаси бор. Кечаси захира плагини тўлиқ архив ярата бошлаган ва диск квотасини тўлдирган. Эрталаб сайт 500 хато бераётган эди. Администратор эски архивларни ўчириб жой бўшатди, лекин хато йўқолмади. .htaccess файли очилганда у хавфсизлик плагини қоидалари ўртасида узилиб қолгани маълум бўлди. Файл стандарт таркиб билан алмаштирилгач, сайт очилди, аммо қабул формаси ишламади.

mysqlcheck натижаси формадан ёзувларни сақлайдиган плагин жадвали бузилганини кўрсатди. Бу эски MyISAM жадвал бўлгани учун --auto-repair ёрдам берди. Шундан кейин хавфсизлик плагини созламалари қайта сақланиб, унинг .htaccess қоидалари тикланди, захира плагини эса архивларни хостингдан ташқарига юборадиган қилиб созланди.

Қайта такрорланмаслиги учун

Диск тўлиши камдан-кам ҳолларда тўсатдан содир бўлади, одатда у ҳафталар давомида аста-секин йиғилади. Шунинг учун панелда диск ҳажмини ойига камида бир марта кўриб чиқинг. Захира плагинларида сақланадиган нусхалар сонини чекланг ва уларни ташқи омборга юборинг. debug.log файлини фақат носозликни аниқлаш вақтида ёқинг, иш тугагач WP_DEBUG_LOG ни ўчириб қўйинг. Агар сайт табиий равишда ўсиб бораётган бўлса, тариф ҳажмини олдиндан ошириш масаласини sayt.uz кабинетидан ёки техник ёрдам орқали ҳал қилиш мумкин.