Önce neyi kurtarmak istediğinizi belirleyin

Kurumsal sitenin içerikleri, yüklenen görseller, formlardan gelen kayıtlar ve uygulama ayarları farklı yerlerde bulunabilir. Sadece sayfaları indirmek bütün bunları kapsamaz. Teknik ekiple bir kapsam listesi oluşturun: dosyalar, veri tabanı, gerekli yapılandırma ve dış hizmet bağlantıları. Parolaları veya erişim anahtarlarını herkese açık teslim belgesine yazmayın.

WordPress’in resmi rehberi dosyalar ile veri tabanını ayrı bileşenler olarak açıklar; tipik tam geri dönüşte ikisi birlikte gerekir. Başka bir altyapıda kapsam değişebilir. Statik sayfa yedeği ile sipariş kaydı tutan bir uygulamanın yedeğini aynı kontrol listesiyle tamamlanmış saymayın.

Kabul edilebilir veri aralığını konuşun

Son sağlam kopya dün geceye aitse bugünkü içerik değişiklikleri veya başvurular o kopyada bulunmayabilir. Yedek sıklığını alışkanlıkla seçmek yerine işletmenin hangi kayıtları kaybetmeyi kabul edemeyeceğini konuşun. Bu görüşme, her sistem için aynı süreyi garanti etmek anlamına gelmez.

Bir editör haftada iki içerik ekliyor olabilir; aynı sitedeki başvuru formu her gün kayıt topluyor olabilir. Kapsam ve sıklık bu ayrımı yansıtmalı. Prova için seçilen kümenin tarihini, içerdiği parçaları ve beklenen son kaydı not edin. Dosya adı tek başına yedeğin içinde ne olduğunu göstermez.

Prova kabul kartı

Prova ortamını canlı işlemlerden ayırın

Test kopyası canlı alan adını veya üretim veri tabanını kullanmamalı. Erişimi sınırlandırın; yalnızca arama motorlarına noindex demek erişim kontrolü değildir. Kopyadaki kişisel veriler gerçekten gerekiyorsa yetkili erişim ve saklama kapsamını belirleyin; gerekmeyen verileri test için taşımayın.

E-posta, ödeme, kurye ve webhook gibi dış etkileri başlamadan kontrol edin. Geri yüklenen eski bir zamanlanmış görev, gerçek müşteriye tekrar bildirim gönderebilir. Prova senaryosunda bu bağlantıları güvenli test karşılıklarına yönlendirmek veya devre dışı tutmak teknik sorumlunun işi olmalı. Canlı hizmeti kapatarak prova yapmayın.

Ana sayfadan fazlasını kontrol edin

Kopya açıldıktan sonra bir iç sayfa, yüklenmiş görsel, yönetim girişi ve beklenen içerik kaydını inceleyin. Sadece ana sayfanın görünmesi bütün uygulamanın kurtarıldığını kanıtlamaz. Arama, belge bağlantısı veya dosya erişimi iş için önemliyse onları da seçilmiş kabul adımlarına ekleyin.

Gerçek müşteriye ileti göndermeden formun test kaydı oluşturma yolunu sınayın. Kullanılan yedek tarihini ve provanın gerçek süresini kaydedin. Ölçtüğünüz süre yalnız o ortam ve kapsam için kanıttır; farklı bir kesintinin aynı sürede çözüleceğine dair taahhüt değildir. Eksikleri yeni yedek planına geri besleyin.

Sorumluyu ve bir sonraki provayı netleştirin

Yedeği kim alıyor, geri dönüşü kim başlatabiliyor ve iş tarafında kim sonuçları kabul ediyor? Bu üç rol aynı kişi olabilir, fakat karar açık olmalı. Altyapı veya kritik eklenti değiştiğinde eski prova kaydını güncel sistemin kanıtı gibi kullanmayın. Değişen kapsam için yeniden doğrulama planlayın.

Bakım sayfası rehberimiz kesinti sırasında ziyaretçiye verilecek bilgiyi anlatır; geri dönüş provası bunun teknik hazırlığına odaklanır. Web sitesi teslim kapsamına yedek envanteri ve doğrulanmış prova kaydı eklemek, yalnızca “yedek alınıyor” ifadesinden daha somut bir teslim sağlar.

Sık sorulan sorular

Prova için canlı siteyi geri almalı mıyız?

Hayır. Ayrı ve korunmuş bir test ortamında çalışın. Gerçek geri dönüş gerektiğinde kapsamı, veri etkisini ve sorumluları ayrıca değerlendirin.

Yedek sağlayıcının panelindeyse kontrol biter mi?

Hayır. Kapsam, erişim ve geri yükleme adımları doğrulanmalı. Sağlayıcının dosya saklaması, işletmenizin bütün kayıtlarının kurtarılabildiğini tek başına göstermez.

Kaynaklar ve ileri okuma

WordPress — Backups
Web tasarım & geliştirmeBu hizmeti konuşalım