Sunucu yedekleme nedir? 3-2-1 kuralı, snapshot farkı, KVKK ve fidye yazılımına karşı geri dönüş planı

Sunucu yedekleme nedir?

Sunucu yedekleme, sunucudaki verilerin, veritabanlarının, yapılandırma dosyalarının ve gerekirse işletim sisteminin bir kopyasını sunucudan bağımsız bir yerde saklama işidir. Amaç, bir şey ters gittiğinde işi kabul edilebilir bir sürede ve kabul edilebilir bir veri kaybıyla yeniden ayağa kaldırmaktır.

Bu tanımda iki kelime önemli: bağımsız ve geri dönüş. Aynı diskte duran bir kopya yedek sayılmaz, çünkü disk bozulduğunda ya da sunucu ele geçirildiğinde kopya da gider. Hiç geri yüklenmemiş bir yedek de tam anlamıyla yedek sayılmaz, çünkü çalışıp çalışmadığını bilmezsiniz.

Bu yazıda işletme sunucuları için yedeklemenin neden gerekli olduğunu, 3-2-1 kuralını, snapshot ile yedek arasındaki farkı, fidye yazılımı senaryosunu, KVKK açısından yedeğin yerini ve geri dönüş testinin nasıl yapılacağını adım adım ele alıyoruz.

Yedeğiniz yoksa ne olur: veri kaybının yaygın nedenleri

İşinizi bir sunucu üzerinde yürütüyorsanız (muhasebe programı, e-ticaret sitesi, dosya sunucusu ya da bir veritabanı fark etmez) verinin kaybolması birkaç farklı yoldan gelebilir:

• İnsan hatası: Yanlış klasörün silinmesi, hatalı bir güncelleme ya da yanlış veritabanına çalıştırılan bir sorgu.
• Kötü niyet: Mevcut ya da eski bir çalışanın verileri kasten silmesi veya dışarıdan sisteme sızan birinin dosyaları şifrelemesi.
• Donanım ve yazılım arızası: Disk bozulması, dosya sistemi hatası, başarısız bir işletim sistemi güncellemesi.
• Fiziksel olaylar: Yangın, su baskını, elektrik sorunu ya da cihazın çalınması.

Bu olayların hepsinde aynı soru sorulur: "Dosyalarıma ulaşabilecek miyim ve ne zaman?" Önceden planlanmış bir yedekleme yoksa bu sorunun cevabı çoğu zaman "hayır" olur. Yedekleme planı yaparken iki ölçüyü baştan belirlemek işinizi kolaylaştırır:

• Kabul edilebilir veri kaybı: En fazla kaç saatlik ya da kaç dakikalık veriyi kaybetmeyi göze alabilirsiniz? Bu, yedek sıklığını belirler.
• Kabul edilebilir kesinti süresi: Sistem en geç ne zaman yeniden çalışır olmalı? Bu, yedeğin nerede ve hangi biçimde tutulacağını belirler.

3-2-1 kuralı nedir?

3-2-1 kuralı, yedekleme stratejisi kurarken en sık başvurulan basit bir ölçüdür. Kural şunu söyler:

• 3 kopya: Verinin toplam üç tam kopyası olsun (canlı veri dahil).
• 2 farklı ortam: Kopyalardan ikisi birbirinden farklı depolama ortamlarında dursun.
• 1 tesis dışı kopya: En az bir kopya, sunucunun bulunduğu yerden fiziksel olarak ayrı bir lokasyonda bulunsun.

Kural yeni bir fikir değildir: ABD Ulusal Siber Güvenlik ve İletişim Entegrasyon Merkezi (NCCIC), bu yaklaşımı 2012'de yayımladığı "Data Backup Options" başlıklı belgede önermiştir. O günden bu yana kamu kurumları ve üreticiler tarafından temel yedekleme ölçüsü olarak kullanılmaktadır.

Bir sunucu için 3-2-1'i uygulamaya dökmenin örnek bir yolu:

Fidye yazılımı riskini düşünerek bu kurala bir adım daha eklemek iyi bir yöntemdir: kopyalardan birini sunucunun silemeyeceği bir yerde tutmak. Bu, ağdan ayrılmış (çevrim dışı) bir kopya ya da belirli bir süre boyunca değiştirilemeyecek biçimde saklanan bir kopya olabilir. Ayrıca yedeklerin düzenli olarak geri yüklenip hatasız açıldığının doğrulanması da kuralın doğal tamamlayıcısıdır; buna aşağıda ayrı bir bölümde değiniyoruz.

Snapshot ile yedek arasındaki fark

Bulut sunucularda en çok karıştırılan konulardan biri snapshot (anlık görüntü) ile yedeğin aynı şey olup olmadığıdır. Kısa cevap: snapshot kullanışlı bir araçtır ama tek başına yedek stratejisi değildir.

Pratikte doğru kullanım şöyledir: büyük bir güncellemeden ya da yapılandırma değişikliğinden hemen önce snapshot alın, işler ters giderse dakikalar içinde geri dönün. Uzun vadeli koruma için ise sunucudan bağımsız, düzenli ve saklama süresi tanımlanmış yedeklere güvenin.

Bir uyarı daha: veritabanı çalışırken alınan snapshot, veritabanının o anki yazma işlemlerini yarım yakalayabilir. Veritabanları için uygulamanın kendi yedek aracıyla (örneğin SQL Server yedek görevi ya da MySQL için döküm aracı) tutarlı bir yedek almak daha güvenlidir.

Fidye yazılımı senaryosu: yedek sizi nasıl kurtarır, nasıl yarı yolda bırakır

Fidye yazılımı (halk arasında "kripto virüs") sunucudaki dosyaları şifreler ve anahtar karşılığında ödeme ister. Özellikle uzak masaüstüyle internete açık Windows sunucular bu saldırıların sık hedefidir. Senaryoyu adım adım düşünelim:

1. Saldırgan zayıf bir parola ya da yamasız bir servis üzerinden sunucuya girer.
2. Bir süre sistemde kalıp neye erişebildiğini keşfeder.
3. Ulaşabildiği her yeri şifreler: yerel diskler, bağlı ağ sürücüleri ve sunucudan erişilebilen yedek klasörleri.
4. Sizden fidye ister.

Üçüncü adım kritiktir. Yedek deposu sunucuya ağ sürücüsü olarak bağlıysa ya da sunucu yedek deposunda silme yetkisine sahipse, yedekler de canlı veriyle birlikte şifrelenir veya silinir. Bu durumda yedeğiniz var gibi görünür ama işe yaramaz.

Fidye yazılımına dayanıklı bir yedek için kontrol listesi:

• Ayrı kimlik bilgisi: Yedek deposuna erişen hesap, sunucudaki yönetici hesabıyla aynı olmamalı. Mümkünse sunucu yalnız yeni yedek yazabilsin, eskileri silemesin.
• Ayrı ağ ve ayrı lokasyon: Yedek deposu sunucuya kalıcı bir sürücü olarak bağlı durmasın.
• Saklama süresi: Saldırgan sistemde bir süre fark edilmeden kalabileceği için yalnız son günün yedeğini tutmak yetmez. Haftalık ve aylık kopyalar da saklanmalı.
• Şifreleme: Yedeklerin kendisi şifreli olmalı; şifre anahtarı sunucuda düz metin olarak durmamalı.
• Temiz geri dönüş: Geri yüklemeyi saldırının olduğu sunucuya değil, temiz kurulmuş yeni bir sunucuya yapın. Aksi halde saldırganın bıraktığı arka kapı yerinde kalabilir.

Bu ayrımı hazır bir hizmetle kurmak isterseniz Cloud Backup sayfasında planlı yedekleme ve geri dönüş seçeneklerini inceleyebilirsiniz.

KVKK açısından yedekleme

Sunucunuzda müşteri, çalışan ya da tedarikçi bilgisi varsa yedekleriniz de kişisel veri içerir. Bu nedenle yedekleme yalnız teknik bir tercih değil, aynı zamanda bir uyum konusudur.

KVKK'nın 12. maddesi veri sorumlusuna üç temel yükümlülük yükler: kişisel verilerin hukuka aykırı işlenmesini önlemek, verilere hukuka aykırı erişimi engellemek ve verilerin muhafazasını sağlamak. Bunlar için uygun güvenlik düzeyini sağlayan teknik ve idari tedbirlerin alınması gerekir; tedbirler kurumun yapısına, faaliyetine ve risklerine göre belirlenir. Ayrıntılar Kurum'un Veri Güvenliğine İlişkin Yükümlülükler sayfasında yer alıyor.

Bu yükümlülükleri yedekleme tarafına çevirdiğimizde ortaya şu sorular çıkar:

• Muhafaza: Veri kaybolursa geri getirebiliyor musunuz? Düzenli ve test edilmiş bir yedek, muhafaza yükümlülüğünün somut karşılığıdır.
• Erişim: Yedeklere kim erişebiliyor? Yedek dosyaları canlı veri kadar korunmalı: şifreli saklama, sınırlı yetkili hesap, erişim kaydı.
• Hizmet sağlayıcı: Yedekleriniz bir dış sağlayıcıda tutuluyorsa, veri sorumlusu tedbirlerin alınmasından bu veri işleyenle birlikte müştereken sorumludur. Sözleşmede yedeklerin nerede, nasıl ve ne kadar süre tutulduğu açıkça yazmalı.
• İhlal: Kişisel veriler kanuni olmayan yollarla başkalarının eline geçerse veri sorumlusu bunu en kısa sürede ilgili kişiye ve Kurul'a bildirmek zorundadır. Fidye yazılımı saldırısında yalnız şifreleme değil, verinin dışarı çıkarılması da söz konusu olabileceğinden yedekten geri dönmek bildirim yükümlülüğünü ortadan kaldırmaz.
• Lokasyon: Yedeğin hangi ülkede tutulduğunu bilin ve kayıt altına alın; yurt dışında tutulan kopyalar ayrıca değerlendirilmelidir.

Bu bölüm genel bir çerçevedir, hukuki görüş yerine geçmez. Kişisel veri içeren sistemler için ayrı ve korunmuş bir yedek kurgusuna ihtiyacınız varsa KVKK yedekleme çözümüne göz atabilirsiniz.

Adım adım sunucu yedekleme planı

Aşağıdaki adımlar küçük bir işletme sunucusundan çok sunuculu bir yapıya kadar uygulanabilir:

1. Envanter çıkarın. Hangi sunucuda ne var? Veritabanları, kullanıcı dosyaları, web siteleri, yapılandırma dosyaları, lisans dosyaları.
2. Önceliklendirin. Her veri için kabul edilebilir veri kaybını ve kesinti süresini yazın. Muhasebe veritabanı ile arşiv klasörünün sıklığı aynı olmak zorunda değil.
3. Yedek türünü seçin. Tüm sunucunun imaj yedeği hızlı tam geri dönüş sağlar; dosya ve veritabanı yedeği ise daha sık alınabilir ve tek bir kaydı geri getirmeyi kolaylaştırır. Çoğu senaryoda ikisini birlikte kullanmak mantıklıdır: günlük imaj, gün içinde daha sık veritabanı yedeği.
4. 3-2-1'e göre yer belirleyin. En az bir kopya sunucunun bulunduğu lokasyonun dışında olsun. Örneğin bulut sunucu İstanbul'daysa uzak kopyayı farklı bir lokasyonda tutmayı düşünün.
5. Saklama politikası yazın. Örneğin son 7 günlük, son 4 haftalık ve son 6 aylık yedekleri tutmak gibi bir kural belirleyin ve otomatik uygulatın.
6. Otomatikleştirin ve izleyin. Yedek elle alınıyorsa bir gün mutlaka atlanır. Zamanlanmış görev kurun ve başarısız yedekte e-posta ya da mesajla uyarı alın.
7. Geri dönüş testini takvime koyun. En az ayda bir kez seçilen bir yedeği gerçekten geri yükleyin.

Linux sunucularda şifreli ve artımlı yedeği S3 uyumlu bir depoya otomatik göndermek için Restic ile S3 yedekleme rehberindeki adımları izleyebilirsiniz.

Geri dönüş testi nasıl yapılır?

Geri dönüş testi, yedeğin gerçekten açılabildiğini ve içinde beklediğiniz verinin bulunduğunu kanıtlamanın tek yoludur. Test, canlı veriye dokunmadan, ayrı bir klasöre ya da ayrı bir test sunucusuna yapılmalıdır.

Önce en son yedeğin ne zaman alındığını kontrol edin. Aşağıdaki komut, yedek klasöründe son 24 saatte değişmiş dosya olup olmadığına bakar; çıktı boşsa yedek görevi çalışmıyor olabilir:

find /yedek/gunluk -type f -mtime -1 -printf '%TY-%Tm-%Td %TH:%TM  %s bayt  %p\n' | sort | tail -n 5

Ardından yedeği canlı veriden ayrı bir test klasörüne açın ve içeriği karşılaştırın. Bu örnekte tar arşivi kullanılıyor; komutlar mevcut dosyaların üzerine yazmaz:

TEST=/srv/geri-donus-testi/$(date +%F)
mkdir -p "$TEST"
tar -xzf /yedek/gunluk/web-$(date +%F).tar.gz -C "$TEST"

# Canlı veriyle farkları listele (yalnız okur, değişiklik yapmaz)
diff -rq /var/www "$TEST/var/www" | head -n 20

# Kritik bir dosyanın bütünlüğünü karşılaştır
sha256sum /var/www/site/config.php "$TEST/var/www/site/config.php"

Veritabanı yedekleri için canlı veritabanının üzerine değil, adı farklı bir test veritabanına geri yükleyin ve basit kontroller yapın:

mysql -e "CREATE DATABASE geri_donus_testi;"
mysql geri_donus_testi < /yedek/gunluk/magaza-$(date +%F).sql
mysql -e "SELECT COUNT(*) FROM geri_donus_testi.siparisler;"

Kontrol noktaları:

• Arşiv hatasız açıldı mı?
• Kayıt sayıları canlı sisteme yakın mı? (Yedek anından sonra eklenen kayıtlar kadar fark normaldir.)
• Uygulama test verisiyle çalışıyor mu? Örneğin muhasebe programı test veritabanına bağlanıp açılıyor mu?
• Geri yükleme ne kadar sürdü? Bu süre, belirlediğiniz kabul edilebilir kesinti süresinin içinde mi?

Test bittiğinde sonucu tarih, yedek adı ve süreyle birlikte kayda geçirin. Bu kayıt hem kendi kontrolünüz hem de KVKK kapsamındaki teknik tedbirlerinizi belgelemek için işe yarar.

Sık yapılan hatalar

• Yedeği aynı sunucuda tutmak: Disk arızası ya da fidye yazılımı canlı veriyle birlikte yedeği de götürür.
• Yalnız snapshot'a güvenmek: Snapshot çoğu zaman aynı depolama sisteminde durur ve uzun süre saklanmaz.
• Hiç test etmemek: Yedek görevi "başarılı" görünse de arşiv bozuk, veritabanı dökümü yarım ya da şifre anahtarı kayıp olabilir.
• Şifre anahtarını yedekle aynı yerde saklamak: Anahtarı kaybederseniz yedeği açamazsınız; yedekle aynı yerde tutarsanız şifrelemenin anlamı kalmaz. Anahtarı ayrı ve güvenli bir yerde saklayın.
• Kısa saklama süresi: Sadece son yedeği tutmak, sorun fark edilene kadar bozuk verinin yedeklere de yayılmasına yol açabilir.
• Uyarı kurmamak: Yedek görevinin haftalardır çalışmadığı ancak ihtiyaç anında fark edilir.

Sık sorulan sorular

Sunucu yedekleme ile bulut yedekleme aynı şey mi?

Sunucu yedekleme, sunucudaki verinin kopyasını alma işinin genel adıdır. Bulut yedekleme ise bu kopyanın internet üzerinden erişilen, sunucudan ayrı bir depoda tutulmasıdır. Bulut yedekleme, 3-2-1 kuralındaki tesis dışı kopyayı sağlamanın pratik bir yoludur.

Snapshot almak yedek yerine geçer mi?

Tek başına geçmez. Snapshot, değişiklik öncesi hızlı geri dönüş için çok kullanışlıdır ama genellikle sunucu diskiyle aynı depolama sisteminde durur ve kısa süre saklanır. Uzun vadeli koruma için sunucudan bağımsız bir depoya alınan yedek gerekir.

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

Bu, kaybetmeyi göze alabileceğiniz veri miktarına bağlıdır. Gün içinde sürekli kayıt giren bir muhasebe ya da e-ticaret veritabanı için gün içinde birden fazla yedek mantıklıdır; nadiren değişen dosyalar için günlük yedek yeterli olabilir.

Fidye yazılımı yedeklerimi de şifreleyebilir mi?

Evet, yedek deposu sunucudan erişilebiliyorsa ve sunucunun orada silme ya da değiştirme yetkisi varsa şifreleyebilir. Bunu önlemek için yedek deposunu ayrı kimlik bilgisiyle, kalıcı bağlantı olmadan ve sunucunun eski yedekleri silemeyeceği biçimde kurun; ayrıca bir kopyayı çevrim dışı ya da değiştirilemez tutun.

KVKK yedek almayı zorunlu kılıyor mu?

KVKK'nın 12. maddesi veri sorumlusuna verilerin muhafazasını sağlama ve bunun için uygun teknik ve idari tedbirleri alma yükümlülüğü getirir. Yedekleme bu tedbirlerin en temel olanlarından biridir; hangi ölçüde ve nasıl yapılacağı ise kurumun yapısına ve risklerine göre belirlenir.