Yedek dosyası açılıyor, veritabanı içe aktarılıyor ve ana sayfa görüntüleniyor. Buna rağmen ürün fotoğrafları yok, yönetici giriş yapamıyor ve sipariş bildirimleri çalışmıyor. Geri yükleme, arşivin bozulmadan saklanmasından daha geniş bir problemdir.
Web sitesi yedekleme planının asıl çıktısı bir klasör dolusu kopya değil, gerektiğinde çalıştırılabilen bir kurtarma sürecidir. Hangi verinin korunacağını, ne kadar kaybın kabul edilebileceğini ve sistemi kimin yeniden açacağını birlikte belirlemek gerekir.
Bu yazı, varsayımsal bir sipariş sitesi üzerinden uygulanabilir bir plan önerir. Verilen süreler yalnızca hesaplama örneğidir; belirli bir altyapının performans taahhüdü veya WebWizz müşteri sonucu değildir.
Kabul edilebilir kaybı ve kesintiyi ayrı tanımlayın
RPO, kurtarma sonrasında kabul edilebilir veri kaybını zaman açısından ifade eden hedeftir. RTO ise hizmetin kabul edilebilir süre içinde geri döndürülmesi hedefidir. Birinin küçük olması diğerinin de küçük olduğu anlamına gelmez. AWS'nin kurtarma planlama rehberi bu hedeflerin iş gereksinimleriyle belirlenmesini ele alır. AWS: Disaster Recovery Planning.
Örnek işletmenin en fazla bir saatlik sipariş verisi kaybını kabul ettiğini varsayalım. Günde bir kez alınan yedek bu hedefi tek başına karşılayamaz. Ancak saatlik yedek takvimi yazmak da yeterli değildir; başarısız kopyalar ve doğrulanmamış aktarım nedeniyle son kullanılabilir kurtarma noktası daha eski kalabilir.
Başka bir varsayımda kesinti hedefi dört saat olabilir. Bu sürenin içine yetkili kişiye ulaşma, temiz ortam hazırlama, yedeği indirme, geri yükleme, doğrulama ve trafiği açma adımlarını da koyun. Yalnızca arşivi açma süresini ölçmek yanıltıcıdır.
Hedefi iş sahibiyle örnek kayıtlar üzerinden konuşun
“Bir saatlik veri kaybı” soyut gelebilir. Bunun kaç siparişin yeniden girilmesi, hangi başvuruların kaybolması veya hangi işlemlerin karşılaştırılması anlamına gelebileceğini işletmenin kendi kayıtlarıyla değerlendirin. Sayıları ölçmeden tahminleri kesin maliyet gibi sunmayın.
İçerik sitesiyle sık işlem alan bir sipariş sisteminin aynı takvime ihtiyaç duymaması normaldir. Hedefleri hizmet bazında yazmak, bütün veriye en pahalı korumayı uygulamakla kritik veriyi eksik korumak arasındaki tercihi görünür kılar.
Geri yükleme için gerekenleri envantere alın
Uygulama deposunun bulunması, sitenin bütün durumunun korunduğu anlamına gelmez. Kullanıcının yüklediği fotoğraflar, veritabanı kayıtları ve yapılandırma birbirinden farklı yerlerde yaşayabilir.
Örnek envanterde şu başlıkları ayrı takip edin:
- Veritabanları, roller ve uygulamanın ihtiyaç duyduğu uzantılar.
- Kullanıcı yüklemeleri, belgeler ve bunların erişim izinleri.
- Uygulama sürümü, bağımlılık tanımları ve veritabanı şeması.
- Güvenli saklanan yapılandırma ve şifre çözme anahtarları.
- Zamanlanmış işler, iş kuyrukları ve dış servis bağlantıları.
- Alan adı, DNS ve sertifika yönetimine erişim prosedürü.
Her kalem için sahibi, saklandığı yer ve geri yükleme sırasını kaydedin. Gizli bilgileri bu envanterin içine düz metin olarak yapıştırmayın; yetkili kişinin güvenli kaynağa nasıl erişeceğini tarif edin.
Şifrelenmiş bir yedeğin anahtarı yalnızca kaybedilen sunucuda bulunuyorsa kopya pratikte kullanılamayabilir. Anahtar kurtarma yöntemini ayrı planlayın ve erişimi görev gereği yetkili kişilerle sınırlayın.
Dosya ile veritabanının tutarlı olmasını sağlayın
Siparişe bağlı belgenin veritabanı kaydı korunup dosyasının eksik kalması, tek tek başarılı görünen iki yedeğin birlikte sorunlu olabileceğini gösterir. Uygulamanın veri yazma biçimine uygun tutarlılık yaklaşımı seçilmelidir.
PostgreSQL'de pg_dump, işlem sürerken tek veritabanı için tutarlı bir görünüm alabilir. Ancak roller gibi küresel nesneler ve uygulamanın dosya deposu bu çıktının otomatik parçası değildir. Farklı veritabanlarına alınan ayrı dökümleri de tek ortak zaman noktası gibi varsaymayın. PostgreSQL: SQL Dump.
Daha sık kurtarma noktaları gereken yapılarda temel yedekle birlikte WAL arşivleme ve belirli zamana dönüş değerlendirilebilir. Bunun çalışması gereken kayıt zincirinin korunmasına bağlıdır; yalnızca bir temel yedeği saklamak aynı kabiliyeti sağlamaz. PostgreSQL: Continuous Archiving.
Buradaki amaç her siteye aynı veritabanı yöntemini dayatmak değildir. Kullandığınız sistemin resmî yedekleme mekanizmasını seçin, dosyalarla ilişkisini belgeleyin ve birlikte geri yükleyerek sınayın.
Kopyanın bağımsızlığını da değerlendirin
Canlı siteyle yedeklerin aynı yönetici hesabına, aynı diske ve aynı silme yetkisine bağlı olması ortak arıza riski doğurur. Bir hesabın yanlış kullanılması veya ele geçirilmesi her iki tarafı da etkileyebilir.
Planı oluştururken farklı depolama konumu, ayrı erişim yetkileri ve desteklenen yerde değiştirilemeyen kopyalar gibi korumaları değerlendirin. Bu önerileri tek bir düğme veya ürün adı olarak değil, hangi olaydan korunmak istediğiniz üzerinden ele alın.
Örneğin site yöneticisi içerik silebilsin fakat yedek saklama politikasını değiştiremesin. Kurtarma yetkilisinin erişimi ayrıca sınanabilsin. Bir sağlayıcıya erişilemediğinde gerekli hesap ve iletişim bilgilerinin yalnızca o sağlayıcının sisteminde kalmaması da operasyon planının parçasıdır.
İzole ortamda geri yükleme tatbikatı yapın
Kurtarma denemesini doğrudan canlı sistemin üzerine yapmayın. Gerçek müşterilere e-posta, ödeme isteği veya webhook göndermeyen izole bir ortam hazırlayın. Dış entegrasyonları kapatmak veya güvenli test uçlarına yönlendirmek, tatbikatın yeni bir olaya dönüşmesini önler.
AWS'nin yedek doğrulama rehberi, periyodik geri yüklemeyle hem veriyi hem süreci sınamayı önerir. Bizim örnek site için bu yaklaşım aşağıdaki çalışma sırasına çevrilebilir. AWS: Periodic Recovery Testing.
- Denemenin hedef kurtarma noktasını ve başlangıç saatini kaydedin.
- Yetkili erişimi ve gerekli anahtarların kullanılabilirliğini doğrulayın.
- Uyumlu uygulama sürümünü ve veriyi izole ortama kurun.
- Temel kayıt sayılarını, ilişkileri ve örnek dosyaları karşılaştırın.
- Yönetici girişi, ürün görüntüleme ve deneme sipariş akışını çalıştırın.
- Eksikleri, harcanan süreyi ve düzeltilecek prosedürleri raporlayın.
Dosyanın sağlama toplamını doğrulamak aktarım bütünlüğü için yararlıdır; iş kayıtlarının anlamlı ve uygulamanın çalışır olduğunu tek başına göstermez. Örnek bir siparişin satırları, toplamı ve bağlı belgeleriyle birlikte açılması daha farklı bir kontrol sağlar.
Başarısızlıkları görünür tutun
Yedekleme görevinin başlamasıyla kullanılabilir kopyanın oluşması farklı durumlardır. Son başarılı kopyanın zamanı, beklenmeyen boyut değişimi ve aktarılamayan dosyalar için takip tanımlayın. Uyarının gerçekten sorumlu kişiye ulaşmasını da denemeye dahil edin.
Saklama süresini yalnızca disk doluluğuna göre belirlemeyin. Hatanın geç fark edilmesi ihtiyacını, verinin niteliğini ve kurumun saklama gereksinimlerini birlikte değerlendirin. Aynı bozuk verinin tekrar tekrar yedeklenmesi eski, sağlam noktaların önemini gösterir.
Güvenlik olayı sonrasında ise herhangi bir kopyayı hızla açmak yeterli değildir. Temiz kurtarma noktası ve güvenilir çalışma ortamı belirlenmeden aynı sorunu geri getirebilirsiniz. Kurtarma planı, olay incelemesi ve gerekli erişim değişiklikleriyle birlikte yürütülmelidir.
Uygulama kontrol listesi
- RPO ve RTO hedeflerini iş sahibiyle ayrı belirleyin.
- Dosya, veritabanı, sürüm ve anahtar envanterini tamamlayın.
- Yedeklerin canlı sistemle ortak arıza noktalarını inceleyin.
- Tutarlılık yöntemini kullanılan altyapıya göre seçin.
- Son kullanılabilir kopyanın yaşını takip edin.
- Test ortamında gerçek dış bildirimleri devre dışı bırakın.
- Kayıtları ve temel kullanıcı işlerini birlikte doğrulayın.
- Tatbikat sonuçlarını kurtarma prosedürüne geri işleyin.
WebWizz ile mevcut yedekleme planınızı değerlendirmek için altyapınızı ve kabul edilebilir kesinti hedefinizi bizimle paylaşabilirsiniz. Konuşmaya depolama alanından değil, geri dönmesi gereken iş akışından başlayabiliriz.
Sık sorulan sorular
Sunucu anlık görüntüsü tek başına yeterli mi?
Altyapının tutarlılık ve kurtarma özelliklerine bağlıdır. Anlık görüntünün kapsamadığı dış dosyalar veya servisler bulunabilir. Yeterliliğini ürün adından değil, envanterinizin tamamını geri yükleyerek değerlendirin.
Yedekleme başarılı mesajı kurtarmayı kanıtlar mı?
Hayır. Mesaj belirli bir görevin sonucunu anlatır. Anahtar erişimi, uygulama uyumluluğu ve verinin çalışır durumda geri gelmesi ayrıca sınanmalıdır.
Kaç gün yedek saklamak gerekir?
Her site için geçerli tek bir sayı yoktur. Hata fark etme süresi, veri değişim sıklığı, kurumun yükümlülükleri ve maliyet birlikte değerlendirilmelidir.
Tatbikat ne zaman tekrarlanmalı?
Risk düzeyine göre düzenli aralık belirleyin; veritabanı, şifreleme, depolama veya uygulama sürümünde önemli değişiklikten sonra da planı yeniden sınayın. Eski bir başarılı deneme yeni yapıyı otomatik doğrulamaz.