Gece başlayan yedek sabah hâlâ yüzde 73 gösteriyor, ikinci deneme ise birkaç dakika sonra hata veriyor. Site açık olsa da işi tekrar tekrar başlatmak diski dolduruyor ve ilk hatanın kanıtlarını belirsizleştiriyor.
Yavaş ilerleyen bir yedek ile gerçekten takılmış bir işlem aynı şey değildir; önce hatanın hangi aşamada oluştuğunu belirleyip son geçerli kurtarma noktasını korumak gerekir.
Bu konu ne anlama gelir?
Yedekleme çalışanı anlamlı ilerleme göstermiyorsa işlem takılmıştır; süreç eksiksiz ve kullanılabilir paket üretmeden sonlanırsa başarısızdır. Arşiv oluşturma, veritabanı dışa aktarma, yerel geçici alan ve uzak hedefe yükleme ayrı aşamalardır. Bu yüzden wp-admin yüzdesi tek başına nedeni göstermez.
- Arşiv boyutunun büyümesi veya yeni günlük satırları yavaş da olsa ilerlemeyi, değişmeyen zaman damgaları ise gerçek durmayı gösterir.
- Büyük ortam dosyaları, okunamayan yollar, yetersiz geçici alan, çalışma süresi sınırı ve uzak depolama zaman aşımı farklı aşamalarda hata oluşturur.
- Çok büyük bir sitede dosya ve günlükler değişmeye devam ediyorsa tek bir yavaş işi iptal etmek yerine izlemek doğru olabilir.
Gerçekçi bir WordPress örneği
Gece başlayan yedek sabah hâlâ yüzde 73 gösteriyor. Geçici arşiv iki saattir değişmemiş ve günlük yükleme aşamasında kesilmiş. İşi yeniden başlatmak, olası depolama veya ağ sorununu çözmeden bir büyük geçici dosya daha oluşturacak. Önce iş bilgilerini saklamak ve yerelde eksiksiz bir arşiv bulunup bulunmadığını denetlemek gerekir.
Neden önemlidir ve ne zaman incelemelisiniz?
Zamanlanmış yedekler çakışıyorsa, paketler sürekli eksik kalıyorsa veya son geçerli kurtarma noktası saklama politikasının izin verdiğinden eskiyse sorunu inceleyin. Önce yavaş çalışan işlemi takılmış olandan ayırın: Dosya boyutlarının değişmesi ve yeni günlük satırları etkinliği gösterir; dosyalar, zaman damgaları ve günlük değişmiyorsa işlem büyük olasılıkla durmuştur.
Yeni başlayanlar için anlaşılır yol
- İptal etmeden önce iş kimliğini, başlangıç zamanını, bildirilen son aşamayı, günlüğün son satırlarını ve paket boyutunu kaydedin.
- Sunucudaki boş alanı ve inode sayısını, ardından uzak hedefin kotasını ve erişilebilirliğini kontrol edin.
- Yalnızca veritabanı veya büyük bir medya dizini hariç dosyalar gibi tek bir küçük tanı yedeği çalıştırın.
- Belirlediğiniz nedeni düzeltin. Yalnızca hiçbir çalışan işlemin kullanmadığı geçici paketleri kaldırın ve bir kez daha deneyin.
- Tamamlanan paketi açın ve yalıtılmış ortamda geri yükleyin. Başarı mesajı tek başına kurtarma testi değildir.
İleri teknik yol
Hatanın zamanını PHP, web sunucusu, sistem ve yedekleme günlükleriyle karşılaştırın. Bellek tükenmesi, çalışma süresi sınırı, sonlandırılan işlemler, okunamayan yollar, dosya boyutu sınırları ve bağlantı zaman aşımını arayın. Yerelde eksiksiz arşiv varsa yedek oluşturulmuş, sorun aktarım veya uzak depolama aşamasında çıkmıştır. Arşiv yoksa ulaşılan son dosya ya da veritabanı adımına bakın.
Büyük sitelerde arşivin nasıl büyüdüğünü ve işlem sırasında hangi yolların değiştiğini izleyin. Olağan dışı büyük tek bir dosya, yanlışlıkla tekrar yedeklenen eski arşivler veya çok sayıda küçük dosya içeren bir dizin işlemi uzatabilir. Başarılı çalışmanın süresini ve paket boyutunu daha sonraki incelemeler için kaydedin.
Riskler, sık hatalar ve geri dönüş planı
- Tekrarlanan denemeler diski doldurabilir, çalışan işlemleri çakıştırabilir ve ilk anlamlı hatayı gizleyebilir.
- Etkin işlemin kullandığı geçici dosyaları silmek, yavaş yedeğin başarısız olmasına yol açar.
- Tüm PHP sınırlarını gelişigüzel artırmak izin veya uzak depolama sorununu çözmeden sunucu yükünü büyütebilir.
- Yeni paket geri yükleme testini geçene kadar son doğrulanmış kurtarma noktasının yerini almamalıdır.
Tanı amacıyla yaptığınız değişiklik işe yaramazsa eski zamanlama ve ayarlara dönün, günlükleri saklayın ve son çalışan yedeği koruyun. Aynı işi tekrar çalıştırmak yerine hatanın çıktığı aşamayla birlikte barındırma veya depolama sağlayıcısına başvurun.
AIOWS nasıl yardımcı olur?
AIOWS Yedekleme Yöneticisi
AIOWS Yedekleme Yöneticisi, desteklenen yedekleme işlerini ve seçilen kapsamı tek yerde gösterir. Bir iş takılmış görünüyorsa iptal etmeden önce başlangıç zamanını, hedefi, mevcut aşamayı ve paket boyutunu kaydedin. Daha küçük bir veritabanı veya dosya yedeği, aynı yükü hemen tekrarlamadan sorunun hangi bölümde olduğunu bulmanıza yardımcı olabilir.
Modül sunucudaki kaynak sınırlarını kaldıramaz, okunamayan dosyaları onaramaz veya üçüncü taraf depolama bağlantısını garanti edemez. İş bilgilerini sunucu ve PHP günlükleri, yerel kapasite ve uzak hedefin durumuyla birlikte değerlendirin. Nedeni düzelttikten sonra tek bir kontrollü deneme yapın ve ortaya çıkan paketi yalıtılmış bir geri yüklemeyle sınayın.
Test başarılı olana kadar önceki doğrulanmış kurtarma noktasını saklayın. Yaptığınız düzeltmeyi, başarılı işin süresini ve boyutunu, ayrıca bir sonraki planlanmış çalışmayı not edin. Aynı site daha sonra benzer aşamada yavaşlarsa bu bilgiler yararlı bir karşılaştırma sağlar.
AIOWS Yedekleme Yöneticisi’ni inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress geri yükleme başarısız veya takılıyor
- Büyük WordPress sitesi yedekleme: Güvenli adım adım rehber
- WordPress yedeğini doğrulama: Geri yüklenebilirliği kanıtlayın
Sonuç ve önerilen yol
Takılan yedeği sürekli Başlat düğmesine basarak çözmeye çalışmayın. İş kanıtlarını koruyun, duran aşamayı bulun, yalnızca o depolama, izin, kaynak veya ağ koşulunu düzeltin ve tek bir kontrollü tekrar yapın. Ortaya çıkan paket bağımsız geri yükleme testini geçmeden işi tamamlanmış saymayın.
