Güncellemelerin çoğu sorunsuz biter, ama bozulduğunda dönüş yolunuz yalnızca yedeğinizin kalitesi kadardır. Bir eklenti güncellemesi veritabanı şemasını değiştirdiyse dosyaları eski sürüme çekmek tek başına yetmez, veritabanını da önceki hâline döndürmeniz gerekir. Bu rehber, wordpress güncelleme öncesi yedeğin neyi içermesi gerektiğini, hızlı yedek yollarını, doğrulamayı ve güncellemeyi yedekle birleştiren güvenli akışı anlatıyor. Güncellemenin kendisi için WordPress güncelleme rehberine göz atın.
Güncellemeden önce neden yedek almalıyım?
Güncelleme dosyaları değiştirir ve bazen veritabanı tablolarını da dönüştürür. Bir eklenti ya da tema yeni sürümde PHP veya WordPress sürümünüzle uyumsuz çıkabilir, başka bir eklentiyle çakışabilir ya da yarıda kesilebilir. Bu durumlarda sitenin beyaz ekran vermesi ya da kritik hata göstermesi mümkündür. Yedek, bu riskin sigortasıdır ve sigorta ancak güncellemeden önce alınırsa işe yarar.
WordPress’in yerleşik geri alma mekanizmaları sınırlıdır ve veritabanı değişikliklerini kapsamaz. Bu nedenle kendi yedeğiniz asıl güvencedir.
Güncelleme öncesi neyi yedeklemeliyim?
İki parçayı da yedekleyin: dosyaları ve veritabanını. Yalnızca birini alan bir yedek, geri yükleme anında yarım kalır.
| Parça | İçerik | Neden gerekli |
|---|---|---|
| Veritabanı | Yazılar, sayfalar, kullanıcılar, ayarlar, sipariş verileri | Güncelleme tabloları değiştirebilir, dosya yedeği bunu geri almaz |
| wp-content klasörü | Eklentiler, temalar, yüklenen görseller ve dosyalar | Güncellenen eklenti ve temaların eski sürümü burada durur |
| wp-config.php | Veritabanı bağlantısı, güvenlik anahtarları, özel sabitler | Kaybolursa siteyi yeniden bağlamak zorlaşır |
| .htaccess ve çekirdek dosyalar | Yönlendirme ve sunucu kuralları, WordPress çekirdeği | Çekirdek güncellemesinde önemli, özel kurallarınız varsa değerli |
Büyük bir mağazanız varsa yükleme klasörü çok yer kaplar. Kısa vadede yalnızca veritabanını ve değişen eklenti klasörlerini yedeklemek hızlı bir seçenek olabilir, ancak tam yedeği düzenli aralıklarla da almaya devam edin.
Güncellemeden önce hızlı yedek nasıl alınır?
Birkaç dakikalık bir iş için üç pratik yol vardır. Hangisini seçeceğiniz, sunucu erişiminize bağlıdır.
WP-CLI ile veritabanı yedeği
SSH erişiminiz varsa veritabanını tek komutla dışa aktarabilirsiniz. wp db export, bağlantı bilgilerini wp-config.php dosyasından kullanır:
wp db export guncelleme-oncesi-$(date +%Y%m%d-%H%M).sqlDosyalar için wp-content klasörünü sıkıştırabilirsiniz:
tar -czf wp-content-$(date +%Y%m%d-%H%M).tar.gz wp-contentYedekleme eklentisi ya da hosting paneli
Eklenti kullanıyorsanız güncellemeden önce elle bir yedek başlatın, planlı yedeğin saatini beklemeyin. Hosting panelinizde anlık yedek alma seçeneği varsa onu da kullanabilirsiniz, ama panel yedeğinin içeriğine (veritabanı dahil mi) bakın.
Merkezi panel
Birden fazla siteniz varsa her birinde elle yedek almak zaman kaybıdır. Panelden toplu yedek ya da güncellemeyle birleşik yedek tek adımda yapılabilir. Aşağıda bunu nasıl yaptığımızı anlatıyoruz.
Yedek alırken en sık yapılan hatalar nelerdir?
Yedek aldığını sanıp aslında korumasız kalmak, bu konunun en yaygın tuzağıdır. Aşağıdaki durumlar kriz anında ortaya çıkar.
- Yedeğin yedeğini almak: wp-content altında bir yedekleme eklentisinin klasörü varsa, yeni yedek eskileri de içine alır, boyut hızla büyür ve disk dolar. Yedek klasörünü yedekten hariç tutun.
- Disk dolu olduğunda yedek almak: yarım kalmış dosya hata vermeden bırakılabilir. Yedekten önce boş disk alanına bakın.
- Yalnızca sunucuda tutmak: sunucu sorununda yedek de erişilemez olur.
- Yedek ile güncelleme arasında geçen süreyi görmezden gelmek: bir mağaza ya da üyelik sitesinde yedekten sonra gelen siparişler, yorumlar ve kayıtlar yedeğe girmez. Geri yüklerseniz bu veriler kaybolur. Bu tür sitelerde güncellemeyi düşük trafikli saatte yapın ve yedekle güncelleme arasını mümkün olduğunca kısa tutun.
- Veritabanı dökümünü yoğun yazma sırasında almak: çok yoğun bir sitede döküm sırasında yazılan veriler tutarsız kalabilir. Büyük mağazalarda bu yüzden düşük trafikte yedek almak daha güvenlidir.
- Yedeği hiç denememek: yedeğin geri yüklenebildiğini yalnızca geri yükleyerek öğrenirsiniz.
Yedekten başka güncellemeden önce neye bakmalıyım?
Yedek, bir şey ters giderse dönüş yoludur. Ters gitme olasılığını azaltmak için güncellemeden önce kısa bir ön kontrol yapın.
- Eklenti ya da temanın sürüm notlarını okuyun. Büyük sürüm atlamaları (örneğin 2.x’ten 3.x’e) genellikle uyumsuzluk riski taşır.
- Eklentinin test edildiği WordPress ve PHP sürümlerine bakın. Sitenizdeki sürümler bunun dışındaysa riski bilerek güncelleyin.
- Yedek eklentiniz ve güvenlik eklentiniz gibi kritik bileşenleri diğerlerinden ayrı güncelleyin.
- Mümkünse güncellemeyi önce bir test kopyasında deneyin. Test ortamı yoksa en düşük riskli parçadan başlayın.
- Güncellemeyi, sorunu ilk elden izleyebileceğiniz bir zamanda yapın. Cuma akşamı ya da tatile çıkmadan hemen önce yapmak sorunun fark edilmesini geciktirir.
Kısa bir kontrol bile çoğu zaman yedeğe hiç ihtiyaç duyulmamasını sağlar, ama yedeğin ne zaman gerekeceğini önceden bilemezsiniz. Bu yüzden iki adımı birlikte uygulayın.
Yedeğin çalıştığını nasıl doğrularım?
Dosya var diye yedek var demek değildir. Boş ya da yarım kalmış bir veritabanı dökümü, kriz anında en kötü sürprizdir. En azından şunları kontrol edin:
- Dosya boyutları mantıklı mı? Önceki yedeklerle karşılaştırın, belirgin biçimde küçükse bir sorun vardır.
- SQL dosyası sonuna kadar yazılmış mı? Dosyanın son satırlarına bakın, yarıda kesilmiş bir döküm genellikle tamamlanma yorumuyla bitmez.
- Arşiv açılıyor mu? Sıkıştırılmış dosyayı bir klasöre çıkarıp wp-content içeriğini görün.
- Mümkünse bir test alt alan adına ya da yerel ortama gerçekten geri yükleyin. Adımlar aşağıdaki paragrafta.
WordPress yedek geri yükleme rehberi, bu denemeyi komut komut anlatıyor. Büyük bir güncelleme öncesi bu denemeyi yapmak 15 dakikanızı alır ve en sinsi sorunu, yani geri yüklenemeyen yedeği önceden ortaya çıkarır.
Yedeği nerede ve ne kadar süre saklamalıyım?
Yaygın olarak kullanılan 3-2-1 ilkesi şöyledir: verinin üç kopyası olsun, bunlar iki farklı ortamda dursun ve en az biri farklı bir konumda (sunucu dışında) bulunsun. Sunucudaki yedek, sunucu bozulursa ya da hesap askıya alınırsa onunla birlikte gider.
- Sunucuda bir kopya: hızlı geri dönüş için.
- Sunucu dışında bir kopya: bulut depolama, başka bir hosting ya da nesne depolama (S3 uyumlu servisler gibi).
- Bilgisayarınızda ya da ayrı bir diskte üçüncü kopya, önemli dönüm noktaları için.
Saklama süresi için tek doğru yoktur, bu bir tercih meselesidir. Pratik bir başlangıç: son birkaç günün her güncelleme öncesi yedeğini, son birkaç haftanın haftalık yedeklerini ve bir önceki ayın bir yedeğini tutmak. Bir hata hemen fark edilmezse (örneğin bir saldırı günler sonra anlaşılırsa) çok yeni olmayan bir yedeğe ihtiyaç duyabilirsiniz. Yedekleri sonsuza kadar da biriktirmeyin, depolama maliyeti büyür.
Güncelleme öncesi yedeğin tamamını WP-CLI ile alma
SSH erişiminiz olan tek bir site için tüm akışı birkaç satırda toplayabilirsiniz. Önce bakım modunu açın, yedeği alın, güncellemeyi yapın ve bakım modunu kapatın. Aşağıdaki örnek yalnızca eklentileri günceller ve bir şey ters giderse yedek dosyalarının hazır olmasını sağlar:
wp maintenance-mode activate
wp db export guncelleme-oncesi.sql
tar -czf wp-content-oncesi.tar.gz wp-content
wp plugin update --all
wp maintenance-mode deactivateKomutları sırayla ve hata kontrolüyle çalıştırın. Yedek komutlarından biri başarısız olursa güncellemeye geçmeyin. Üretim sitesinde wp plugin update --all yerine tek tek eklenti adı vermek, sorun çıktığında suçluyu bulmayı kolaylaştırır.
Mağaza ve üyelik siteleri için ek önlemler
Sipariş alan ya da kullanıcı kaydı tutan bir sitede veritabanı sürekli değişir. Yedekten sonra gelen her sipariş, geri yüklemede kaybolma riski taşır. Bu tür sitelerde güncellemeyi bakım penceresinde yapın, güncelleme süresince siteyi bakım moduna alın ve yedekle güncelleme arasındaki boşluğu kısaltın. Geri yükleme gerekirse, yedek sonrası gelen siparişleri sunucu günlüklerinden ya da ödeme sağlayıcınızın panelinden elle eşleştirmeniz gerekebilir. Bu yüzden ödeme sağlayıcısının kendi kayıtlarını da bir referans olarak saklayın.
Geri dönüş planınızı önceden yazın
Güncelleme bozulduğunda karar vermek en zor andır. Önceden kısa bir plan yazın: hangi belirti hangi geri dönüşü tetikler? Örneğin ana sayfa açılmıyorsa ilgili eklentiyi dosya sisteminden devre dışı bırakın, bu yetmiyorsa son yedeği geri yükleyin. Planda yedeğin nerede durduğunu, geri yüklemeyi kimin yapacağını ve sitenin ne kadar süre kapalı kalabileceğini yazın. Bu plan, ekip içinde ya da müşteriye karşı sorumluluk taşıyorsanız ayrıca değerlidir.
Güncelleme sonrası yedekle ne yapmalıyım?
Güncelleme başarılı olduysa güncelleme öncesi yedeği hemen silmeyin. Bazı sorunlar (bir form bozulması, yavaşlama, bir eklentinin ayarlarını sıfırlaması) ancak birkaç gün sonra fark edilir. Bir hafta kadar bekleyin, sonra saklama düzeninize göre eskiyen yedekleri temizleyin.
Yedeğin kendisini nasıl korumalıyım?
Bir yedek, sitenizin tüm içeriğini ve wp-config.php içindeki veritabanı şifresini taşır. Yedek dosyalarını herkese açık bir klasörde bırakmayın, tahmin edilebilir bir adresten indirilebilir hâlde tutmayın. Sunucu dışındaki depolamada erişimi sınırlayın, mümkünse iki aşamalı doğrulama kullanın ve yedeği şifreleyin. Müşteri ya da üye verisi içeren siteler için bu, hem güvenlik hem de veri koruma açısından önemlidir.
Yedeğin yaşını nasıl izlerim?
‘Yedek var’ bilgisi yeterli değildir, yedeğin ne kadar yeni olduğu da önemlidir. Son başarılı yedeğin tarihini düzenli görün. Günlerdir yeni yedek alınmıyorsa bu, güncelleme yapmadan önce çözülmesi gereken bir sorundur.
Yedek ve güncellemeyi tek akışta nasıl yaparım?
Güvenli bir güncelleme akışı, yedeği güncellemeyle aynı sürecin bir adımı hâline getirir. Elle yapacaksanız sırası şudur:
- 1Güncellenecek eklenti, tema ve çekirdek sürümlerinin listesini ve sürüm notlarını okuyun.
- 2Tam yedek alın (dosyalar ve veritabanı), sunucu dışına da kopyalayın.
- 3Yedeğin boyutuna ve içeriğine hızlıca bakın.
- 4Önce bir ya da iki parçayı güncelleyin, hepsini birden değil. Sorun çıkarsa neyin yol açtığını bilirsiniz.
- 5Ana sayfayı, giriş ekranını ve kritik akışları (ödeme, form) kontrol edin.
- 6Sorun varsa yalnızca ilgili parçanın önceki sürümüne dönün, olmazsa yedeği geri yükleyin.
.maintenance dosyasını silmek siteyi yeniden açar. Ardından güncellemeyi yeniden deneyin ya da yedeğe dönün. Güncelleme sonrası site bozulmuşsa güncelleme sonrası site bozuldu yazısındaki adımları izleyin.Sık sorulan sorular
Her küçük eklenti güncellemesinden önce yedek şart mı?
Her güncelleme için ayrı tam yedek şart değildir, ama güncellemeden önce yakın zamanda alınmış sağlam bir yedeğiniz olmalı. Sık güncellenen sitelerde günlük otomatik yedek, ek olarak büyük güncelleme öncesinde elle yedek makul bir dengedir.
Sadece veritabanını yedeklemek yeterli mi?
Hayır. Veritabanı içeriği korur, ama eklenti ve tema dosyaları ve yüklenen görseller dosya sistemindedir. Her ikisini de yedekleyin.
Yedek eklentisi kendisi güncellenirken risk var mı?
Var, çünkü yedeği alan araç bozulursa yedek de alınamaz. Yedekleme eklentisini diğer güncellemelerden ayrı ve onlardan önce güncelleyin, ardından yedeğin hâlâ alınabildiğini bir deneme yedeğiyle doğrulayın.
Otomatik güncellemeler açıksa ne yapmalıyım?
WordPress otomatik güncellemeleri bir yedek almadan çalışır. Otomatik güncelleme açıksa günlük yedeğin gerçekten çalıştığını düzenli kontrol edin. Otomatik güncellemeyi kapatmayı düşünüyorsanız otomatik güncellemeyi kapatma yazısına bakın.
Güncelleme öncesi alınan yedekler ne kadar süre kalmalı?
Güncelleme sorunsuz geçtiyse birkaç gün ile birkaç hafta arası yeterlidir. Sorun geç ortaya çıkabileceği için ilk güncellemeden sonra en az bir hafta eski yedeği silmeyin.
Güncellemeden önce yedek otomatik alınsın
Watch Your WP’deki Güvenli güncelle, güncellemeyi uygulamadan önce yedek alır, sonra güncellemeyi uygular. Sorun çıkarsa tek tıkla sürüm geri alma dosyaları önceki sürüme çeker (veritabanına dokunmaz). Yedek sitenin kendi sunucusunda tutulur, panelden indirip başka bir yerde de saklayabilirsiniz. Ücretsizdir.

Erdinç
Watch Your WP'yi geliştiriyor. WordPress bakım, güvenlik ve site yönetimi deneyiminden yazıyor.
LinkedIn

