Bir yedek dosyasının bulunması, sitenin gerektiğinde geri dönebileceği anlamına gelmez. Arşiv eksik olabilir, veritabanı başka tarihe ait olabilir veya geri yükleme yöntemi hiç denenmemiş olabilir. WordPress yedeğini değerlendirirken temel soru “Kaç dosya var?” değil, “Bu paketle siteyi bağımsız bir ortamda yeniden açabiliyor muyum?” olmalıdır. Bir kişisel blog üzerinden dosya, veritabanı ve geri yükleme ilişkisini ele alalım.

Dosyalar ile veritabanı farklı bilgi taşır

Tema, eklenti ve yüklenen görseller dosya sisteminde bulunur. Yazı içerikleri, kullanıcılar ve birçok ayar ise veritabanında saklanır. Sadece tema ZIP’ini almak bütün siteyi yedeklemek değildir. WordPress’in dışa aktarma XML’i de tam site yedeğiyle aynı kapsamda değildir; içerik taşımak için yararlı olsa da bütün dosya ve ayarların yerine geçmez.

wp-content dizini, yapılandırma dosyası ve siteye özgü sunucu ayarları önemlidir. Sistemin çekirdek dosyaları yeniden kurulabilse bile siteye özel değişiklikler ve yüklemeler ayrıca değerlendirilmelidir. Veritabanı dışa aktarımıyla dosya yedeğinin hangi tarihe ait olduğunu aynı kayıt içinde tutun.

Kapsamı işinize göre yazın

Küçük bir blog için en azından dosya yedeği, veritabanı yedeği, alınma zamanı ve kullanılan WordPress/PHP sürümü not edilebilir. Sipariş veya üyelik sistemi varsa yedek alınırken yeni kayıtların oluşması ayrıca yönetilmelidir. Dosya ile veritabanının birbiriyle uyumlu anı temsil etmesi önem kazanır.

Günlük otomatik yedek, her durumda kabul edilebilir veri kaybı aralığı değildir. Bir gün içindeki yüzlerce siparişin kaybı ile haftada bir yazı yayımlayan kişisel blogun kaybı aynı etkiyi yaratmaz. Yedek sıklığını sitenin değişim hızına ve geri dönülebilir veri miktarına göre seçin.

Yedeği aynı sunucuya mahkûm etmeyin

Sunucunun diskinde duran arşiv, sunucu veya hesap tamamen erişilemez olduğunda işe yaramayabilir. Bağımsız bir kopya bulundurun. İçinde kullanıcı verileri ve bağlantı bilgileri olabileceğinden yedeği herkese açık bir web klasörüne koymayın. Dosyanın indirilebilir adresini tahmin edilemez yapmak, erişim kontrolünün yerine geçmez.

Birden fazla geçmiş sürüm saklamak da yararlıdır. Sorun geç fark edildiğinde en yeni yedek bozulmuş durumu içeriyor olabilir. Saklama sayısını ve süresini depolama ihtiyacına göre planlayın; eski arşivleri silmeden önce bağımsız kopyaların mevcut olduğunu kontrol edin.

Geri yükleme provasını ayrı ortamda yapın

Canlı sitenin üzerine deneme yapmak yerine yerel veya ayrı test ortamı kullanın. Dosyaları açın, veritabanını içeri alın ve yapılandırma bağlantılarını test ortamına göre düzenleyin. Alan adı değişiyorsa WordPress’te URL ve serileştirilmiş veri ilişkilerini bilen araçlarla işlem yapın; veritabanının tamamına kör bir metin değişimi uygulamayın.

Test sitesinin canlı ziyaretçilere veya arama motorlarına açık olmaması gerekir. E-posta, ödeme, bildirim ve dış servis bağlantılarının yanlışlıkla gerçek işlem başlatmasını önleyin. Bu adım test yedeğinin doğruluğunu bozmaz; prova ortamının canlı operasyonla karışmasını engeller.

Kontrol yalnızca ana sayfa değildir

Bir yazıyı, kategori sayfasını, görseli ve iletişim formunu açın. Yönetim paneline girişin çalıştığını doğrulayın. Özel tema ayarlarını, kalıcı bağlantıları, site haritasını ve kullanılan önemli eklentileri kontrol edin. Ana sayfa güzel görünürken yazı adresleri 404 verebilir veya görseller eski alan adından yüklenebilir.

Son olarak geri yükleme için geçen süreyi ve karşılaşılan adımları not edin. “Yedek var” bilgisinin yanına “Ayrı ortamda açıldı, şu kontroller geçti” bilgisini eklemek çok daha değerlidir. Yedekleme düzeni bir kez kurulup unutulacak iş değildir; büyük tema, eklenti veya sunucu değişikliklerinden sonra prova tekrar gözden geçirilmelidir.

Kaynaklar: WordPress — Backups, Backing Up Files.