Disk to'ldi: 500 xato, buzilgan .htaccess va bazani tiklash

Hosting diski to'lib qolishi ko'pchilik o'ylagandan ko'ra jiddiyroq oqibatlarga olib keladi. Bir qarashda hammasi oddiy ko'rinadi: joy tugadi, keraksiz fayllarni o'chirsangiz, sayt yana ishlaydi. Amalda esa disk to'lgan paytda sayt ichida yozilayotgan fayllar yarim yo'lda uzilib qoladi. Natijada joy bo'shatilgandan keyin ham sayt 500 xato berishda davom etadi, chunki muhim fayllar allaqachon buzilgan bo'ladi. Ushbu maqolada disk to'lishining odatiy oqibatlarini va ularni ketma-ket tuzatish tartibini ko'rib chiqamiz.

Disk to'lganda nima sodir bo'ladi

Dastur faylni yozish uchun avval uni ochadi, eski tarkibini tozalaydi va yangi ma'lumotni yoza boshlaydi. Agar shu jarayon o'rtasida disk kvotasi tugasa, fayl bo'sh yoki chala holda qoladi. WordPress kabi tizimlar .htaccess faylini doimiy havolalar sozlamalarini saqlaganda, kesh yoki xavfsizlik plaginlari ishlaganda qayta yozadi. Agar shu payt joy qolmagan bo'lsa, fayl yarmida uzilib qoladi va Apache uni o'qiy olmay butun saytga 500 xato qaytaradi.

Ma'lumotlar bazasi ham zarar ko'radi. MySQL jadvalga yozolmasa so'rov xato bilan tugaydi, ba'zi hollarda esa jadval buzilgan deb belgilanadi. Sayt foydalanuvchisi buni Error establishing a database connection yoki bo'sh oq sahifa ko'rinishida ko'radi. Bundan tashqari PHP sessiya fayllarini saqlay olmaydi, pochta xatlari qabul qilinmaydi, kesh fayllari 0 bayt bo'lib qoladi.

Birinchi qadam: diagnoz va joy bo'shatish

Avval muammo aynan diskda ekaniga ishonch hosil qiling. Hosting panelida disk hajmi va uning chegarasi ko'rsatiladi, sayt xatolar jurnalida esa odatda No space left on device yoki Disk quota exceeded yozuvlari uchraydi. sayt.uz mijozlari ISPmanager panelini kabinetdan ochib, foydalanuvchi resurslari bo'limida bu ma'lumotni ko'rishlari mumkin.

So'ng joyni bo'shating. Eng tez natija beradigan joylar — eski zaxira arxivlari, katta jurnal fayllari va kesh papkalari. SSH orqali eng katta papkalarni quyidagicha topish mumkin:

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

Zaxira plaginlari, masalan UpdraftPlus, odatda arxivlarni wp-content ichida saqlaydi va ular bir necha gigabaytgacha yetishi mumkin. Kerakli arxivni kompyuteringizga yuklab oling, qolganlarini o'chiring. Jurnal fayllarini o'chirish o'rniga bo'shatish xavfsizroq, chunki ba'zi dasturlar ochiq faylga yozishda davom etadi:

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

Ikkinchi qadam: buzilgan .htaccess

Joy bo'shagandan keyin ham 500 xato qolsa, birinchi gumon .htaccess fayliga tushadi. Uni oching va oxirini tekshiring: agar fayl yarim qatorda uzilgan bo'lsa, <IfModule> bloki yopilmagan bo'lsa yoki fayl umuman bo'sh bo'lsa, u disk to'lganda buzilgan. Apache xatolar jurnalida bunday holatda RewriteRule: bad argument line yoki Invalid command kabi xabarlar ko'rinadi.

WordPress sayti uchun eng tez yechim — faylning nusxasini saqlab qo'yib, uni standart tarkib bilan almashtirish:

# 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

Agar faylda xavfsizlik plagini, kesh yoki yo'naltirish qoidalari bo'lgan bo'lsa, ularni zaxira nusxadan yoki plagin sozlamalarini qayta saqlash orqali tiklang. WordPress boshqaruv panelida "Sozlamalar — Doimiy havolalar" sahifasini ochib "Saqlash" tugmasini bosish ham standart qoidalarni qayta yozadi, lekin buning uchun admin panel ochilishi kerak.

0 baytli PHP fayllarni topish

Disk to'lgan paytda plagin yoki yadro yangilanayotgan bo'lsa, PHP fayllar ham bo'sh qolishi mumkin. Bunday fayllar saytning ayrim sahifalarini yoki butun saytni ishdan chiqaradi. Oxirgi bir sutkada o'zgargan bo'sh fayllarni quyidagicha topasiz:

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

Topilgan fayllarni zaxira nusxadan qaytaring yoki plaginni qayta o'rnating. WordPress yadrosi fayllari bo'sh bo'lsa, xuddi shu versiyadagi rasmiy arxivdan wp-admin va wp-includes papkalarini almashtirish mumkin, wp-content va wp-config.php ga esa tegmang.

Uchinchi qadam: ma'lumotlar bazasini tekshirish

Bazani tekshirish uchun phpMyAdmin'da jadvallarni belgilab Check table amalini bajaring yoki SSH orqali mysqlcheck buyrug'idan foydalaning:

mysqlcheck -u baza_user -p --check baza_nomi

Natijada har bir jadval yonida OK yozilishi kerak. MyISAM jadvallari buzilgan bo'lsa, ularni ta'mirlash mumkin:

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

Hozirgi WordPress va boshqa zamonaviy tizimlar ko'pincha InnoDB jadvallaridan foydalanadi. InnoDB uchun REPAIR TABLE ishlamaydi, ammo bu dvigatel tranzaksiyalar bilan ishlagani uchun chala yozuvlardan ancha yaxshi himoyalangan. Agar InnoDB jadvali haqiqatan buzilgan bo'lsa, eng ishonchli yo'l — bazani zaxira nusxadan tiklash. Bunday holatda o'zingiz server darajasidagi tiklash rejimlarini yoqishga urinmang, texnik yordamga murojaat qiling.

Misol: klinika sayti qanday tiklandi

Toshkentdagi xususiy klinikaning example.uz sayti WordPress'da ishlaydi va onlayn qabulga yozilish formasi bor. Kechasi zaxira plagini to'liq arxiv yarata boshlagan va disk kvotasini to'ldirgan. Ertalab sayt 500 xato berayotgan edi. Administrator eski arxivlarni o'chirib joy bo'shatdi, lekin xato yo'qolmadi. .htaccess fayli ochilganda u xavfsizlik plagini qoidalari o'rtasida uzilib qolgani ma'lum bo'ldi. Fayl standart tarkib bilan almashtirilgach, sayt ochildi, ammo qabul formasi ishlamadi.

mysqlcheck natijasi formadan yozuvlarni saqlaydigan plagin jadvali buzilganini ko'rsatdi. Bu eski MyISAM jadval bo'lgani uchun --auto-repair yordam berdi. Shundan keyin xavfsizlik plagini sozlamalari qayta saqlanib, uning .htaccess qoidalari tiklandi, zaxira plagini esa arxivlarni hostingdan tashqariga yuboradigan qilib sozlandi.

Qayta takrorlanmasligi uchun

Disk to'lishi kamdan-kam hollarda to'satdan sodir bo'ladi, odatda u haftalar davomida asta-sekin yig'iladi. Shuning uchun panelda disk hajmini oyiga kamida bir marta ko'rib chiqing. Zaxira plaginlarida saqlanadigan nusxalar sonini cheklang va ularni tashqi omborga yuboring. debug.log faylini faqat nosozlikni aniqlash vaqtida yoqing, ish tugagach WP_DEBUG_LOG ni o'chirib qo'ying. Agar sayt tabiiy ravishda o'sib borayotgan bo'lsa, tarif hajmini oldindan oshirish masalasini sayt.uz kabinetidan yoki texnik yordam orqali hal qilish mumkin.