WordPress Yedekleme Takılıyor mu? Nedenleri ve Çözümleri

Yüzde 45’te duruyorsa WordPress yedekleme takılıyor gibi görünür; çoğu zaman takılmamıştır. Baktığınız çubuğu tarayıcınız çiziyor. Çubuğun anlattığı iş ise sunucunuzda çalışıyor — ikisi arasındaki bağ koptuğunda çubuğunuz durur, iş onsuz devam eder.

O ekranda birbirinin aynısı görünen üç ayrı durum vardır: hâlâ çalışan bir iş, kimse bakmazken biten bir iş ve hiç başlamamış bir iş. Bu rehber üçünü birbirinden ayırır. Her birinin bir sonraki adımı farklıdır ve yalnızca biri sizden bir şey ister.

Çalışıyor mu, yoksa sayfa mı haberdar değil?

Hiçbir şeyi iptal etmeden önce tek bir soruyu yanıtlayın: ortada hâlâ bir iş var mı?

İlerleme penceresini kapatın ve yedek listesini açın.O listeyi, paket tamamlandığında sunucunuz yazar. Çubuğu ise beklerken tarayıcınız çizer. Yedeğiniz listedeyse iş bitmiştir; çubuğun en son ne yazdığı fark etmez.

Bu, nadir değil olağan sonuçtur. Veritabanı aşamasında yüzde 45’te duran, uzun süre kıpırdamayan ve siz vazgeçip sekmeyi kapattıktan sonra yüzde 100’e ulaşan bir pencere: sonunu hiç görmezsiniz. Yedeğinizi ekrandan değil listeden bulursunuz.

Hiçbir şeyin değişip değişmediğine bakın.İki işaret var ve birbirlerini yararlı biçimde yalanlarlar:

• diskteki paket dosyanız büyüyorsa ya da geçen süre artmayı sürdürüyorsa bir şey çalışıyordur;
• dosya boyutu, aşama ve geçen süre dakikalardır yerinde duruyorsa çalıştırıcınız muhtemelen durmuştur.

Öğrenmek için Başlat’a yeniden basmayın.İkinci bir iş birincinin yerini almaz. Aynı disk, aynı veritabanı ve aynı PHP süreçleri için onunla yarışır; üstelik ilk hatayı sizin için okunmaz hale getirir.

Ekrandaki yüzde aslında nedir?

O sayı işinizin ölçümü değildir. Tarayıcınızın toplamayı başardığı son mesajdır.

Yedeğiniz sunucuda ayrık bir çalıştırıcı olarak koşar. Bu çalıştırıcı ilerledikçe durumunu yazar: aşama, ilerleme, geçen süre. Baktığınız sayfa bu durumu birkaç saniyede bir sorar ve çubuğu gelen yanıttan çizer. Kendi başına başarısız olabilen bir HTTP isteğiyle birbirine bağlanmış iki ayrı şey.

O istek gelmez olduğunda çubuğunuz kendisine verilen son sayıda donar ve çalıştırıcı, sizin artık dinlemediğinizi hiç öğrenmez. Dizüstü bilgisayarınızın uykuya geçmesi bunun için yeter. Tarayıcınızın arka planda kıstığı bir sekme, boştaki bağlantıyı kapatan bir vekil sunucu ya da uç noktayı hız sınırına almaya başlayan bir güvenlik eklentisi de aynı sonucu verir.

Eklenti bunu kendisi söylüyor. Hata kataloğunda AIOWS-BK-E2000şöyle geçiyor: “Tarayıcı, yedekleme ilerleme uç noktasıyla bağlantıyı kaybetti. Yedekleme sunucuda hâlâ çalışıyor olabilir — birazdan yedekler listesini kontrol edin.”Bu mesaj yedeğinizi değil, sayfanızı anlatıyor.

Uzun aşamalar sizi aynı sayıda tutar ve bu bir arıza değildir. Çok sayıda tablo boşaltan bir veritabanı aşaması ya da binlerce küçük dosyalık bir dizini gezen bir dosya aşaması seyrek bildirir, çünkü her iş birimi küçüktür. Çubuğunuz dakikalarca kıpırdamadan durup yine de gayet sağlıklı olabilir.

Yani yüzde, sayfanızın en son ne duyduğunu yanıtlar. Yedek listesi ise elinizde bir paket olup olmadığını. Sorulmaya değen yalnızca ikincisidir.

Hiç başlamayan zamanlanmış yedek

Bu durum farklı görünür ve olması gerekenden çok daha sık karşınıza çıkar. Zamanlamayı kaydedersiniz, sıradaki çalışma saati gelip geçer ve hiçbir şey olmaz. Gecikmeli değil. Hiç.

WP-Cron, cron değildir.Zamanlayıcısı yoktur. WordPress, vakti gelen işleri ancak biri sitenizi ziyaret ettiğinde denetler ve onları çalıştırmak için kendi wp-cron.phpdosyasına bir istek atar. Siteniz sessizse o an hiç gelmeyebilir.

WordPress’te aynı sessizliği üreten dört ayrı neden vardır ve her biri farklı bir çözüm ister:

• Hostinginiz isteği geri çeviriyor.wp-cron.php401 ya da 403 yanıtlıyor, dolayısıyla zamanlanmış hiçbir şey çalışmıyor.
• Siteniz kendisine ulaşamıyor.Geri döngü isteği baştan başarısız oluyor — sunucunuzun kendi alan adını çağırmasını engelleyen bir DNS ya da güvenlik duvarı düzeni.
• Hiçbir şey bozuk değil, yine de çalışmıyor.wp-cron.phpnormal yanıt veriyor; sitenize tetiklemeye yetecek kadar ziyaret gelmemiş.
• DISABLE_WP_CRONtanımlı, arkasında bir şey yok.Biri sistem cron işi kuracağı için yerleşik zamanlayıcıyı kapatmış; cron işi ya hiç kurulmamış ya da sonradan durmuş.

Yedekleme Yöneticisi kuruluysa ve bir zamanlama etkinse bu dördüncü neden yedeklerinizi durdurmaz.Modül, kendi işinin vakti geçti mi diye bakar ve geçtiyse wp-cron.phpdosyasını sizin yerinize kendisi çağırır, en fazla beş dakikada bir. Yani sabit tek başına sizi yedeksiz bırakmaz.

Diğer üç nedeni bu çözmez; sessiz kalan sitenizi de kurtarmaz: o çağrı bir sayfa sunulurken yapılır, kimse uğramazsa hiçbir şey tetiklenmez. wp-cron.php401 ya da 403 yanıtlıyorsa da modülün çağrısı WordPress’inkiyle aynı kapıya çarpar.

Araçlar → Site sağlığıaltında, Yedekleme Yöneticisi’nin Zamanlanmış görevlertesti dördünü de birbirinden ayırır ve size hangisinin geçerli olduğunu söyler. Ayrıca siz işi çözerken önemli olanı da söyler: “Kendi başlattığınız yedeklemeler bundan etkilenmez.”Hiç tetiklenmeyen bir zamanlama, elle aldığınız yedekleri bozmaz.

Çözüm gerçek bir cron işidir.Sunucunuza on beş dakikada bir çalışacak şekilde ekleyin:

*/15 * * * * cd /wordpress/yolu && /php/yolu -q wp-cron.php >/dev/null 2>&1

Ardından wp-config.phpdosyasında WordPress’e ziyaretlerde denemeyi bırakmasını söyleyin:

define('DISABLE_WP_CRON', true);

Sıra önemlidir. Sabiti ancak cron işi çalışmaya başladıktan sonra tanımlayın; yoksa ziyarete dayalı zamanlayıcıyı kapatır ve yerine hiçbir şey koymamış olursunuz.

Bu satırın nereye gideceği panelinize bağlı. Natro ya da Turhost gibi bir sağlayıcıdaysanız karşınıza çıkacak iki panelden biri olur.

cPanel: Gelişmiş → Cron İşleri.Ortak Ayarlaraltındaki Komutalanına satırın tamamını yapıştırın, zamanlama ve komut birlikte, sonra Yeni Cron İşi Ekledeyin. Eklendiğini Geçerli Cron İşlerilistesinde görürsünüz.

Plesk: Websites & Domains → Scheduled Tasks → Add Task.Plesk ikisini ayırır: zamanlamanın kendi alanı vardır (Cron style, beş cron alanı), oraya yalnızca komutu yazın. Run a commandseçin. Bu ekran Türkçe bir kurulumda bile çoğunlukla İngilizce kalır; panelin geri kalanı Türkçeyken Scheduled Tasks, Add Taskve Run a commandyazılarını ararsınız. Fetch a URLile kendi wp-cron.phpadresinizi göstermek PHP yolunu aramaktan kurtarır ama HTTP üzerinden gider ve yukarıdaki ilk nedenin tam o reddine çarpar.

Hata kodunu okumak

İşiniz gerçekten durduğunda bir kodla durur. Kodlar sabit metinlerdir: bir yıl sonra bir günlükte bulacağınız kod, bugünkü anlamını korur.

Bunlardan ikisi başarısızlık değildir. E2000sayfanızın ipin ucunu kaçırmasıdır, E4000ise sizsiniz. Geri kalanlar nereye bakacağınızı söyler; kodların işi zaten budur.

Hangi aşama neyi tüketir?

Yedeğiniz tek bir işlem değildir. Dört işlemdir ve her biri başka bir kaynakta tükenir.

Aşamayı bildiğinizde, siz hiçbir şeyi değiştirmeden önce neden bu tablonun tek bir sütununa iner. Veritabanı aşamasında biten bir çalışma disk sorunu değildir ve iş yükleme sırasında durduysa memory_limitartırmak size yardım etmez.

Aşamanız veritabanıysa ve siteniz büyükse, cevap genelde sınır değil tek bir tablodur — önce WordPress veritabanı neden büyüryazısına bakın. Sorun diskse paket boyutundan başlayın: disk dolduğu için tamamlanmayan yedek.

İzleri kaybetmeden iptal etmek

İptal etmek çoğu zaman doğrudur. Önce iptal edip sonra bakmak değil: ilk başarısızlığınız bilgi verendir ve ikinci çalışma, ona yol açan koşulların üzerine yazar.

İlerleme penceresi not almaya değer iki şey gösterir ve pencereyi kapattığınızda kaybolan da tam olarak o ikisidir:

1. durduğu aşama;
2. ulaştığı geçen süre.

Saati de not edin — pencere saat göstermiyor, kendi saatinize bakın — ki sonra sunucu günlüklerinde eşleşen satırları bulabilesiniz.

Orada bulmayı bekleyeceğiniz üç bilgi ise hiç görünmüyor: yedek kimliğiniz, işlenen miktar ve yarım paketinizin boyutu. Pencerede bir aşama ile bir sayaç var, o kadar; bu yüzden oradan kimlik kopyalamayı planlamayın.

Sonra iptal edin ve geçici dosyalara dokunmayın. Hâlâ bir çalıştırıcıya ait olan yarım paketi silmeniz güvenli değildir: bu, yavaş bir işi başarısız bir işe çevirir ve aynı anda izlerinizi de yok eder. Saklama politikası eski paketleri kendiliğinden temizler.

Tek bir tekrar ve öncesinde değiştireceğiniz şey

Bir değişiklikten sonra tek bir tekrar. Umut ederek üç tekrar değil.

Önce yer açın.Boş disk alanınızı son başarılı paketinizin boyutuyla karşılaştırın. Siteniz çalışmayı sürdürürken yedeğinizin yeni paket için yere ihtiyacı var.

Sonra işi daraltın.Önce Yalnızca Veritabanı, ardından Yalnızca Dosyalaryedeği alın. Hangisi başarısız olursa sorun o yarıdadır ve her yarı, tam yedeğinizin bitiremediği yerde bitecek kadar küçüktür. Ayrıntılar veritabanı yedeğive dosya yedeğirehberlerinde.

Yedeklemeniz gerekmeyeni hariç tutun.wp-contentiçindeki eski arşivler klasik örnektir: yedeğiniz geçen ayın yedeklerini de alır ve her çalışmada büyüyerek bir noktada bitemez hale gelir. Önbellek dizinlerini ve üretilmiş medya klasörlerini de genelde dışarıda bırakabilirsiniz.

Tek bir sınırı değiştirin, hepsini değil.Kodunuz E5000ya da E5001ise memory_limitveya max_execution_timedeğerini artırın — birini, bir kademe — ve yeniden çalıştırın. Hepsini birden artırmak hangi sınırın belirleyici olduğunu gizler ve sunucunuzu boşuna yorar. İkisini ayrı ayrı bellek limitini güvenle artırmave maksimum çalışma süresi aşıldıanlatıyor.

Son doğrulanmış geri dönüş noktanızı koruyun.Gerçekten geri yüklediğiniz son yedeğin yerini, yeni paketi de geri yükleyene kadar yeni pakete bırakmayın. Var olan paket, çalışan paket demek değildir.

Doğrulama

Yedeğiniz, bir mesaj yüzde 100 dediğinde değil, siz onu bir yere geri yüklediğinizde biter.

Bu dördüncü satır uygulandı ve siz denemeden önce bilmeniz gereken iki şey çıktı.

Yerel paketiniz, başarısız bir aktarımdan sağ çıkar.Uzak hedef seçiliyken paketiniz önce diskte kurulur, sonra gönderilir. Reddedilen bir oturum açma size hedefteki kopyaya mal olur, yedeğe değil. Tasarım böyle; başarısız bir yükleme, başarısız bir yedek değildir.

Mesajın ikinci yarısı İngilizce gelir, çünkü aktarım katmanından çıkar ve hata anında siteniz hangi dildeyse o dilde saklanır. Yalnızca baştaki bölüm gösterim sırasında çevrilir.

Ve iz kalmaz.Hata, kayan bir bildirim olarak görünür ve bir sonraki sayfa açılışında yoktur. Yedek listenize yazılmaz, uzak yedek listenizde de ona ait satır bulunmaz. Katalogda on bir tane olmasına rağmen bir AIOWS-BK-Ekodu da gösterilmez. Bu kontrolü yaparsanız mesajı ekrandayken okuyun; sonrasında arayüz size bunun olduğunu söylemeyecek.

Her satırının geçmesi beklenen bir doğrulama tablosu, yalnızca okuyabildiğinizi kanıtlar.

Yedeğiniz değil de geri yükleme tarafı bozuluyorsa bu ayrı bir konudur: geri yükleme takılıyor veya başarısız oluyor. Hiç geri yükleme denemediyseniz başlangıç noktanız şu: WordPress yedeğini doğrulama.

AIOWS nasıl yardımcı olur?

AIOWS Yedekleme Yöneticisi

Yedekleme Yöneticisi yedeğinizi alır — ve bu yazı açısından daha yararlısı, yukarıdaki üç durumdan hangisinde olduğunuzu size söyler.

Aşamayı ve kodu adıyla söyler.İlerleme penceresi aşamayı ve geçen süreyi gösterir: iptalden önce önemli olan iki bilgi ve pencereyle birlikte kaybolan iki bilgi. İşiniz durduğunda, genel bir hata mesajıyla değil, yukarıdaki tablodaki on bir sabit AIOWS-BK-Ekodundan biriyle durur.

Zamanlayıcıya güvenmek yerine onu denetler.Yedekleme Yöneticisi, WordPress Araçlar → Site sağlığıiçine Zamanlanmış görevlertesti ekler. Test, yukarıdaki dört nedeni birbirinden ayırır ve sizinkini söyler; sonra kurulumunuza göre, doğruladığı PHP dosyasıyla bir cron satırı yazar. Dosyayı doğrulayamıyorsa bunu açıkça söyler ve yer tutucu bırakır; size gece üçte sessizce başarısız olacak bir komut vermez.

Dördüncü nedeni yalnızca bildirmekle kalmaz, onu karşılar.Zamanlama etkinse, kendi işinin vakti geçtiğinde wp-cron.phpdosyasını kendisi çağırır; böylece arkasında cron işi olmayan bir sabit yedeklerinizi sessizce durdurmaz.

İşi sizin için daraltır.Tam yedek, Yalnızca Veritabanıve Yalnızca Dosyalartek bir açılır listedir. Hariç tutulacak yollarınız tek bir kutudur, satır başına bir yol. Yerel, Google Drive, OneDrive ve FTP/SFTP, zamanlamanızı yeniden kurmadan ekleyip çıkarabileceğiniz hedeflerdir; saklama süresini yerel ve bulut kopyalar için ayrı ayrı belirlersiniz.

Bir geri yüklemenin gerçekte ne yaptığını gösterir.Geri Yükleme Merkeziher geri yükleme için bir makbuz ve sonradan okuyabileceğiniz bir rapor tutar. “Geri yüklendi” böylece sizin hatırlamanız değil, bir kayıt olur.

Sınırları, açıkça. Modül ne hostinginizin PHP sınırlarını ne de disk kotanızı yükseltebilir. Zamanlayıcıya yaptığı çağrı bir sayfa sunulurken çıkar; bu yüzden kimsenin uğramadığı bir sitede tetikleyemez, orada yalnızca olanın bu olduğunu söyler ve size cron satırını verir. Paylaşımlı bir hostingin uzun süren bir çalıştırıcıyı sonlandırmasını da engelleyemez. Bu üçü hosting sağlayıcınıza aittir.

AIOWS Yedekleme Yöneticisi’ni inceleyinAIOWS planlarını karşılaştırın

Sık sorulanlar

Çubuk on dakikadır kıpırdamıyor. Yedek öldü mü?Şart değil. Pencereyi kapatın ve yedek listenize bakın. Paketiniz oradaysa iş bitmiştir. Orada değilse, iptal etmeden önce diskteki dosyanın hâlâ büyüyüp büyümediğine bakın.

Yedek alınırken sekmeyi kapatabilir miyim?Evet. Çalıştırıcı tarayıcınızda değil sunucunuzda koşar. Sekmeyi kapatmak yedeğinizi değil, ilerleme çubuğunuzu durdurur.

Zamanlanmış yedeğim neden hiç çalışmadı?Büyük olasılıkla zamanlanan saat civarında sitenizi kimse ziyaret etmedi; çünkü WordPress’in yerleşik zamanlayıcısı saate göre değil ziyarete göre çalışır. Zamanlanmış görevlertesti, dört nedenden hangisinin sizde geçerli olduğunu söyler.

Başarısız bir yedekten kalan dosyaları silmem güvenli mi?Yalnızca hiçbir çalıştırıcı onlara sahip değilse. Hâlâ çalışan bir iş olabilirse dokunmayın — saklama politikası eski paketlerinizi kendiliğinden temizler.

Yedek tamamlandı ama dosya çok büyük. Bu bir hata mı?Hayır, ama genelde bir şeyi iki kez yedeklediğiniz anlamına gelir ve wp-contentiçindeki eski arşivler en sık görülen durumdur. Onları hariç tutup yeniden çalıştırın.

Kaynaklar

• WP-Cron — WordPress Developer Resources
• WP-Cron’u sistem görev zamanlayıcısına bağlamak
• WordPress dosyalarını yedeklemek — WordPress Dokümantasyonu
• PHP çalışma zamanı yapılandırması: memory_limitve max_execution_time