SQL Server Backup Stratejisi ve Değişiklik Yönetimi Neden Birlikte Düşünülmeli?
I’m a passionate software engineer specializing in SQL change management, database security, and DevOps automation. With over 17 years of experience in the banking sector, I focus on building tools and processes that make database deployments safer, more auditable, and automated.
As the creator of SQL Change Guard, I develop solutions that use risk scoring and AI-powered code analysis to detect dangerous SQL scripts before they reach production. I’m dedicated to helping teams minimize downtime and data loss through smarter change governance.
When I’m not coding, I enjoy sharing insights about secure development practices, WPF desktop applications, and integrating modern CI/CD pipelines.
Feel free to connect or reach out at info@sqlchangeguard.com
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