Web kök dizininde htaccess-oldadlı birkaç dosya bulunması gerçek bir geri alma planı değildir. Hangi kopyanın hangi siteye ait olduğu, ne zaman alındığı ve gerçekten çalışan sürümü içerip içermediği bilinmiyorsa kesinti sırasında yanlış dosya geri yüklenebilir.
Kullanılabilir bir .htaccessyedeği; site adı, etkin dosya yolu, tarih, sağlama toplamı ve değişiklik gerekçesiyle tanımlanmış tam kopyadır. Geri yükleme yöntemi de WordPress açılmadığında çalışacak bağımsız bir hosting erişimine dayanmalıdır.
İyi bir yedek nasıl olmalı?
Yedek, etkin dosyanın değişiklikten hemen önce alınmış eksiksiz kopyası olmalıdır. Dosya adında site veya host, UTC tarih-saat ve kısa sürüm bilgisi bulunması doğru kopyayı seçmeyi kolaylaştırır. Sağlama toplamı, içeriğin sonradan değişmediğini doğrular.
Dosyanın sahibi ve izinleri de kaydedilmelidir. Yalnız içerik geri yüklenip sahiplik modeli bozulursa WordPress veya web sunucusu dosyayı kullanamayabilir.
Gerçekçi bir örnek
Bir yönetici güvenlik kuralı eklemeden önce etkin dosyanın kopyasını site-example-20260823T1200Z.htaccessadıyla özel yedek dizinine koyar. Değişiklik 500 hatası üretince hosting dosya yöneticisinden bu sürümü geri getirir; içerik, sahiplik ve izinleri doğruladıktan sonra site yeniden açılır.
Neden web kökü dışında saklanmalı?
Web kök dizinindeki yedek dosyalar yanlış sunucu yapılandırmasında ziyaretçiler tarafından indirilebilir ve erişim kurallarını açığa çıkarabilir. Ayrıca hatalı bir dağıtım aynı dizindeki etkin dosyayla yedeği birlikte silebilir veya değiştirebilir.
Bazı arşiv araçları noktayla başlayan dosyaları varsayılan olarak atlar. “Tam site yedeği” olarak görünen pakette .htaccessbulunduğunu ayrıca doğrulayın.
Yedekleme adımları
- Etkin web kök dizinindeki gerçek
.htaccessyolunu doğrulayın. - Dosyanın tam kopyasını web üzerinden erişilemeyen bir konuma alın.
- Site, tarih, dosya hash’i, sahiplik ve izin bilgilerini kaydedin.
- Planlanan değişikliğin amacını, beklenen URL davranışını ve test adreslerini not edin.
- Yalnız hedeflenen bölümü değiştirin; önceki yedeğin üzerine yazmayın.
Geri yükleme provası
Yedek ancak geri yüklenebildiği doğrulanırsa işe yarar. Canlı siteyi etkilemeyen ayrı bir test ortamında bilinen bir hata oluşturup bağımsız hosting erişimiyle önceki sürümü geri getirme adımlarını prova edin. Canlı ortamla aynı sunucu yolu ve izin modelini kullanmaya dikkat edin.
Geri yüklemeden sonra dosya hash’ini, sahibini ve izinlerini karşılaştırın. Ana sayfa, kalıcı bağlantı, giriş, statik dosya, REST, form ve gerçek 404 adreslerini temiz istemciden sınayın. Kurtarmanın ne kadar sürdüğünü ve hangi erişim hesabının kullanıldığını kaydedin.
Sık hatalar
- Belirsiz adlandırma nedeniyle başka siteye ait dosyayı geri yüklemek.
- Yedekleri genel web kökünde tutarak sunucu kurallarını dışarı açmak.
- Yalnız WordPress paneline bağlı geri alma yöntemi kullanmak.
- Tek yedeğin üzerine her değişiklikte yeniden yazmak.
- Dosya içeriğini koruyup sahiplik ve izinleri kaydetmemek.
AIOWS nasıl yardımcı olur?
AIOWS Htaccess Düzenleyici
AIOWS Htaccess Düzenleyici, dosyayı kaydetmeden önce yedek oluşturur; bu yedekle son düzenleme geri alınabilir. Etkin dosyanın ve değiştirilen bölümün aynı arayüzde görünmesi, küçük değişiklikleri takip etmeyi kolaylaştırır.
Panel içindeki yedek tek kurtarma yöntemi olmamalıdır. Hatalı kural WordPress’i kapatırsa araca erişilemez. Bu nedenle web kök dizini dışında sürümlü kopya ve bağımsız hosting dosya erişimi ayrıca korunmalıdır.
AIOWS Htaccess Düzenleyici’yi inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress .htaccess Dosyası: Başlangıç Rehberi
- WordPress .htaccess Dosyasına Yazamıyor: Nedenler ve Çözümler
- WordPress .htaccess Düzenlemesinden Sonra 500 Hatası
Sonuç
Her değişiklikten önce tanımlı ve sürümlü kopya alın; yedeği web kök dizini dışında saklayın ve WordPress çalışmasa da kullanılabilecek geri yükleme yöntemini önceden prova edin.
