Yedeklemeyle ilgili en yaygın yanılgı şudur: yedek almak, korunmuş olmak anlamına gelir. Gerçekte veri kayıplarının önemli bir bölümü, yedeği olan ama o yedekten geri dönemeyen işletmelerde yaşanır. Dosya bozuktur, şifreleme anahtarı kaybolmuştur, yedek sunucuyla aynı diskte durduğu için o da gitmiştir ya da geri yükleme prosedürünü kimse daha önce denememiştir.
Bu rehber, bir VDS sunucu için gerçekten işleyen bir yedekleme ve kurtarma planının nasıl kurulacağını anlatıyor. Ölçüt tek: geri yükleme testi geçilmiş mi?
Plana Başlamadan Cevaplanması Gereken İki Soru
Yedekleme sıklığı, saklama süresi ve maliyet — hepsi bu iki sayıdan türer. Cevapları tahmin etmeyin, iş tarafıyla birlikte netleştirin.
- Ne kadar veri kaybını göze alabilirsiniz? Bu, yedekleme sıklığını belirler. Günde on sipariş alan bir sitede günlük yedek yeterlidir; saatte yüz işlem gören bir sistemde bir günlük kayıp kabul edilemez. Cevap "hiç" ise, yedekleme değil çoğaltma (replication) konuşuyorsunuz demektir — farklı ve daha pahalı bir çözüm.
- Ne kadar süre kapalı kalabilirsiniz? Bu, kurtarma yönteminizi belirler. Dört saatlik kesintiyi kaldırabiliyorsanız dosya tabanlı yedekten kurulum yapabilirsiniz. On beş dakikanız varsa hazır bir sistem görüntüsüne (snapshot) ihtiyacınız var.
Bu iki sayı yazıya geçmediği sürece yedekleme planı bir teknik alışkanlıktan öteye gitmez. Yazıya geçtiğinde ise hangi çözümün gerekli, hangisinin fazla olduğu kendiliğinden ortaya çıkar.
Neyi Yedeklemek Gerekir?
"Siteyi yedekliyorum" ifadesi genellikle eksiktir. Tam bir kurtarma için gereken kalemler şunlardır:
1. Veri Katmanı
Veritabanı ve kullanıcı tarafından yüklenen dosyalar. Bu katman yeri doldurulamaz olandır: kaybederseniz hiçbir yerden yeniden üretemezsiniz. Yedekleme önceliğiniz burasıdır ve en sık yedeklenmesi gereken katmandır.
2. Yapılandırma Katmanı
Web sunucusu ayarları, sanal host tanımları, güvenlik duvarı kuralları, zamanlanmış görevler, SSL sertifikaları ve yenileme yapılandırması. Bu katman teoride yeniden üretilebilir ama pratikte aylar süren ince ayarları içerir. Yedeklenmediğinde kurtarma süresi günlere çıkar.
3. Uygulama Katmanı
Kod ve bağımlılıklar. Sürüm kontrolü kullanıyorsanız bu katman zaten güvendedir; kullanmıyorsanız yedeklemeye dahil etmelisiniz. Ayrıca hangi sürümlerin kurulu olduğunu (PHP, veritabanı, eklentiler) bir metin dosyasında tutun — kurtarma anında en çok bu bilgiyi arayacaksınız.
3-2-1 Kuralı ve VDS'te Uygulanışı
Yedekleme dünyasının en dayanıklı pratiği 3-2-1 kuralıdır: verinin üç kopyası, iki farklı ortamda, biri farklı bir fiziksel konumda. Bir VDS için pratik karşılığı şudur:
| Kopya | Nerede | Neye karşı korur |
|---|---|---|
| 1. Canlı veri | Sunucunun kendisi | — |
| 2. Sağlayıcı anlık görüntüsü | Sağlayıcı altyapısı | Yanlış komut, bozulan güncelleme, disk arızası |
| 3. Dış yedek | Bağımsız depolama / farklı sağlayıcı | Hesap kaybı, sağlayıcı kaynaklı sorun, fidye yazılımı |
Kritik nokta üçüncü satırdır. Yalnızca sağlayıcı anlık görüntüsüne güvenmek, tüm yumurtaları tek sepete koymaktır: hesabınıza erişimi kaybederseniz veriye de erişemezsiniz. Dış yedek, planın en sık atlanan ve en çok işe yarayan parçasıdır.
Anlık Görüntü ve Dosya Yedeği: İkisi de Gerekli
Bu ikisi rakip değil, farklı işler için araçlardır. Aralarında seçim yapmaya çalışmak yaygın bir hatadır.
- Anlık görüntü (snapshot): Tüm diskin belirli bir andaki hâli. Kurtarma çok hızlıdır — sunucuyu o ana geri döndürürsünüz. Ancak tek bir dosyayı ya da tek bir tabloyu geri almak için kullanışsızdır ve genellikle sunucuyla aynı altyapıda durur.
- Dosya/veritabanı yedeği: Yavaş kurtarılır ama seçicidir. Yanlışlıkla silinen bir tabloyu, üç gün önceki bir dosya sürümünü tek tek geri alabilirsiniz. Dışarıya taşınabilir olması en büyük avantajıdır.
Pratik yaklaşım: sağlayıcı anlık görüntüsünü felaket kurtarma için, dosya yedeğini günlük hata düzeltme için kullanın. İkisinin birlikte maliyeti, tek bir veri kaybı olayının maliyetinin çok altındadır.
Uygulama: Sekiz Maddelik Kurulum
1. Veritabanı Yedeğini Otomatikleştirin
Zamanlanmış bir görevle düzenli veritabanı dökümü alın ve sıkıştırın. Dökümü alırken tabloların tutarlı bir anda yakalandığından emin olun; yazma trafiği yoğun bir veritabanında tutarsız döküm, geri yüklenemeyen bir dosya üretir.
2. Dosyaları Artımlı Yedekleyin
Her seferinde tüm dosyaları kopyalamak yerine yalnızca değişenleri aktaran bir yöntem kullanın. Hem süre hem depolama kazanırsınız, hem de aynı bütçeyle daha fazla geri dönüş noktası tutabilirsiniz.
3. Yedeği Sunucudan Çıkarın
Bu adım pazarlıksızdır. Yedek dosyaları sunucunun diskinde kaldığı sürece, sunucuyu etkileyen her olay yedeği de etkiler. Aktarımı yedekleme alındıktan hemen sonra otomatik yapın; elle taşınan yedekler taşınmayı unutulur.
4. Dış Depolamaya Yazma-Sınırlı Erişim Verin
Sunucunuzun dış depolamaya erişimi yalnızca yeni dosya yazma yetkisiyle sınırlı olmalı; mevcut yedekleri silme yetkisi olmamalı. Sunucu ele geçirildiğinde saldırganın ilk yapacağı şey yedekleri silmektir. Bu tek yetkilendirme kararı, fidye yazılımı senaryosunda planınızı ayakta tutan şeydir.
5. Saklama Politikası Tanımlayın
Sınırsız saklama gereksiz maliyettir, tek yedek ise yetersizdir. Kademeli bir politika işe yarar: son yedi günün günlük yedeği, son dört haftanın haftalık yedeği, son altı ayın aylık yedeği. Bu yapı, üç hafta önce bozulmuş bir veriyi de yakalamanızı sağlar.
6. Yedeklemeyi İzleyin
Sessizce başarısız olan bir yedekleme, hiç yedek almamaktan daha tehlikelidir — çünkü korunduğunuzu sanırsınız. Yedekleme görevinin başarılı bittiğini ve üretilen dosyanın beklenen boyutta olduğunu kontrol eden bir uyarı kurun. Aniden küçülen bir yedek dosyası, bozuk bir yedeklemenin ilk işaretidir.
7. Şifreleyin ve Anahtarı Ayrı Tutun
Dışarıya çıkan yedekler şifrelenmelidir. Ancak şifreleme anahtarını yedekle aynı yerde tutmak, kilidi kapının üstünde bırakmaktır. Anahtarı bir parola yöneticisinde, yedekten bağımsız saklayın ve kimlerin eriştiğini bilin.
8. Geri Yükleme Prosedürünü Yazın
Kurtarma anı, prosedür öğrenme anı değildir. Adım adım geri yükleme talimatını bir dosyaya yazın ve bu dosyayı sunucunun dışında saklayın. Talimatta şunlar olmalı: yedeğin nerede olduğu, hangi sırayla geri yükleneceği, hangi bilgilerin gerektiği ve kime haber verileceği.
Planı Gerçek Yapan Adım: Geri Yükleme Testi
Bir yedekleme planı, geri yükleme testi geçilene kadar bir varsayımdır. Testi şöyle yapın: yeni bir sunucu açın, yalnızca yedeklerinizi ve yazdığınız prosedürü kullanarak sistemi ayağa kaldırın, süreyi ölçün.
Bu testte tipik olarak ortaya çıkan bulgular şunlardır: yedekte olmadığı fark edilen bir yapılandırma dosyası, kimsenin bilmediği bir şifre, beklenenden çok daha uzun süren bir aktarım. Bunları kurtarma anında değil test anında öğrenmek, testin bütün amacıdır. Yılda en az bir kez, tercihen sistemde büyük bir değişiklikten sonra tekrarlayın.
Sonuç
İyi bir yedekleme planı karmaşık değildir; disiplinlidir. Üç kopya, biri dışarıda, silinemez yetkilendirmeyle, izlenen ve yılda bir test edilen bir düzen — bu kadarı bir VDS sunucu için gerçek koruma sağlar. Planınızda eksik olan tek şey geri yükleme testiyse, henüz test edilmemiş bir umut taşıyorsunuz demektir. O testi yapın; sonucundan bağımsız olarak kazançlı çıkacaksınız.
Sıkça Sorulan Sorular (SSS)
Sağlayıcımın yedeği var, benim ayrıca yedek almam gerekir mi?
Evet. Sağlayıcı yedekleri altyapı arızalarına karşı koruma sağlar; hesap erişimi kaybı, yanlışlıkla silinen veri veya sağlayıcı kaynaklı bir sorunda tek başına yeterli değildir. Ayrıca çoğu sağlayıcı yedeği, tek bir dosyayı seçerek geri almaya izin vermez.
Yedekleme sıklığını nasıl belirlerim?
"Son yedekten bu yana üretilen veriyi kaybetsem ne olur?" sorusunun cevabına göre. Kaybı kabul edilebilir bulduğunuz süre, yedekleme aralığınızdır. Bu süreyi teknik kolaylığa göre değil iş etkisine göre belirleyin.
Fidye yazılımı yedeklerimi de şifreleyebilir mi?
Sunucudan erişilebilen ve silme/değiştirme yetkisi olan yedekler için evet. Bu yüzden dış depolamaya yalnızca yazma yetkisi vermek ve sürüm koruması olan bir depolama kullanmak kritiktir. Sunucunun kendi diskinde duran yedekler bu senaryoda hiçbir koruma sağlamaz.
Geri yükleme testini ne sıklıkla yapmalıyım?
Yılda en az bir kez ve sistemde büyük bir değişiklikten (sürüm yükseltmesi, mimari değişiklik, sunucu taşıma) sonra mutlaka. Test sırasında ölçtüğünüz süre, kesinti planlamanız için gerçek veridir — tahmin değil.
