Yedek dosyasının oluşması, sistemin geri getirilebildiği anlamına gelmez. İyi bir plan; hangi verinin, hangi noktaya ve ne kadar sürede döndürüleceğini test ederek gösterir.
Kabul edilebilir kaybı ve süreyi belirleyin
RPO, hedeflenen en fazla veri kaybı aralığını; RTO ise hizmetin geri getirilmesi için hedeflenen süreyi anlatır. Örneğin günde bir kez yedek alınan bir yayın sitesinde son yedekten sonra girilen yazılar kaybolabilir. Sürekli sipariş alan bir uygulamada aynı aralık kabul edilemeyebilir.
Bu hedefleri yalnızca teknik ekip belirlememeli. İşletme hangi kayıtları yeniden oluşturabilir, ne kadar kesintiyle çalışabilir ve geri dönüş için hangi personel gerekir sorularını yanıtlamalıdır. “Hiç veri kaybı ve hiç kesinti” beklentisi varsa bunun yedekten daha kapsamlı replikasyon, yedeklilik ve işletim tasarımı gerektirebileceğini değerlendirin.
Yedek kapsamına neler girmeli?
- Uygulamanın kaynak veya dağıtım paketi ve sürüm bilgisi.
- Veritabanı ile kullanıcının yüklediği dosyalar.
- Sunucu ve uygulama yapılandırmaları.
- Zamanlanmış görevler, kuyruk yapılandırması ve gerekli servis listesi.
- Güvenli biçimde yönetilen şifreleme anahtarları ve kurtarma erişimi.
- DNS ve e-posta yapılandırmasının güncel kaydı.
Git deposu kaynak kod için yararlıdır fakat kullanıcı yüklemeleri ve canlı veritabanı genellikle orada bulunmaz. Sunucu anlık görüntüsü hızlı dönüş sağlayabilir, ancak aynı sağlayıcı hesabına bağımlı tek kopya olarak düşünülmemelidir. Hesap erişimi kaybolduğunda hangi kopyaya ulaşabileceğinizi ayrıca sorgulayın.
Tutarlı dosya ve veritabanı kopyası
Çalışan veritabanının veri dizinini sıradan dosya kopyasıyla almak tutarlı yedek garantisi vermez. Veritabanının desteklediği dışa aktarma veya fiziksel yedek yöntemini kullanın. Uygulamaya göre dosya yüklemesi ile veritabanı kaydı aynı işlemin parçaları olabilir; kopyaların zaman uyumu önemlidir.
Düşük değişim hızında kısa bir yazma duraklaması uygulanabilir. Yoğun sistemlerde işlem günlükleri, tutarlı anlık görüntü veya veritabanına özgü yöntemler gerekebilir. Kullanılan motor ve sürümün belgelerini izleyin. Yedek süresi, depolama yükü ve canlı performansa etkisini de ölçün.
Kopyaları ve erişimi ayırın
Yaygın bir başlangıç yaklaşımı birden fazla kopyayı farklı ortam ve konumlarda tutmaktır. Önemli olan sayıyı ezberlemekten çok ortak arıza nedenlerini azaltmaktır. Aynı disk üzerindeki iki klasör disk arızasına karşı koruma sağlamaz. Aynı yönetici hesabıyla silinebilen tüm kopyalar da hesap ele geçirilmesine karşı yeterli ayrım sunmayabilir.
Yedekleri aktarım ve saklama sırasında uygun biçimde şifreleyin. Şifre çözme anahtarına yalnızca arızalanan sunucudan erişilebiliyorsa kurtarma planı eksiktir. Değiştirilemez veya çevrimdışı kopya seçeneklerini veri önemine göre değerlendirin. Geri yükleme yetkisiyle günlük uygulama yetkisini mümkün olduğunda ayırın.
Saklama politikasını neden yazmalısınız?
Yalnızca en son yedeği tutmak, günler sonra fark edilen bir bozulmada işe yaramayabilir. Günlük, haftalık ve daha eski kopyalar için saklama aralıkları belirleyin. Bu aralıklar iş ihtiyacı, veri boyutu ve geçerli yükümlülüklere bağlıdır; her sistem için aynı takvim uygun değildir.
Silinen veya güncellenen verilerin yedeklerde ne kadar kaldığı da politika içinde açıklanmalı. Süresiz kopya biriktirmek güvenlik ve maliyet yükü yaratır. Otomatik temizleme işlemini test edin; yanlış yol veya tarih hesabının geçerli tüm kopyaları silmesini önleyecek kontroller koyun.
Geri yükleme tatbikatı
- Canlı sistemden ayrı ve erişimi kontrollü bir test ortamı açın.
- Seçilen tarihli yedeği indirin, bütünlük kontrolünü yapın ve gereken sürümleri kurun.
- Dosya, veritabanı ve yapılandırmayı belgelenmiş sırayla yükleyin.
- Gerçek müşteriye bildirim göndermeyi ve üretim servislerine yazmayı engelleyin.
- Önemli sayfalar, örnek kayıtlar, yüklenen dosyalar ve temel iş akışlarını kontrol edin.
- Geçen süreyi ve ulaşılabilen son veri zamanını kaydedin; RTO ve RPO hedefleriyle karşılaştırın.
Arşivin açılması testin yalnızca ilk adımıdır. Örneğin veritabanı yüklenmiş ama dosya izinleri nedeniyle görseller görünmüyorsa hizmet tam dönmüş değildir. Test sonucunda eksik komut, unutulmuş anahtar veya uzun indirme süresi bulursanız kurtarma belgesini güncelleyin.
İzleme ve başarısız yedekler
Yedek işinin çıkış kodu, dosya boyutu, süre ve son başarı zamanı izlenebilir. Sıfır baytlık veya beklenmedik ölçüde küçük bir arşiv, işlem “tamamlandı” görünse bile araştırılmalıdır. Birikmiş eski yedeklerin diski doldurması canlı hizmeti etkileyebilir; kapasite uyarısı da plana dahil edilmeli.
Başarısızlık bildiriminin gerçekten ulaştığını kontrollü bir testle görün. Bildirim adresi ayrılan personele aitse teknik olarak çalışan alarm pratikte etkisizdir. Her yedek işinin sahibi ve müdahale süresi belli olsun.
Olay sırasında acele üzerine yazmayın
Veri kaybı fark edildiğinde önce yeni yazmaları ve olayın yayılmasını değerlendirin. Hangi tarihli kopyanın doğru olduğunu belirlemeden canlı veritabanını eski yedekle değiştirmek yeni kayıtları da kaybettirebilir. Mevcut durumun ayrı kopyasını alıp karşılaştırma ve uzlaştırma planı hazırlayın.
Hosting değişikliği veya güvenlik olayı için aynı geri dönüş ilkeleri geçerlidir. Site taşıma rehberi geçiş sırasında oluşan yeni veriyi, Linux güvenlik rehberi erişim ve kayıt hazırlığını ele alır. Belgelenmiş ve tekrarlanmış bir tatbikat, yalnızca “yedek alıyoruz” ifadesinden daha güçlü bir işletim güvencesidir.
Kaynaklar ve ek okuma
Platform belgeleri giriş gerektirebilir; arayüz ve özellikler sürüme göre değişebilir. Örnekler, ayrıca belirtilmedikçe temsili senaryolardır.
Bir düzeltme öneriniz mi var? Sayfa bağlantısıyla bildirin. · Kaynak ve yayın yaklaşımı