Yedekleme Rehberi: 3-2-1 Kuralı, RPO/RTO ve Fidye Yazılımına Karşı Yedek Stratejisi

Yedekleme, bilişimin en sıkıcı ama en değerli konusudur: ihtiyaç duyulana kadar kimse düşünmez, ihtiyaç duyulduğunda ise her şeydir. Disk arızası, yanlışlıkla silme, hacklenen site, fidye yazılımı veya hosting sağlayıcısındaki bir sorun... Bunların hepsinde verinizi geri getirmenin tek yolu, sağlam bir yedekleme düzenidir. Bu yazıda yaygın kabul gören 3-2-1 kuralını ve bir web sitesi için uygulamasını anlatıyoruz.

3-2-1 kuralı

3 kopya: Verinin asıl kopyası ve en az iki yedek kopya.
2 farklı ortam: Kopyaları farklı türde depolama ortamlarında tutun (örneğin sunucu diski ve bulut depolama); tek bir arıza türü hepsini etkilemesin.
1 kopya farklı yerde (off-site): Yangın, sel, çalınma veya sağlayıcı hatası gibi olaylara karşı en az bir kopya başka bir konumda olmalı.

Günümüzde birçok uzman buna ek olarak "1 değiştirilemez veya çevrimdışı kopya" eklenmesini önerir; böylece fidye yazılımı bağlı yedekleri de şifrelese bile elinizde erişilemeyen temiz bir kopya kalır.

İki temel kavram: RPO ve RTO

RPO (Recovery Point Objective): En fazla ne kadarlık veri kaybını göze alabilirsiniz? Günlük yedek alıyorsanız, en kötü durumda bir günlük veriyi kaybedersiniz. Sipariş alan bir e-ticaret sitesi için bu çok fazla olabilir.
RTO (Recovery Time Objective): Sistem çöktüğünde ne kadar sürede yeniden ayağa kalkmanız gerekir? Yedeğin geri yükleme hızı bunu belirler.

Bu iki hedefi önce iş açısından belirleyin; yedek sıklığınız ve altyapınız buna göre şekillensin.

Bir web sitesi neleri yedeklemeli?

Dosyalar: Kaynak kod, yüklenen görseller ve belgeler, tema ve eklentiler.
Veritabanı: Genellikle sitenin en değerli kısmıdır (içerik, kullanıcılar, siparişler).
Yapılandırma: config dosyaları, .htaccess, sunucu ayarları (gizli anahtarlar yedekte de güvenli saklanmalı).
DNS kayıtları: Dışa aktarın veya ekran görüntüsüyle kaydedin; hesap sorununda yeniden kurmak için gereklidir (DNS rehberi).
E-posta: Kurumsal e-posta kutuları ayrı yedek gerektirebilir.
Üçüncü taraf hesap verileri: Önemli hesapların kurtarma kodları ve erişim bilgileri.

Veritabanı yedeği nasıl alınır?

MySQL/MariaDB için en yaygın araç mysqldump'tır. InnoDB tablolarında tutarlı bir yedek için --single-transaction seçeneği kullanılır:

mysqldump --single-transaction --routines -u KULLANICI -p VERITABANI | gzip > yedek-$(date +%F).sql.gz

Parolayı komut satırına yazmak yerine yapılandırma dosyası kullanın ve çıkan dosyayı şifreleyip başka bir konuma kopyalayın. Cron ile zamanlayarak otomatikleştirebilirsiniz. Hosting panelleri de çoğunlukla yedekleme araçları sunar; bunlar kullanışlıdır ancak tek başına yeterli değildir (aşağıya bakın).

Neden yalnızca hosting yedeğine güvenmemeli?

Yedekler aynı sağlayıcıda ve çoğu zaman aynı hesapta durur; hesap askıya alınırsa, sağlayıcıda büyük bir arıza olursa veya saldırgan hesabı ele geçirirse yedeklerle birlikte gider.
Saklama süresi kısa olabilir; sorunu birkaç gün sonra fark ederseniz temiz yedeğe ulaşamayabilirsiniz.
Geri yükleme koşulları (ücret, süre) belirsiz olabilir.

Kritik veriler için kendi bağımsız yedeğinizi de farklı bir sağlayıcıda tutun.

Fidye yazılımı ve yedekleme

Fidye yazılımı, dosyalarınızı şifreleyip erişimi kapatır ve ödeme ister. Yedekleriniz sunucuya bağlı bir disk veya ağ paylaşımıysa, saldırgan onları da şifreleyebilir veya silebilir. Korunmak için:

Yedeklerin bir kopyasını çevrimdışı veya değiştirilemez (immutable) depolamada tutun (bazı bulut depolama hizmetleri nesne kilitleme sunar).
Yedekleme hesabına, üretim hesabından farklı kimlik bilgileri ve iki aşamalı doğrulama kullanın.
Yedekleme sistemine yalnızca "yazma/ekleme" yetkisi verin; silme yetkisini kısıtlayın.
Güvenlik açıklarını kapatın (web güvenliği rehberi).

Yedekler şifrelenmeli

Yedekleriniz, veritabanındaki tüm kişisel verileri içerir. Çalınan veya yanlış paylaşılan bir yedek, veri ihlali demektir. Yedekleri şifreleyin, erişimi kısıtlayın ve KVKK kapsamındaki teknik tedbirler açısından saklama sürelerini belirleyin.

En önemli adım: geri yüklemeyi test edin

"Çalışmayan bir yedek, yedek değildir." Birçok işletme, ihtiyaç duyduğunda yedeğin eksik, bozuk veya geri yüklenemez olduğunu fark eder. Düzenli aralıklarla (örneğin üç ayda bir) yedeği ayrı bir ortama geri yükleyip sitenin çalıştığını doğrulayın; ne kadar sürdüğünü ölçün (RTO). Adımları bir belgeye yazın; kriz anında kimin ne yapacağı belli olsun.

Saklama politikası

Yalnızca son yedeği tutmak yetmez; sorun geç fark edilirse son yedek de bozuk olabilir. Örnek bir düzen: son 7 günlük günlük yedek, son 4 haftalık haftalık yedek, son birkaç aylık aylık yedek. Depolama maliyetiyle gereksinimleri dengeleyin.

Kontrol listesi

RPO ve RTO hedeflerimi belirledim.
Dosya, veritabanı, yapılandırma ve DNS yedeklerim var.
En az bir kopya başka bir yerde ve başka bir sağlayıcıda.
Bir kopya çevrimdışı/değiştirilemez.
Yedekler şifreli ve erişim kısıtlı.
Yedekleme otomatik ve başarısızlık uyarısı var.
Geri yüklemeyi son aylarda test ettim.

Kaynaklar ve ileri okuma

Sık Sorulan Sorular

Ne sıklıkla yedek almalıyım?

RPO hedefinize göre. İçeriği nadiren değişen bir site için haftalık yeterli olabilir; sipariş alan veya sürekli güncellenen bir sitede günlük veya daha sık, veritabanı için sürekli yedek gerekebilir.

Bulut senkronizasyonu (Drive, Dropbox) yedek midir?

Hayır; senkronizasyon, bir dosyayı sildiğinizde veya fidye yazılımı şifrelediğinde değişikliği de eşitler. Sürüm geçmişi sunan yedekleme çözümleri veya değiştirilemez depolama kullanın.

Yedek almak sunucuyu yavaşlatır mı?

Büyük yedekler anlık yük yaratabilir; trafiğin en düşük olduğu saatlere zamanlayın. --single-transaction gibi seçenekler tabloları kilitlemeden yedek almayı sağlar.