Barındırma teklifini kapasite, sorumluluk, yedek kapsamı ve kurtarma konusunda açık bir anlaşmaya dönüştürün; geri yüklemeyi uygulamalı kontrol edin.
Barındırma seçimini, sitenizin çalışır durumda tutması gereken işlere göre yapın. Ayda bir güncellenen tanıtım sitesiyle her saat sipariş alan mağazanın ihtiyaçları farklıdır. Depolama ve fiyat karşılaştırmadan önce temel işlevleri, değişen verileri ve sorumlu kişileri yazın. Barındırma seçeneklerini bu listeyle değerlendirin; böylece teklifler aynı ihtiyacı kapsar.
İş ihtiyacını cevaplanabilir sorulara dönüştürün
Her gün fotoğraf ekleyen ve müşterilerden bilgi talepleri alan hayali bir emlak ofisini düşünün. İletişim formu çalışmazken ana sayfa görünmeye devam edebilir. Hangi işlemleri kontrol edeceğinizi, uyarıyı kimin alacağını ve düzelmeyi nasıl doğrulayacağınızı belirleyin. Yeni hizmet eklendiğinde kolayca güncellenebilen küçük bir envanter hazırlayın.
- Paket; uygulama dosyalarını, veritabanını, yüklenen görselleri ve e-postayı kapsıyor mu?
- Depolama ve trafik sınırları neler, aşıldıklarında hangi işlem veya ücret uygulanıyor?
- Uygulamayı ve sunucuyu kim güncelliyor; sertifika ile alan adı bitişlerini kim takip ediyor?
- Ayrı bir deneme ortamı mevcut mu ve maliyeti teklife dahil mi?
- Başka sağlayıcıya geçerken dosyalar ve veriler hangi yöntemle dışa aktarılabiliyor?
Alan adı hesabını, yenileme tarihini ve bağlantı yetkilerini barındırmayla birlikte planlamak için teslim notlarınıza alan adı seçimi rehberini ekleyin.
Kabul edilebilir veri kaybını ve kesintiyi belirleyin
İki iş sorusu sorun: ne kadar veriyi yeniden girebiliriz ve hizmetin dönmesi için ne kadar bekleyebiliriz? Örneğin iki saatlik talep kaybını kabul etmek ve dört saatte geri dönmeyi hedeflemek bir planlama kararıdır. Bu hedefler tasarım ve test gerektirir; maliyeti artırabilir. Teklife yazılmaları, kendiliğinden garanti oldukları anlamına gelmez.
Günlük yedek, seyrek değişen içerik için uygun olabilir. Ancak gün boyunca gelen taleplerde tek başına iki saatlik veri kaybı hedefini karşılamaz. Her veri türünün değişim sıklığını, kopyalama yöntemini ve eski sürümlerin saklanma süresini yazın. Kaynak kodunun kopyası, veritabanı kayıtlarını veya sonradan yüklenen dosyaları içermez.
Yedeğin kapsamını somutlaştırın
OWASP veritabanı güvenliği rehberi, düzenli yedeklemeyi, erişim korumasını ve mümkünse şifrelemeyi önerir. Kapsamı, saklama yerini ve kopyaları silmeye yetkili kişileri yazılı isteyin. Ana barındırma hesabına erişilemediğinde kurtarmanın nasıl yapılacağını da değerlendirin.
| Konu | Alınması gereken cevap |
|---|---|
| Kapsam | Dahil edilen ve dışarıda kalan veritabanları ile dosyalar |
| Takvim | Yedek sıklığı, saklama süresi ve başarısızlık uyarıları |
| Erişim | Kopyaları okuyabilen, yükleyebilen ve silebilen kişiler |
| Maliyet | Depolama, indirme ve destekli kurtarma ücretleri |
Sınırlı bir geri yükleme denemesi yapın
- Tarihi bilinen bir kopyayı seçin ve işlemi yapacak yetkili kişiyi belirleyin.
- Müşteri mesajları, ödemeler ve dış sistem görevleri kapalı olan yalıtılmış bir ortama geri yükleyin.
- Örnek sayfaları, görselleri ve kayıtları beklenen yedek tarihiyle karşılaştırın.
- Temel işlevleri test verileriyle deneyin; süreyi, eksik dosyaları ve sorunları kaydedin.
- Çalışan sitenin üzerine yazmadan eksikleri giderin ve sonraki denemenin tarihini belirleyin.
Yedekleme görevinin başarıyla bitmesi, geri yüklemenin de başarılı olduğunu göstermez. Deneme sonucunu ve sorumlu isimlerini site bakım planında saklayın. İletişim ve depolamayı da ayırın: Cloudflare, TLS'nin bağlantıları koruduğunu açıklar. HTTPS tek başına depolanan veritabanının veya yedek dosyalarının şifrelendiğini göstermez.
Barmijly'de mevcut barındırma hazırlığı elle yürütülür; koordinasyon ve etkinleştirme teyidi gerekir. Paketi, sorumlulukları ve gerçek yedekleme düzenini kullanmadan önce iletişim üzerinden netleştirin. Geri yükleme sonuçlarını, kontrol edilen işleri ve kapsam dışında kalanları yayına alma listenize ekleyin.