# SQL Server Backup Stratejisi ve Değişiklik Yönetimi Neden Birlikte Düşünülmeli?

Backup ve değişiklik yönetimi genellikle ayrı konular olarak ele alınır. Ama ikisi arasında kritik bir bağ var: değişiklik yönetimi olmadan backup'ın değeri yarıya iner.

* * *

## Backup Tek Başına Yeterli Değil

"Backup'ımız var, bir şey olursa geri döneriz" cümlesi bir güvence gibi görünür. Ama şu soruyu yanıtlamadan eksik kalır: neye geri döneceğiz?

Bir production krizi yaşandı. Backup'tan geri dönme kararı verildi. Ama son backup'tan bu yana hangi değişiklikler yapıldı? Bunları kaybetmek kabul edilebilir mi? Geri döndükten sonra hangi değişiklikleri tekrar uygulamak gerekecek, hangi sırayla?

Bu soruların yanıtı değişiklik kaydında. Kayıt yoksa geri dönmek basit bir teknik operasyon olmaktan çıkar, belirsizlik içinde bir deneme yanılma sürecine dönüşür.

* * *

## Point-in-Time Recovery ve Değişiklik Kaydı

SQL Server'ın full recovery model'inde transaction log backup'ları sayesinde belirli bir zaman noktasına geri dönmek mümkün.

Ama "hangi zaman noktasına geri döneceğiz" kararını vermek için değişiklik kaydına ihtiyaç var.

"Yanlış deployment saat 14:37'de yapıldı" bilgisi varsa geri dönüş noktası bellidir. Bu bilgi yoksa hangi zaman noktasının "temiz" olduğunu tahmin etmek gerekir.

* * *

## Deployment Öncesi Backup

Her kritik deployment öncesinde tam backup almak iyi bir pratik. Böylece bir şeyler ters giderse deployment öncesindeki temiz duruma hızla dönülebilir.

Bu pratik değişiklik yönetimiyle birleştirildiğinde şu tablo ortaya çıkar: her deployment kaydı, ilgili backup'ın referansını da içeriyor. Kim ne değiştirdi, hangi backup bu değişiklikten önceki durumu koruyor.

* * *

## Backup'ı Test Etmek

Backup var ama test edilmemiş. Bu yaygın ve tehlikeli bir durum.

Restore sürecini gerçekten test etmek için periyodik olarak backup'tan geri yükleme yapılmalı ve sistemin beklenen şekilde çalıştığı doğrulanmalı.

Bu testin değişiklik yönetimiyle ilişkisi şu: geri yükleme sonrası hangi değişikliklerin tekrar uygulanması gerektiği belli olmalı. Değişiklik kaydı olmadan bu liste oluşturulamaz.

* * *

## Retention Süresi ve Denetim

Backup retention süresi ve değişiklik kayıtlarının saklama süresi uyumlu olmalı.

KVKK ve ISO 27001 kapsamında değişiklik kayıtlarının belirli süre saklanması gerekiyor. Aynı dönemin backup'larının da erişilebilir olması, olası bir soruşturmada tam resmi ortaya koymak için şart.

* * *

## Sonuç

Backup ve değişiklik yönetimi birbirini tamamlayan iki katman. Biri olmadan diğeri eksik işlev görür. İkisini birlikte planlayan kurumlar hem teknik hem de compliance açısından çok daha sağlam bir zemine oturur.

Detaylı bilgi için: [sqlchangeguard.com](http://sqlchangeguard.com)