TR / EN

SQL Server Yedeklemesinde Named Instance ve Veritabanı Envanteri

Bir sunucunun yedekleme konsolunda görünmesi, üzerindeki bütün SQL veritabanlarının korunduğunu göstermez. Named instance, farklı recovery model veya yeni eklenen uygulama veritabanı sessizce kapsam dışında kalabilir.

8 Temmuz 2026 tarihli vakada SQL Server 2022 named instance üzerindeki birden fazla uygulama veritabanı için günlük bulut yedeği talep edildi. Talebi doğrudan zamanlamaya çevirmek yerine instance, veritabanı, veri kaybı hedefi ve geri dönüş sorumluluğunu envanterledik.

Veritabanı korumasında sorumluluk sınırı açık değilse herkes kendi parçasının çalıştığını söyleyebilir: DBA bakım işinin başarılı olduğunu, altyapı ekibi dosyanın kopyalandığını, bulut ekibi nesnenin depoda bulunduğunu gösterir. Fakat geri yükleme anında doğru zincirin, sertifikanın ve uygulama bilgisinin bir arada olmadığı anlaşılabilir. Bu yüzden uçtan uca hizmet sahibi belirledik ve teknik kayıtları ortak kurtarma kanıtında birleştirdik. Yeni veritabanı açma prosedürüne de yedek sınıfı ve iş hedefi seçimini ekledik; koruma sonradan hatırlanan bir operasyon olmaktan çıktı.

Sorunun ortaya çıkışı

Talepte yalnızca sunucu adı bulunuyor, named instance ve veritabanı listesi yer almıyordu. Sistem veritabanları, uygulama veritabanları, recovery model ve bakım işlerinin sahibi belirsizdi. Günlük full yedek her uygulamanın RPO ihtiyacını karşılamayabilirdi.

DBA, uygulama sahibi, altyapı ve yedekleme ekibi ortak envanter oluşturdu. Her veritabanına iş sahibi, kritiklik, RPO/RTO, recovery model, boyut, büyüme ve saklama gereksinimi atandı.

İlk belirtiler ve yanlış varsayımlar

Named instance adına uzaktan erişilebilmesi için kullanılan keşif yöntemlerinin her ağda güvenilir olacağı sanılıyordu. Sabit bağlantı parametresi ve kontrollü envanter otomatik keşiften daha öngörülebilir olabilir. Tarayıcı servisini açmak varsayılan çözüm yapılmadı.

Full yedek almanın transaction log yönetimini gereksiz kıldığı da yanlıştı. Recovery model ve hedef RPO log yedeği ihtiyacını belirler. Dosyanın buluta kopyalanması, SQL tutarlılığı ve geri yüklenebilir zincir anlamına gelmez.

Teknik analiz

Savunmacı envanter sorgusu yalnızca yetkili DBA hesabıyla çalıştırıldı; sonuçlarda sır bulunmadı. Durum, recovery model ve son yedek zamanları merkezi kayıtla karşılaştırıldı. Yeni veritabanlarını algılayan günlük uyum kontrolü planlandı.

Full temel, differential değişim ve transaction log yedekleri hedeflere göre zincirlendi. CHECKSUM, yedek şifreleme, anahtar saklama, aktarım güvenliği ve offsite kopya değerlendirildi. Sistem veritabanları ile şifreleme sertifikalarının kurtarma ihtiyacı ayrıca ele alındı.

-- Yetkili DBA için savunmacı envanter örneği
SELECT name, state_desc, recovery_model_desc
FROM sys.databases
ORDER BY name;

Uygulanan çözüm veya önerilen mimari

Kritik veritabanları için full, differential ve log planı iş hedeflerine göre oluşturuldu; düşük kritiklikteki sistemlere daha sade plan uygulandı. Yedek dosyaları şifreli biçimde farklı hata alanına kopyalandı ve saklama politikası yasal gereksinimle sınırlandı.

Aylık otomatik doğrulamaya ek olarak dönemsel izole restore testi yapıldı. Test; veritabanını açma, tutarlılık kontrolü, uygulama sahibinin temel işlemi doğrulaması ve ölçülen süreyi kapsadı. Başarısız test operasyon kaydı olarak takip edildi.

Alternatifler ve karar gerekçesi

Native SQL yedekleri şeffaflık ve taşınabilirlik sunar; merkezi platformlar orkestrasyon, izleme ve offsite yönetimini kolaylaştırabilir. Sanal makine görüntüsü hızlı kurtarma sağlayabilir, fakat uygulama tutarlılığı ve noktasal dönüş ihtiyacı doğrulanmalıdır.

Tek araç bütün hedefleri karşılıyor varsayılmadı. SQL-aware yedek, güvenli offsite kopya ve düzenli restore testi birlikte seçildi. Karar lisans özelliğinden çok kanıtlanmış kurtarma zincirine dayandı.

Güvenlik ve operasyonel riskler

Yedekler üretim verisinin tam kopyasıdır. Servis hesabı en az yetkili olmalı, aktarım ve depolama şifrelenmeli, silme yetkisi ayrılmalı ve erişimler loglanmalıdır. Şifreleme anahtarı kaybolursa sağlam yedek kullanılamaz.

Log zincirinin kırılması, depolama doluluğu ve fark edilmeyen yeni veritabanı RPO’yu bozar. Alarm sahipliği ve kapasite eğilimi izlenmelidir. Restore testi üretim üzerine yapılmamalı; izole, yetkili ve veri gizliliğine uygun ortam kullanılmalıdır.

Çıkarılan Dersler

Kontrol Listesi