Microsoft SQL Server 2025 Always On Availability Group Veritabanı Restore İşlemi

bakicubuk

6 saat önce

Merhaba

Bu yazımızda, Microsoft SQL Server 2025 Always On Availability Group yapısına bir Database (Veritabanı)’nin Restore (Geri Yükleme) edilmesi sürecini adım adım anlatıyor olacağız.

Daha önceki yazı dizimizde Microsoft SQL Server 2025 Always On Availability Group mimarisini detaylı şekilde kurulumu ve yapılandırmasını anlatmıştık. High Availability (Yüksek Erişebilirlik) ve Disaster Recovery (Felaket Kurtarma) senaryolarını örnek bir mimari üzerinden açıklayacak ve üretim ortamları için gerekli tüm ön koşulları ele almıştık.

Daha önceki yazımızda

W25SQL25NOD1 ve W25SQL25NOD2 isimli Windows Server 2025 sunucularımız üzerinde Windows Server Failover Cluster (WSFC) yapısının kurulum ve yapılandırma adımlarını tamamlamıştık.

Daha sonraki yazımızda

W25SQL25NOD1 ve W25SQL25NOD2 isimli Windows Server 2025 sunucularımız üzerinde Microsoft SQL Server 2025 kurulum ve yapılandırma adımlarını başarıyla tamamlamıştık.

Daha sonraki yazımızda

W25SQL25NOD1 ve W25SQL25NOD2 isimli sunucularımız üzerinde Microsoft SQL Server 2025 Always On Availability Group yapılandırması öncesinde, her iki sunucu üzerindeki Microsoft SQL Server 2025 servisleri için gerekli tüm ön yapılandırmaları başarıyla tamamladık.

ve en son yazımızda

Microsoft SQL Server 2025 Always On Availability Group Kurulumu 4

Microsoft SQL Server 2025 SQL Always On Availability Group mimarisinin kurulum ve yapılandırma adımlarını, Availability Group oluşturma sürecini ve dikkat edilmesi gereken teknik noktaları detaylı olarak ele almıştık.

Bu kapsamda, NIHATCUBUKDB isimli Database (Veritabanı)’nı mevcut Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edeceğiz.

İlk olarak, W25SQL25NOD1 isimli sunucumuz üzerinde, NIHATCUBUKDB isimli Database (Veritabanı)’ne ait NIHATCUBUKDB.bak dosyasını, Microsoft SQL Server 2025 Always On Availability Group yapısına uygun dizinler altına kopyalıyoruz.

Bu adımda, NIHATCUBUKDB.bak dosyasını, Microsoft SQL Server 2025 Always On Availability Group yapısında yapılandırılmış olan H:\DATA dizinine kopyalıyoruz.

Bu hazırlık işlemi, veritabanının sorunsuz bir şekilde Restore (Geri Yükleme) edilmesi ve sonrasında Availability Group yapısına başarılı bir şekilde dahil edilebilmesi açısından kritik öneme sahiptir.

W25SQL25NOD1 isimli sunucumuz üzerinde Microsoft SQL Server Management Studio (SSMS) konsolunu açıyoruz ve karşımıza Connect ekranı geliyor.

Connect ekranında Connection Properties bölümü altında

Server Name bölümünde, bağlantı kurulacak W25SQL25NOD1 isimli sunucumuzun adını giriyoruz. Bu alan, istemci veya yönetim aracının hangi SQL Server instance’ına bağlanacağını belirler.
Authentication bölümünde Windows Authentication seçeneğini tercih ediyoruz. Bu yöntemle kimlik doğrulama, Active Directory üzerindeki kullanıcı veya servis hesabı bilgileri kullanılarak gerçekleştirilir. Windows Authentication, parola yönetimi ve merkezi güvenlik politikaları açısından SQL Authentication’a göre daha güvenli ve yönetilebilir bir yaklaşımdır.
Encrypt bölümünde, SQL Server ile istemci arasındaki bağlantının hangi şifreleme düzeyinde kurulacağını yapılandırıyoruz. Varsayılan olarak Mandatory (Zorunlu) seçeneği aktif gelir ve bu ayar, tüm istemci bağlantılarının TLS üzerinden şifrelenmesini zorunlu kılar. Böylece ağ üzerinde taşınan veriler düz metin olarak iletilmez ve olası dinleme (sniffing) saldırılarına karşı korunur.
Trust Server Certificate seçeneğini işaretleyerek, istemcinin SQL Server tarafından sunulan sertifikayı doğrulama zincirini kontrol etmeden kabul etmesini sağlıyoruz. Bu ayar genellikle LAB, TEST ortamlarında veya self-signed sertifika kullanılan senaryolarda tercih edilir. PROD ortamlarda ise güvenilir bir iç CA veya public CA tarafından üretilmiş sertifikalar kullanılması ve bu seçeneğin kapalı bırakılması önerilir.

Connect seçeneği ile W25SQL25NOD1 isimli sunucumuza bağlantı sağlıyoruz.

Microsoft SQL Server Management Studio (SSMS) konsolunda W25SQL25NOD1 isimli sunucumuza bağlantı sağlamış oluyoruz.

Microsoft SQL Server Management Studio (SSMS) konsolunda Databases bölümü altında BAKICUBUKDB isimli Database (Veritabanı)’in BAKICUBUKDB (Synchronized) durumunda olduğunu görüyoruz.

BAKICUBUKDB (Synchronized) durumu, veritabanının SQL Server Always On Availability Group yapısında Primary ve Secondary replikalar arasında senkronize çalıştığını ve yapının sağlıklı olduğunu gösterir.

W25SQL25NOD1 isimli sunucumuz üzerinde Microsoft SQL Server Management Studio (SSMS) konsoluna bağlantı sağlıyoruz.

Microsoft SQL Server Management Studio (SSMS) konsolununda Databases (Veritabanları) bölümüne sağ tıklayarak Restore Database… seçeneğini seçiyor ve NIHATCUBUKDB isimli Database (Veritabanı) için Restore (Geri Yükleme) işlemini başlatıyoruz.

Bu işlem ile NIHATCUBUKDB isimli Database (Veritabanı), W25SQL25NOD1 sunucusu üzerinde tekrar erişilebilir ve kullanılabilir hale gelir.

Restore Database ekranı karşımıza geliyor.

Restore Database ekranında Source (Kaynak) bölümü altında yer alan Database ve Device seçenekleri, geri yüklenecek Database (Veritabanı)’nin hangi kaynaktan alınacağını belirlemek amacıyla kullanılır. Bu iki seçenek, tercih edilen kullanım senaryosu ve ortamın yapılandırma gereksinimlerine göre farklı avantajlar sunar.

Database: Bu seçenek, SQL Server üzerinde daha önce alınmış ve sistem tarafından tanınan yedeklerin kullanılarak Restore (Geri Yükleme) yapılmasını sağlar. Bu yöntemde SQL Server, seçilen veritabanına ait mevcut yedek setlerini otomatik olarak listeler ve kullanıcıdan yalnızca uygun yedeğin seçilmesi beklenir. Aynı sunucu üzerinde alınmış yedeklerin geri yüklenmesi gereken test veya hızlı geri dönüş senaryolarında pratik bir çözüm sunar. Ancak farklı bir sunucudan taşınan veya SQL Server tarafından henüz tanınmayan .bak dosyaları bu seçenek altında görüntülenmez. Bu nedenle, SQL Server Always On Availability Group gibi çok sunuculu mimarilerde kullanım alanı sınırlıdır.
Device: Bu seçenekte, ise geri yüklenecek .bak uzantılı yedek dosyasının manuel olarak seçilmesine imkan tanır. Bu yöntem sayesinde yedek dosyası; lokal disk, farklı bir storage alanı veya ağ paylaşımı (UNC path) üzerinden gösterilebilir. SQL Server, seçilen dosya içerisindeki yedek setlerini okuyarak listeleme yapar ve Restore (Geri Yükleme) işlemi bu dosya üzerinden gerçekleştirilir. Farklı sunucular arasında restore işlemlerinde, Disaster Recovery (Felaket Kurtarma) senaryolarında ve özellikle Microsoft SQL Server 2025 Always On Availability Group yapılandırmalarında tercih edilen ve önerilen yöntemdir. Always On mimarisinde Secondary node üzerine yapılan restore işlemleri ve Database Join adımları öncesinde, yedek dosyasının manuel olarak kontrol edilebilmesi ve doğru storage üzerinden seçilmesi kritik öneme sahiptir. Bu nedenle, kurumsal ve üretim ortamlarında Device seçeneği daha güvenli ve esnek bir yaklaşım sunar.

Restore Database ekranında Destination (Hedef) bölümü altında yer alan Database ve Restore to seçenekleri, geri yüklenecek Database (Veritabanı)’nin hedef ortamda nasıl konumlandırılacağını belirlemek amacıyla kullanılır.

Database: Bu seçenek, Restore (Geri Yükleme) işlemi sonucunda oluşturulacak veya üzerine yazılacak veritabanının adını belirler. Bu alanda varsayılan olarak yedek dosyası içerisindeki orijinal veritabanı adı gelir. İhtiyaca göre bu isim değiştirilebilir. Bu sayede aynı veritabanı farklı bir isimle geri yüklenebilir veya mevcut bir veritabanı üzerine restore işlemi gerçekleştirilebilir. Özellikle test, ön üretim (pre-prod) veya farklı senaryolar için yapılan Restore (Geri Yükleme) bu alan esneklik sağlar.
Restore to: Bu seçenekte, ise geri yükleme işleminin hangi sunucu instance’ı üzerinde gerçekleştirileceğini ifade eder. SQL Server üzerinde birden fazla instance bulunması durumunda, Restore (Geri Yükleme) işleminin hangi instance’a yapılacağı bu alan üzerinden belirlenir. Böylece yedek dosyasının doğru SQL Server instance’ına geri yüklenmesi sağlanır ve olası yapılandırma hatalarının önüne geçilir.

Bu iki seçeneğin doğru yapılandırılması, Restore (Geri Yükleme) işleminin sorunsuz tamamlanması ve özellikle Microsoft SQL Server 2025 Always On Availability Group gibi çok sunuculu ve High Availability (Yüksek Erişebilirlik) mimarilerinde doğru hedefin seçilmesi açısından kritik öneme sahiptir.

Restore Database ekranında Source bölümünde yer alan Database seçeneği üzerinden geri yüklenecek Database (Veritabanı)’yi belirleyebilirsiniz.

Restore Database ekranında SQL Server üzerinde mevcut olan yedek setleri listelenir ve uygun veritabanı seçimi yapılır.

Restore Database ekranında Source bölümünde yer alan Device seçeneği üzerinden .bak uzantılı Database (Veritabanı) yedek dosyasını belirtmemiz gerekiyor. NIHATCUBUKDB.bak yedek dosyasının ismi farklılık gösterebilir; burada önemli olan dosyanın .bak uzantılı olmasıdır.

Restore Database ekranında Source bölümünde yer alan Device seçeneği üzerinden NIHATCUBUKDB.bak isimli Backup dosyasını göstermek için üç nokta (…) simgesine tıklıyoruz.

Select backup devices ekranında yer alan Backup media type bölümünde, yedek dosyasının bulunduğu ortama bağlı olarak File, URL veya S3 URL seçeneklerinden biri yapılandırılabilir.

Select backup devices ekranında yer alan Backup media type bölümü, geri yüklenecek yedek dosyasının hangi depolama ortamında bulunduğunu belirtmek amacıyla kullanılır.

Select backup devices ekranında yer alan Backup media type bölümünde File, URL ve S3 URL olmak üzere üç farklı seçenek sunulmaktadır.

File: Bu seçenek, yedek dosyasının lokal diskler veya ağ paylaşımı (UNC path) üzerinde bulunması durumunda tercih edilir. En yaygın kullanılan yöntem olup, özellikle kurum içi ortamlarda ve on-premise altyapılarda alınan yedeklerin geri yüklenmesinde kullanılır. SQL Server, belirtilen dosya yoluna doğrudan erişerek yedek setlerini okur ve Restore (Geri Yükleme) işlemini gerçekleştirir.
URL: Bu seçenek, yedek dosyalarının bulut tabanlı depolama alanlarında tutulduğu senaryolar için kullanılır. Genellikle Microsoft Azure Blob Storage üzerinde saklanan yedekler bu yöntemle geri yüklenir. Bu seçenek, yedekleme ve Restore (Geri Yükleme) süreçlerinin lokasyon bağımsız yönetilmesine imkan tanır ve Disaster Recovery (Felaket Kurtarma) senaryolarında önemli avantaj sağlar.
S3 URL: Bu seçenekte,ise Amazon S3 veya S3 uyumlu nesne depolama servisleri üzerinde tutulan yedek dosyalarının kullanılmasını sağlar. Bu yöntem sayesinde SQL Server, S3 protokolü üzerinden yedek dosyasına erişerek Restore (Geri Yükleme) işlemini gerçekleştirebilir. Hibrit ve çoklu bulut mimarilerinde, farklı depolama platformları arasında esneklik sağlamak amacıyla tercih edilir.

Select backup devices ekranında yer alan Backup media type seçiminin doğru yapılması, Restore (Geri Yükleme) işleminin sorunsuz tamamlanması ve özellikle Microsoft SQL Server 2025 Always On Availability Group gibi High Availability (Yüksek Erişebilirlik) senaryolarında yedekleme stratejisinin sağlıklı işlemesi açısından kritik öneme sahiptir.

Select backup devices ekranında yer alan Backup media type alanında File seçeneğini işaretliyoruz. Lokal disk veya ağ paylaşımı üzerinde bulunan .bak uzantılı yedek dosyasını eklemek için Add seçeneğine tıklayarak bir sonraki adıma geçiyoruz.

Locate Database File – W25SQL25NOD1 ekranında Microsoft SQL Server 2025 Always On Availability Group yapısında yapılandırılmış olan BACKUP dizinine gidiyoruz. Bu dizin altında yer alan .bak uzantılı NIHATCUBUKDB.bak isimli Backup dosyasını seçiyoruz ve ardından OK seçeneğine tıklıyoruz.

Select backup devices ekranında Backup media bölümü altında .bak uzantılı NIHATCUBUKDB.bak isimli Backup dosyasının listelendiğini görüyoruz.

Select backup devices ekranında seçimi onaylamak için OK seçeneğine tıklıyoruz.

Restore Database ekranında Database bölümünde NIHATCUBUKDB isimli Database (Veritabanı)’nin otomatik olarak geldiğini görüyoruz. Bu durum, seçmiş olduğumuz .bak uzantılı yedek dosyasının SQL Server tarafından doğru şekilde okunduğunu ve ilgili veritabanı ile eşleştirildiğini göstermektedir.

Restore Database ekranında Restore plan bölümü altında yer alan Backup sets to restore alanı, geri yüklenecek yedek setine ait detaylı teknik bilgilerin görüntülendiği bölümdür. Bu alan, doğru yedeğin seçildiğinin doğrulanması ve restore işleminin güvenli bir şekilde gerçekleştirilmesi açısından büyük önem taşır.

Restore sütunu, ilgili yedek setinin geri yükleme işlemine dahil edilip edilmeyeceğini gösterir. İşaretli olan yedek setleri restore işlemi sırasında kullanılacaktır.
Name alanı, yedek setine verilen mantıksal adı ifade eder. Genellikle yedekleme sırasında SQL Server tarafından otomatik olarak oluşturulur.
Component sütunu, yedeğin hangi bileşene ait olduğunu gösterir. Çoğu senaryoda bu alan Database olarak görüntülenir.
Type alanı, yedek türünü belirtir. Bu sütunda Full, Differential veya Transaction Log gibi yedek türleri yer alır.
Server alanı, yedeğin alındığı kaynak SQL Server sunucusunun adını gösterir.
Database sütunu, yedek setinin hangi Database (Veritabanı)’ye ait olduğunu ifade eder.
Position alanı, aynı yedek dosyası (.bak) içerisinde birden fazla yedek bulunması durumunda, ilgili yedeğin dosya içindeki sırasını belirtir.

First LSN (Log Sequence Number), yedek setinin kapsadığı ilk işlem günlüğü numarasını gösterir ve transaction zincirinin başlangıcını temsil eder.
Last LSN, yedek setinin kapsadığı son işlem günlüğü numarasını ifade eder.
Checkpoint LSN, yedek alındığı anda veritabanının checkpoint durumunu temsil eden LSN bilgisini gösterir.
Full LSN, differential veya log yedeklerinin bağlı olduğu Full Backup’a ait LSN bilgisini ifade eder. Yedek zincirinin doğrulanmasında kritik rol oynar.

Start Date, yedekleme işleminin başlatıldığı tarih ve saati gösterir.
Finish Date, yedekleme işleminin tamamlandığı tarih ve saati ifade eder.
Size, ilgili yedek setinin disk üzerindeki boyutunu gösterir.
User Name, yedekleme işlemini başlatan kullanıcı hesabını belirtir.
Expiration, yedek setinin geçerlilik süresini ifade eder. Bu tarih dolduğunda yedek seti süresi geçmiş olarak değerlendirilir.

Restore Database ekranında Restore plan bölümü altında yer alan Backup sets to restore alanında yer alan bilgilerin doğru şekilde kontrol edilmesi, özellikle Microsoft SQL Server 2025 Always On Availability Group gibi High Availability (Yüksek Erişebilirlik) mimarilerinde, doğru yedek setinin restore edilmesini ve Database Join sürecinin sorunsuz ilerlemesini sağlar.

Restore Database ekranında yer alan Verify Backup Media seçeneğine tıklayarak, NIHATCUBUKDB.bak isimli .bak uzantılı yedek dosyasının bozuk olup olmadığını ve Restore (Geri Yükleme) işlemi için uygunluğunu doğruluyoruz.

Restore Database ekranında Verify Backup Media seçeneğine tıklayarak .bak uzantılı NIHATCUBUKDB.bak isimli Backup dosyasını doğruluyoruz. Kontrol işlemi başarıyla tamamlandığında Backup media verified successfully ifadesinin görüntülendiğini görüyoruz.

Restore Database ekranında General menüsünde gerekli yapılandırmaları tamamladıktan sonra Files menüsüne tıklayarak Restore (Geri Yükleme) işleminin dosya yapılandırma adımlarına geçiyoruz.

Restore Database ekranında Files menüsüne geçtiğimizde, Restore (Geri Yükleme) edilecek olan NIHATCUBUKDB isimli Database (Veritabanı)’e ait dosyaların nasıl ve hangi dizinlere Restore (Geri Yükleme) edileceğini belirlememizi sağlayan alanlar yer alır. Bu bölüm, özellikle farklı sunuculara yapılan Restore (Geri Yükleme) işlemleri ve Microsoft SQL Server 2025 Always On Availability Group mimarilerinde kritik öneme sahiptir.

Logical File Name, veritabanı içerisinde tanımlı olan mantıksal dosya adını ifade eder. SQL Server, her veritabanı için en az bir adet Data – .mdf (Master Data File) ve bir adet Log – .ldf (Log Data File) dosyasına ait mantıksal isimleri bu alanda listeler. Restore (Geri Yükleme) işlemi sırasında bu isimler değiştirilemez ve SQL Server tarafından referans olarak kullanılır.
File Type alanı, ilgili dosyanın türünü gösterir. Bu bölümde dosyanın Data (veri dosyası) mı yoksa Log (transaction log dosyası) mı olduğu belirtilir. Bu ayrım, dosyaların doğru disk ve dizinlere yönlendirilmesi açısından önemlidir.
Original File Name, veritabanının yedeğinin alındığı kaynak sunucu üzerindeki orijinal fiziksel dosya yolunu gösterir. Bu alan sayesinde veritabanının backup alındığı sistemde data ve log dosyalarının hangi dizinler altında tutulduğu görüntülenir. Restore (Geri Yükleme) sırasında hedef sunucu üzerindeki dizin yapısının planlanmasına yardımcı olur.
Restore As alanı ise veritabanı dosyalarının Restore (Geri Yükleme) sonrasında hangi dizin ve dosya adıyla oluşturulacağını belirler. Bu bölümde, hedef sunucuya uygun DATA ve LOG dizinleri seçilerek dosyaların doğru konumlara restore edilmesi sağlanır. Özellikle Always On ve Cluster yapılarında, tüm node’larda dizin yapısının uyumlu olması bu alan üzerinden yapılan doğru yapılandırma ile garanti altına alınır.

Restore Database ekranında Files menüsündeki bu alanların doğru şekilde yapılandırılması, Restore (Geri Yükleme) işleminin sorunsuz tamamlanmasını ve Restore (Geri Yükleme) sonrası Database Attach veya Availability Group Join adımlarının problemsiz ilerlemesini sağlar.

Restore Database ekranında Files menüsünde yer alan Original File Name alanında, NIHATCUBUKDB isimli Database (Veritabanı)’nin backup alındığı sistemde Data – .mdf (Master Data File) ve Log – .ldf (Log Data File) dosyalarının hangi dizinler altında tutulduğunu görüntülüyoruz. Bu bilgi, Restore (Geri Yükleme) işlemi sırasında hedef sunucuya uygun dizin eşleştirmesinin yapılmasına yardımcı olur.

Restore Database ekranında Files menüsünde yer alan Restore As alanı, veritabanına ait Data – .mdf (Master Data File) ve Log – .ldf (Log Data File) dosyalarının hedef sunucu üzerindeki konumlarını belirlememizi sağlar. Bu alanda yapılan doğru dizin ve dosya adı yapılandırması, Restore (Geri Yükleme) işleminin sorunsuz tamamlanması ve özellikle Microsoft SQL Server 2025 Always On Availability Group yapılarında tüm node’lar arasında dizin uyumluluğunun sağlanması açısından kritik öneme sahiptir.

Restore Database ekranında Restore all files to folder seçeneğini işaretleyerek, NIHATCUBUKDB isimli Database (Veritabanı)’nin hangi dizin altına Restore (Geri Yükleme) edileceğini yapılandırıyoruz. Bu seçenek etkinleştirildiğinde, veritabanına ait tüm dosyalar belirlenen hedef dizinler altına otomatik olarak yönlendirilir.

Restore all files to folder seçeneğini seçtiğimizde, Restore As bölümünde NIHATCUBUKDB isimli Database (Veritabanı)’nin Restore (Geri Yükleme) işleminin hangi dizinler altında gerçekleştirileceğini görüntülüyoruz. Bu alan, hedef sunucu üzerindeki disk ve klasör yapısının doğru şekilde yapılandırıldığını doğrulamak açısından önemlidir.

Data file folder alanında, seçmiş olduğumuz veritabanına ait Primary Data File (.mdf) dosyasının yolu E:\DATA olarak görüntülenir. Bu yapılandırma ile NIHATCUBUKDB isimli Database (Veritabanı)’ne ait Primary Data File (.mdf) dosyası, SQL Server Always On Availability Group mimarisine uygun disk yapısı altında konumlandırılmış olur.
Log file folder alanında ise veritabanına ait Transaction Log (.ldf) dosyasının yolu F:\LOG olarak görüntülenir. Böylece NIHATCUBUKDB isimli Database (Veritabanı)’nin Transaction Log (.ldf) dosyası, SQL Server Always On Availability Group mimarisine uygun disk yapısı altında konumlandırılmış olur.

Restore Database ekranında Files menüsünde gerekli tüm yapılandırmaları tamamladıktan sonra, Restore (Geri Yükleme) davranışlarını belirlemek üzere Options menüsüne tıklıyoruz.

Restore Database ekranında yer alan Options bölümü, Restore (Geri Yükleme) işleminin nasıl gerçekleştirileceğini ve veritabanının Restore (Geri Yükleme) sonrasında hangi durumda olacağını belirlemek amacıyla kullanılır. Bu bölümde yapılan doğru yapılandırmalar, özellikle üretim ortamları ve Microsoft SQL Server 2025 Always On Availability Group mimarilerinde kritik öneme sahiptir.

Overwrite the existing database (WITH REPLACE) seçeneği, hedef sunucu üzerinde aynı isimde bir veritabanı bulunması durumunda mevcut veritabanının üzerine yazılarak Restore (Geri Yükleme) yapılmasını sağlar. Bu seçenek genellikle test ortamlarında veya mevcut veritabanının tamamen yenilenmesi gereken senaryolarda kullanılır. Üretim ortamlarında kullanılmadan önce mutlaka mevcut veritabanının yedeğinin alınması önerilir.
Preserve the replication settings (WITH KEEP_REPLICATION) seçeneği, veritabanı replikasyon yapılandırmalarının korunmasını sağlar. Replikasyon kullanılan ortamlarda tercih edilir; SQL Server Always On Availability Groupsenaryolarında genellikle aktif olarak kullanılmaz.
Restrict access to the restored database (WITH RESTRICTED_USER) seçeneği, Restore (Geri Yükleme) işlemi tamamlandıktan sonra veritabanına yalnızca belirli yetkilere sahip kullanıcıların erişebilmesini sağlar. Bakım veya doğrulama işlemleri sırasında veritabanına kontrollü erişim sağlamak için kullanılabilir.

Recovery state bölümü, Restore (Geri Yükleme) işlemi sonrasında veritabanının hangi durumda bırakılacağını belirler.

RESTORE WITH RECOVERY seçildiğinde, Restore (Geri Yükleme) işlemi tamamlanır ve veritabanı kullanıma açılır.
RESTORE WITH NORECOVERY seçeneği ise veritabanını Restore (Geri Yükleme) modunda bırakır. Bu seçenek, birden fazla yedek (Full, Differential, Log) uygulanacak senaryolarda veya Always On Availability Group Secondary node üzerinde yapılan restore işlemlerinde tercih edilir.
RESTORE WITH STANDBY seçeneği ise veritabanının salt okunur (read-only) modda kullanılmasına imkan tanır; ancak Always On senaryolarında yaygın olarak kullanılmaz.

Take tail-log backup before restore seçeneği, Restore (Geri Yükleme) işleminden önce mevcut veritabanına ait son işlem günlüklerinin (tail-log) yedeğinin alınmasını sağlar. Bu işlem, restore öncesinde gerçekleşmiş ancak henüz herhangi bir yedeğe dahil edilmemiş işlemlerin korunmasına yardımcı olur ve veri kaybını önlemek amacıyla özellikle üretim (Production) ortamlarında kritik bir güvenlik önlemi olarak kullanılır. Bu seçenek altında yer alan Backup file alanı, alınacak tail-log yedeğinin hangi dosya yolu ve dosya adı ile saklanacağını belirlemek için kullanılır. Belirtilen dizinin SQL Server tarafından erişilebilir olması ve yeterli disk alanına sahip olması gerekir.

Leave source database in the restoring state seçeneği ise Restore (Geri Yükleme) işlemi sonrasında kaynak veritabanının RESTORING durumunda bırakılmasını sağlar. Bu ayar, veritabanı üzerinde ek transaction log veya differential backup restore işlemleri yapılacak senaryolarda tercih edilir. Özellikle Microsoft SQL Server Always On Availability Group yapılandırmalarında, Secondary node üzerinde yapılan restore işlemlerinde bu seçeneğin kullanılması zorunludur. Veritabanı bu durumda kullanıcı erişimine kapalı kalır ve Database Join adımı tamamlanana kadar çevrimiçi hale gelmez. Bu iki seçeneğin doğru şekilde yapılandırılması, hem veri bütünlüğünün korunması hem de Always On mimarisinde Restore (Geri Yükleme) ve senkronizasyon sürecinin sorunsuz ilerlemesi açısından büyük önem taşır.

Server connections bölümü altında yer alan Close existing connections to destination database seçeneği, Restore (Geri Yükleme) işlemi başlatılmadan önce hedef Database (Veritabanı) üzerinde açık olan tüm aktif bağlantıların otomatik olarak kapatılmasını sağlar. Bu seçenek işaretlendiğinde, ilgili veritabanına bağlı olan kullanıcı oturumları ve uygulama bağlantıları sonlandırılır ve restore işleminin bağlantı kaynaklı hatalar nedeniyle başarısız olmasının önüne geçilir. Özellikle üretim ortamlarında, bakım veya planlı kesinti sırasında Restore (Geri Yükleme) yapılırken bu seçeneğin kullanılması önerilir. Microsoft SQL Server Always On Availability Group yapılarında, restore işlemi öncesinde hedef veritabanı üzerinde açık bağlantıların bulunmaması gereklidir. Bu nedenle, Secondary node üzerinde gerçekleştirilen restore işlemlerinde bu seçeneğin etkinleştirilmesi, işlemin sorunsuz tamamlanmasına katkı sağlar.

Prompt alanı altında yer alan Prompt before restoring each backup seçeneği, Restore (Geri Yükleme) işlemi sırasında birden fazla backup set bulunması durumunda, her bir yedek geri yüklenmeden önce kullanıcıdan onay alınmasını sağlar. Bu seçenek etkinleştirildiğinde, SQL Server her bir yedek adımı (örneğin Full, Differential veya Transaction Log) öncesinde işlemi durdurur ve kullanıcıya devam edip etmeyeceğini sorar. Böylece yanlış yedek setinin geri yüklenmesi engellenir ve restore süreci daha kontrollü bir şekilde ilerler. Özellikle manuel olarak yürütülen restore işlemlerinde, karmaşık yedekleme zincirlerinin bulunduğu ortamlarda veya Production (Kritik Üretim) veritabanları üzerinde yapılan Restore (Geri Yükleme) işlemlerinde bu seçenek ek bir güvenlik katmanı sağlar. Ancak otomatik ve hızlı restore gerektiren senaryolarda genellikle işaretlenmez. Microsoft SQL Server Always On Availability Group yapılandırmalarında, restore işlemleri çoğunlukla planlı ve sıralı olarak gerçekleştirildiğinden, bu seçenek isteğe bağlı olarak kullanılmakta olup genellikle kapalı bırakılır.

Restore Options menüsündeki ayarlarının doğru seçilmesi, Restore (Geri Yükleme) işleminin başarıyla tamamlanmasını sağlarken, Always On ve Cluster mimarilerinde Database Join ve senkronizasyon adımlarının sorunsuz ilerlemesine de doğrudan katkı sağlar.

Restore Database ekranında gerekli tüm yapılandırmaları tamamladıktan sonra OK seçeneğine tıklayarak NIHATCUBUKDB isimli Database (Veritabanı)’nin Restore (Geri Yükleme) işlemini başlatıyoruz.

Restore Database ekranında NIHATCUBUKDB isimli Database (Veritabanı) için başlatmış olduğumuz Restore (Geri Yükleme) işleminin sorunsuz bir şekilde tamamlandığını ve işlemin başarıyla sonuçlandığını doğruluyoruz.

Microsoft SQL Server Management Studio (SSMS) konsolunda Databases bölümü altında, NIHATCUBUKDB isimli Database (Veritabanı)’nin Restore (Geri Yükleme) işlemi sonrasında W25SQL25NOD1 isimli sunucumuz üzerine başarıyla geldiğini görüyoruz.

Bu aşama, veritabanına ait Data – .mdf (Master Data File) ve Log – .ldf (Log Data File) dosyalarının SQL Server tarafından doğru şekilde tanındığını, Restore (Geri Yükleme) işleminin hatasız tamamlandığını ve NIHATCUBUKDB isimli Database (Veritabanı)’in artık aktif olarak kullanılabilir durumda olduğunu gösterir. Bundan sonraki adımda, veritabanı durumunu (Online), yetkilendirmeleri (Database Owner / User Mapping) ve Always On gibi ileri seviye yapılandırmaları kontrol ederek ortam standartlarına uygunluğu doğrulayabilirsiniz.

Microsoft SQL Server Management Studio (SSMS) konsolu ile W25SQL25NOD2 isimli sunucumuz üzerine bağlantı sağlıyoruz.

Microsoft SQL Server Management Studio (SSMS) konsolunda Databases bölümü altında, NIHATCUBUKDB isimli Database (Veritabanı)’nin Restore (Geri Yükleme) işlemi sonrasında W25SQL25NOD2 isimli sunucumuz üzerinde listelenmediğini / bulunmadığını görüyoruz.

W25SQL25NOD1 isimli sunucumuz üzerinde NIHATCUBUKDB isimli Database (Veritabanı)’ni Restore (Geri Yükleme) işleminden sonra Microsoft SQL Server 2025 Always On Availability Group yapısına dahil etmeden önce bazı ön hazırlık adımlarını tamamlamamız gerekmektedir.

Öncelikle, NIHATCUBUKDB isimli Database (Veritabanı)’in Recovery model ayarının Full olarak yapılandırılması zorunludur. SQL Server Always On Availability Group, Full Recovery Model ile çalışan veritabanlarını destekler ve bu yapı, transaction log’ların eksiksiz tutulmasını sağlayarak High Availability (Yüksek Erişebilirlik) ve veri tutarlılığı sunar.

Eğer NIHATCUBUKDB isimli Database (Veritabanı)’in Recovery model ayarı Full olarak yapılandırılmazsa, New Availability Group Wizard içerisinde yer alan Select Databases ekranında Availability Group’a dahil etmek istediğimiz NIHATCUBUKDB isimli Database (Veritabanı)’in Status bölümünde Full recovery mode is required hatasını alırız. Bu durumda veritabanı SQL Server Always On Availability Group’a eklenemez.

Bu nedenle, SQL Server Always On Availability Group yapılandırmasına geçmeden önce NIHATCUBUKDB isimli Database (Veritabanı)’in Recovery model ayarının Full olduğunun doğrulanması ve gerekirse bu şekilde yapılandırılması kritik bir adımdır.

Select Databases ekranında NIHATCUBUKDB isimli veritabanını Microsoft SQL Server 2025 Always On Availability Group yapısına eklemek istediğimizde, Status sütununda Full recovery mode is required uyarısını görüyoruz. Bu uyarı, ilgili veritabanının Always On mimarisi için gerekli olan ön koşulları sağlamadığını göstermektedir.

SQL Server Always On Availability Group, veritabanları arasındaki senkronizasyonu Transaction Log üzerinden gerçekleştiren bir High Availability (Yüksek Erişilebilirlik) mimarisidir. Bu nedenle, sisteme dahil edilecek tüm veritabanlarının Recovery Model ayarının Full olması zorunludur. Simple veya Bulk-Logged recovery model ile çalışan veritabanları, işlem günlüklerini sürekli ve eksiksiz şekilde tutmadığı için Always On yapısına dahil edilemez.

Ekranda ayrıca açılan uyarı penceresinde, veritabanının Availability Group’a eklenebilmesi için Recovery Model ayarının Full olarak yapılandırılması gerektiği ve bu işlemden sonra mutlaka Full veya Differential Backup alınması gerektiği belirtilmektedir. Bunun yanı sıra, transaction log zincirinin korunabilmesi için düzenli Log Backup planlarının da aktif olması gerekir.

Özetle, NIHATCUBUKDB isimli Database (Veritabanı)’i Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edebilmek için önce Full Recovery Model yapılandırılmalı, ardından gerekli yedekleme işlemleri tamamlanmalıdır. Bu adımlar gerçekleştirilmeden veritabanı Always On ortamına eklenemez ve Select Databases ekranında seçim yapılamaz.

NIHATCUBUKDB isimli Database (Veritabanı)’nı Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edebilmek için, Recovery Model ayarının Full olarak yapılandırılmasının ardından mutlaka Full Backup alınması gerekmektedir.

Always On mimarisinde, veritabanının SQL Server Always On Availability Group’a eklenebilmesi için SQL Server, mevcut bir Full Backup’ın bulunmasını zorunlu kılar. Bunun nedeni, replikalar arasında başlatılacak olan senkronizasyon sürecinin sağlam ve tutarlı bir backup zinciri üzerinden ilerlemesini sağlamaktır.

Eğer NIHATCUBUKDB isimli Database (Veritabanı)’i üzerinde Full Backup alınmazsa, New Availability Group Wizard içerisindeki Select Databases ekranında ilgili veritabanının Status bölümünde Full backup is required hatası ile karşılaşılır. Bu hata nedeniyle veritabanı seçilemez ve Availability Group’a ekleme işlemi gerçekleştirilemez.

Özetle, NIHATCUBUKDB isimli Database (Veritabanı)’i Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edebilmek için şu adımların eksiksiz tamamlanması gerekir:

Recovery Model ayarının Full olarak yapılandırılması
Veritabanı üzerinde en az bir adet Full Backup alınması
Bu işlemler tamamlandıktan sonra, Select Databases ekranında veritabanı hatasız şekilde listelenecek ve SQL Server Always On Availability Group’a dahil edilebilir hale gelecektir.

Select Databases ekranında NIHATCUBUKDB isimli veritabanını Microsoft SQL Server 2025 Always On Availability Group yapısına eklemek istediğimizde, Status bölümünde Full backup is required uyarısını görüyoruz. Bu uyarı, ilgili veritabanı için henüz Full Database Backup alınmadığını ifade etmektedir.

SQL Server Always On Availability Group mimarisinde, bir veritabanının yapıya dahil edilebilmesi için Full Recovery Model kullanılması tek başına yeterli değildir. SQL Server, replikalar arasında veri senkronizasyonunu başlatabilmek için mutlaka geçerli bir Full Backup’ın mevcut olmasını bekler. Bu backup, Availability Group için başlangıç referansı (baseline) olarak kullanılır.

Ekranda açılan uyarı penceresinde de belirtildiği üzere, This database lacks a full database backup mesajı, veritabanının henüz tam yedeğinin alınmadığını açıkça belirtir. Bu nedenle NIHATCUBUKDB isimli Database (Veritabanı) seçilemez ve Availability Group’a ekleme işlemi devam ettirilemez.

Bu hatanın giderilebilmesi için, NIHATCUBUKDB isimli Database (Veritabanı)’i üzerinde en az bir adet Full Database Backup alınması gerekir. Full backup işlemi tamamlandıktan sonra Select Databases ekranı yenilendiğinde, ilgili veritabanının Status bölümünün hatasız hale geldiği ve Availability Group’a dahil edilebilir olduğu görülecektir.

Özetle, Microsoft SQL Server 2025 Always On Availability Group yapısında bir veritabanını Availability Group’a ekleyebilmek için şu koşulların birlikte sağlanması zorunludur:

Recovery Model ayarının Full olması
Veritabanı üzerinde en az bir adet Full Backup alınmış olması
Bu gereksinimler, Always On mimarisinin veri tutarlılığı ve High Availability (Yüksek Erişilebilirlik) prensiplerinin temelini oluşturmaktadır.

Select Databases ekranında Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database (Veritabanı)’nin Status bölümünde Meets prerequisites ifadesini görüyoruz.

Bu durum, NIHATCUBUKDB isimli Database (Veritabanı) için Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edilebilmesi adına gerekli tüm ön koşulların eksiksiz olarak sağlandığını gösterir. Başka bir ifadeyle, Recovery Model ayarı Full olarak yapılandırılmış, Full Backup (Tam Yedek) alınmış ve veritabanı Always On yapısına eklenmeye hazır hale gelmiştir.

Bu aşamadan sonra NIHATCUBUKDB isimli Database (Veritabanı)’ni seçerek Availability Group yapısına güvenle dahil edebilir ve yapılandırma adımlarına sorunsuz şekilde devam edebiliriz.

Add Database to Availability Group Wizard içerisinde yer alan Select Databases ekranında NIHATCUBUKDB isimli Database (Veritabanı)’nin Status bölümünde Meets prerequisites ifadesini görüyoruz.

Bu ifade, NIHATCUBUKDB isimli Database (Veritabanı)’i için Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edilebilmesi adına gerekli olan tüm ön koşulların eksiksiz olarak sağlandığını göstermektedir. Bu kapsamda;

Recovery Model ayarının Full olarak yapılandırıldığı,
Veritabanı üzerinde en az bir adet Full Backup (Tam Yedek) alındığı,
Veritabanının çevrimiçi (Online) ve erişilebilir durumda olduğu,

SQL Server tarafından doğrulanmış olur.

Ekranda açılan bilgilendirme penceresinde de belirtildiği üzere, This database meets the availability-database prerequisites mesajı, veritabanının Availability Group’a eklenmeye hazır olduğunu açıkça ifade etmektedir.

Bu aşamadan sonra NIHATCUBUKDB isimli veritabanını seçerek Next seçeneği ile devam edebilir ve veritabanını Microsoft SQL Server 2025 Always On Availability Group yapısına sorunsuz bir şekilde dahil edebiliriz.

Bu ekran, SQL Server Always On Availability Group yapılandırmasında en kritik eşiklerden biridir ve veritabanının mimariye teknik olarak uygunluğunun SQL Server tarafından onaylandığını gösterir.

Microsoft SQL Server Management Studio (SSMS) konsolunda Databases bölümü altında yer alan NIHATCUBUKDB isimli Database (Veritabanı) üzerinde sağ tuşa tıklayarak Properties seçeneğine tıklıyoruz.

Database Properties – NIHATCUBUKDB ekranın geliyor karşımıza.

Database Properties – NIHATCUBUKDB ekranında sol menüde yer alan Options seçeneğine tıklıyoruz.

Database Properties – NIHATCUBUKDB ekranda NIHATCUBUKDB isimli Database (Veritabanı) ait Recovery Model, Auto Close, Auto Shrink, Compatibility Level gibi SQL Server Always On Availability Group yapılandırması açısından kritik olan seçenekleri görüntüleyebilir ve gerekli yapılandırmaları gerçekleştirebiliriz.

Database Properties – NIHATCUBUKDB ekranında Options sekmesine geldiğimizde, Recovery model ayarının Simple olarak yapılandırıldığını görüyoruz.

Ancak NIHATCUBUKDB isimli Database (Veritabanı)’nı Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edebilmek için Recovery model ayarının mutlaka Full olarak yapılandırılması gerekmektedir. Always On mimarisi, transaction log zinciri üzerinden çalıştığı için Simple Recovery Model ile yapılandırılmış veritabanları bu yapıya dahil edilemez.

Bu nedenle, SQL Server Always On Availability Group yapılandırmasına devam edebilmek için Recovery model ayarını Simple’dan Full’a çevirerek gerekli yapılandırmayı yapmamız gerekir.

Recovery model bölümünde Full, Simple ve Bulk-Logged olmak üzere üç farklı seçenek bulunmaktadır. Bu modeller, SQL Server’da transaction log yönetiminin nasıl yapılacağını ve olası bir felaket durumunda verinin ne kadar geri döndürülebileceğini belirler.

Full: Full Recovery Model’de yapılan tüm işlemler transaction log dosyasına eksiksiz olarak kaydedilir ve manuel müdahale edilmedikçe silinmez. Bu sayede veritabanı, istenilen herhangi bir zamana kadar geri döndürülebilir. Bu model, SQL Server’da en güvenilir recovery model olarak kabul edilir ve özellikle SQL Server Always On Availability Group, Log Shipping ve kritik Production sistemleri için zorunludur.

Ancak Full Recovery Model’de transaction log yönetimi manuel yapılır. Bu nedenle transaction log dosyalarının kontrolsüz şekilde büyümemesi için düzenli olarak işlem yapılmalıdır. SQL Server’da transaction log temizliği için iki temel yöntem vardır:

Transaction Log Backup almak
Transaction Log Shrink işlemi yapmak

SQL Server 2005 ve sonrası sürümlerde, transaction log shrink işlemi uygulanacaksa, veritabanının Recovery Model’i geçici olarak Simple yapılmalı, shrink işlemi tamamlandıktan sonra tekrar Full olarak ayarlanmalıdır. Full Recovery Model’de INSERT, DELETE, UPDATE gibi DML işlemlerinin yanı sıra; Index oluşturma, Index Rebuild, BCP, Bulk Insert gibi bakım ve toplu işlemler de transaction log’a detaylı şekilde yazılır. Bu durum transaction log dosyasının hızla büyümesine ve işlemlerin bir miktar yavaşlamasına neden olabilir.

Bulk-Logged: Bulk-Logged Recovery Model, Full Recovery Model’e benzer şekilde çalışır; ancak bulk işlemler sırasında önemli bir fark ortaya çıkar. Bulk işlemler esnasında yapılan tüm işlemler tek tek loglanmaz, bunun yerine tek bir kayıt transaction log’a yazılır. Bu sayede bulk işlemler, Full Recovery Model’e kıyasla daha hızlı gerçekleştirilir ve transaction log büyümesi daha kontrollü olur. Ancak bu modelde, bulk işlem yapılan zaman aralığına point-in-time restore yapmak mümkün değildir.

Bu nedenle Bulk-Logged Recovery Model, Production ortamları için kalıcı bir çözüm değildir. Ancak yaygın bir kullanım senaryosu şu şekildedir:

Bulk işlem öncesinde Transaction Log Backup alınır
Recovery Model geçici olarak Bulk-Logged yapılır
Bulk işlem tamamlanır
Recovery Model tekrar Full olarak ayarlanır

Bu yaklaşım sayesinde hem performans kazanılır hem de veri güvenliği korunur. Bu nedenle Bulk-Logged Recovery Model’i geçici olarak tercih edilen bir recovery model olarak tanımlamak yanlış olmaz.

Simple: Simple Recovery Model’de çalışan veritabanlarında, transaction log kayıtları Checkpoint işlemi sonrasında otomatik olarak temizlenir. Bu nedenle transaction log dosyasının sürekli büyümesi söz konusu değildir ve log yönetimi oldukça kolaydır. Burada sıkça yanlış anlaşılan önemli bir noktaya değinmek gerekir. Simple Recovery Model dahil olmak üzere tüm recovery modellerinde transaction log tutulur. Ancak Simple Recovery Model’de bu loglar, checkpoint işleminden sonra otomatik olarak silinir. Simple Recovery Model’in en büyük dezavantajı, transaction log backup alınamamasıdır. Bu nedenle point-in-time restore (belirli bir zamana geri dönüş) mümkün değildir. Olası bir felaket durumunda, en iyi ihtimalle yalnızca en son alınan Full veya Differential Backup’a kadar geri dönülebilir. Bu da ciddi veri kaybı riskine yol açar.

Bu sebeple Simple Recovery Model, Production ortamlarında kesinlikle önerilmez.

Database Properties – NIHATCUBUKDB ekranında Options sekmesi altında yer alan Recovery model bölümünden Full seçeneğini seçiyoruz.

Database Properties – NIHATCUBUKDB ekranında Options sekmesinde gerekli yapılandırmayı tamamladıktan sonra OK diyerek ayarları kaydediyoruz.

Bu işlem ile NIHATCUBUKDB isimli Database (Veritabanı), Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edilebilmesi için gerekli olan Full Recovery Model ile yapılandırılmış olur.

Microsoft SQL Server Management Studio (SSMS) konsolunda, Databases bölümü altında yer alan NIHATCUBUKDB isimli Database (Veritabanı) üzerinde sağ tuş Tasks menüsüne giriyoruz ve Back Up… seçeneğine tıklıyoruz.

Bu adım ile Microsoft SQL Server 2025 Always On Availability Group yapılandırmasına NIHATCUBUKDB isimli Database (Veritabanı)’ni ekleyebilmek için gerekli olan Full Backup (Tam Yedek) işlemini başlatmış oluyoruz.

Back Up Database – BAKICUBUKDB ekranında Backup Type bölümünü Full olarak seçiyoruz. Ardından Destination alanında yer alan Back up to seçeneğini Disk olarak belirliyoruz. Bu yapılandırma ile veritabanının Full Backup (Tam Yedek) işleminin disk üzerine alınacağını belirtmiş oluyoruz.

Destination bölümünde, yedekleme işleminin gerçekleştirileceği dizinin H:\BACKUP olarak yapılandırıldığını görüyoruz. Bu dizin, Microsoft SQL Server 2025 Always On Availability Group kurulumu sırasında daha önce belirlemiş olduğumuz varsayılan Backup klasörüdür.

Gerekli kontrolleri tamamladıktan sonra, Back Up Database – BAKICUBUKDB ekranında OK seçeneğine tıklayarak Full Backup (Tam Yedek) alma işlemini başlatıyoruz.

BAKICUBUKDB isimli Database (Veritabanı) üzerinde Full Backup (Tam Yedek) işleminin başarıyla tamamlandığını görüyoruz.

Full Backup (Tam Yedek) işlemin sorunsuz şekilde tamamlanmasının ardından OK seçeneğine tıklayarak Back Up Database – BAKICUBUKDB ekranını kapatıyoruz.

Microsoft SQL Server Management Studio (SSMS) konsolunda Databases bölümü altında NIHATCUBUKDB isimli Database (Veritabanı)’nin durumunun Online olduğunu görüyoruz.

Ancak NIHATCUBUKDB isimli Database (Veritabanı)’nin Synchronized durumuna geçebilmesi için, ilgili veritabanının Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edilmesi gerekmektedir. Veritabanı SQL Server Always On Availability Group içerisine eklendiğinde, Primary ve Secondary replikalar arasında veri eşitleme (synchronization) süreci başlayacak ve senkronizasyon başarıyla tamamlandığında veritabanı durumu Synchronized olarak görüntülenecektir.

Microsoft SQL Server Management Studio (SSMS) konsolunda Always On High Availability bölümü altında yer alan Availability Groups kısmında, SQL25HAG ismi ile yapılandırmış olduğumuz Availability Group yapısını görüyoruz.

Bu yapı altında bulunan Availability Databases bölümünde, BAKICUBUKDB isimli Database (Veritabanı)’nın ilgili Availability Group içerisinde yer aldığını görüyoruz. Ancak NIHATCUBUKDB isimli Database (Veritabanı) henüz bu Availability Group yapısına dahil edilmediği için Availability Databases listesinde görünmemektedir. Bu nedenle NIHATCUBUKDB isimli Database (Veritabanı) için senkronizasyon (Synchronized) durumu da henüz oluşmamıştır.

Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database (Veritabanı) için gerekli tüm ön hazırlıkları tamamladık. Bu kapsamda, veritabanının Recovery Model ayarını Full olarak yapılandırdık ve ardından Full Backup (Tam Yedek) işlemini aldık.

Bu adımların tamamlanmasıyla birlikte NIHATCUBUKDB isimli Database (Veritabanı), artık Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edilmeye hazır hale gelmiştir.

Bu işlem için Microsoft SQL Server Management Studio (SSMS) konsolunu açıyoruz. Always On High Availability bölümü altında yer alan Availability Groups üzerinde sağ tuşa tıklayarak Add Database seçeneğini seçiyoruz.

Bu adım ile Add Database to Availability Group Wizard başlatılır ve veritabanını Availability Group yapısına ekleme sürecine geçilmiş olur.

Add Database to Availability Group Wizard başlatıldığında ilk olarak Introduction ekranı karşımıza gelir.

Introduction ekranıında mevcut bir Availability Group yapısına yeni bir veritabanı ekleme süreci hakkında genel bilgilendirme sunar.

Introduction ekranında bu sihirbazın mevcut Availability Group yapısına bir veya birden fazla availability database eklemek için kullanılacağı belirtilmektedir. Ayrıca veritabanını Availability Group’a ekleyebilmek için izlenecek temel adımlar özetlenir. Bu adımlar arasında; SQL Server instance üzerindeki uygun veritabanının seçilmesi, başlangıç veri senkronizasyon yönteminin belirlenmesi, varsa secondary replica’lara bağlantı sağlanması, doğrulama kontrollerinin yapılması ve son olarak yapılandırma özetinin gözden geçirilmesi yer alır.

Introduction ekranı yalnızca bilgilendirme amaçlıdır ve herhangi bir yapılandırma işlemi içermez. NIHATCUBUKDB isimli Database (Veritabanı) için gerekli tüm ön koşullar (Full Recovery Model ve Full Backup) sağlandığı için, bu aşamada Next seçeneğine tıklayarak Select Databases adımına geçebiliriz.

Select Databases ekranında Availability Group yapısına dahil edeceğimiz Database (Veritabanı)’nı seçmemiz gerekmektedir. Select Databases ekranında SQL Server instance üzerinde bulunan tüm kullanıcı veritabanları listelenir ve her bir veritabanının Availability Group’a uygunluk durumu Status sütununda görüntülenir.

Daha önce Availability Group yapısına dahil ettiğimiz BAKICUBUK isimli Database (Veritabanı) Status bölümünde Already part of this availability group olarak görüyoruz. Bu ifade, ilgili veritabanlarının halihazırda SQL Server Always On Availability Group üyesi olduğunu ve yeniden eklenemeyeceğini gösterir.

Availability Group yapısına eklemek istediğimiz NIHATCUBUK isimli Database (Veritabanı) ise Status bölümünde Meets prerequisites olarak görünmektedir. Bu durum, veritabanının SQL Server Always On Availability Group yapısı için gerekli tüm ön koşulları sağladığını ve eklenmeye hazır olduğunu ifade eder.

Eğer bir Database (Veritabanı) üzerinde Full Backup alınmamışsa, Status bölümünde Full backup is required uyarısı görüntülenir. Bu durumda ilgili veritabanı seçilemez ve Availability Group yapısına dahil edilemez. Hatanın giderilmesi için veritabanı üzerinde Full Backup (Tam Yedek) alınması gerekmektedir.

Benzer şekilde, Status bölümünde Full recovery mode is required hatası görülüyorsa, ilgili veritabanının Recovery Model ayarı Full olarak yapılandırılmamıştır. Bu durumda Database Properties → Options bölümünden Recovery Model ayarı Full olacak şekilde değiştirilmelidir.

Select Databases ekranında Availability Group’a eklenecek bir veritabanının Status bölümünde mutlaka Meets prerequisites ifadesinin yer alması gerekmektedir. Aksi durumda, ilgili hata mesajına göre Recovery Model veya Full Backup işlemleri tamamlanmadan veritabanı Availability Group yapısına eklenemez.

Bu ifade, NIHATCUBUKDB isimli Database (Veritabanı) için Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edilebilmesi adına gerekli olan tüm ön koşulların eksiksiz olarak sağlandığını göstermektedir. Bu kapsamda;

Recovery Model ayarının Full olarak yapılandırıldığı,
Veritabanı üzerinde en az bir adet Full Backup (Tam Yedek) alındığı,
Veritabanının çevrimiçi (Online) ve erişilebilir durumda olduğu,

SQL Server tarafından doğrulanmış olur.

Bu aşamadan sonra NIHATCUBUKDB isimli Database (Veritabanı) seçerek Next seçeneği ile devam edebilir ve veritabanını Availability Group yapısına sorunsuz bir şekilde dahil edebiliriz.

Select Databases ekranında Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database (Veritabanı)’ni seçiyoruz.

Status bölümünde Meets prerequisites olarak görüntülenen NIHATCUBUKDB isimli Database (Veritabanı)’i işaretledikten sonra Next seçeneğine tıklayarak bir sonraki adıma geçiyoruz. Bu işlem ile veritabanını Availability Group yapısına ekleme sürecinde bir sonraki yapılandırma ekranına ilerlemiş oluyoruz.

Connect to Existing Secondary Replicas ekranında Microsoft SQL Server 2025 Always On Availability Group yapısında Secondary Replica olarak yapılandıracağımız W25SQL25NOD2 isimli sunucumuza bağlantı sağlamamız gerekmektedir.

Connect to Existing Secondary Replicas ekranında Availability Group yapısına dahil olan mevcut secondary replica sunucular listelenir. W25SQL25NOD2 sunucusu için ilgili satırda yer alan Connect seçeneğine tıklayarak, Microsoft SQL Server 2025 Always On Availability Group yapısına bu sunucu üzerinden bağlantı kurabiliriz.

Eğer ortamda birden fazla secondary replica bulunuyorsa, Connect All seçeneğini kullanarak Microsoft SQL Server 2025 Always On Availability Group yapısındaki tüm secondary sunuculara tek seferde bağlantı sağlamak mümkündür. Bu adım, veritabanının secondary replica’lara doğru şekilde kopyalanması ve senkronizasyon sürecinin sorunsuz ilerlemesi açısından kritik öneme sahiptir.

Connect to Existing Secondary Replicas ekranında Secondary Replica olarak yapılandıracağımız W25SQL25NOD2 isimli sunucumuz için ilgili satırda yer alan Connect seçeneğine tıklayarak bağlantı sağlıyoruz.

Bu işlem ile Microsoft SQL Server 2025 Always On Availability Group yapısında, W25SQL25NOD2 sunucusu secondary replica olarak sürece dahil edilir ve bir sonraki adımda veritabanının bu sunucuya senkronize edilmesi için gerekli yapılandırmalara geçilmiş olur.

Connect to Server ekranında Server name bölümünde W25SQL25NOD2 bilgisinin otomatik olarak geldiğini görüyoruz.

Connect to Server ekranında gerekli kontrolleri yaptıktan sonra Connect seçeneğine tıklayarak W25SQL25NOD2 isimli sunucuya bağlantı sağlıyoruz. Bu işlem ile Microsoft SQL Server 2025 Always On Availability Group yapısında Secondary Replica olarak yapılandırılacak olan sunucuya başarıyla bağlanmış oluyoruz.

Connect to Existing Secondary Replicas ekranında Secondary Replica olarak yapılandırdığımız W25SQL25NOD2 isimli sunucumuza bağlantıyı başarıyla sağladıktan sonra Next seçeneğine tıklayarak bir sonraki adıma geçiyoruz.

Bu adım ile, Microsoft SQL Server 2025 Always On Availability Group yapısında yer alacak secondary replica sunucular için gerekli bağlantılar tamamlanmış olur ve yapılandırma sürecine devam edilir.

Select Initial Data Synchronization ekranında Availability Group yapısında Secondary sunucuya veritabanlarının ilk kez nasıl senkronize edileceğinin belirlendiği adımdır. Select Initial Data Synchronization ekranında verinin Secondary replika üzerine hangi yöntemle aktarılacağı seçilir.

Automatic seeding seçeneği tercih edildiğinde, Secondary sunucuya veritabanı senkronizasyonu için gerekli tüm işlemler otomatik olarak gerçekleştirilir. Bu yöntemde ek bir paylaşım alanına veya manuel bir işleme ihtiyaç duyulmaz ve yapılandırma süreci hızlı şekilde tamamlanır.
Full database and log backup seçeneği ile devam edildiğinde ise, her bir veritabanının Full Backup ve Transaction Log Backup dosyaları, önceden yapılandırılmış bir Share (Paylaşım) üzerinden alınarak Secondary sunucuya otomatik olarak aktarılır. Bu yöntemin çalışabilmesi için SQL Server servis hesaplarının ilgili paylaşım üzerinde Read (Okuma) ve Write (Yazma) yetkilerine sahip olması gerekir. Ayrıca, paylaşım alanında veritabanı yedeklerinin sığabileceği yeterli disk alanı bulunmalıdır.
Specify the file share path in Windows format: Availability Group yapılandırması sırasında Full database and log backup yöntemi seçildiğinde kullanılan ekrandır. Bu alanda, Primary ve Secondary sunucular tarafından erişilebilen bir Windows File Share (UNC Path) tanımlanır (örneğin \\SERVERNAME\SQLBackup). Belirtilen paylaşım yolu, Full Backup ve Transaction Log Backup dosyalarının geçici olarak oluşturulacağı ve Secondary sunucuya aktarılacağı konumdur. Paylaşım üzerinde, her iki sunucudaki SQL Server Service Account’larının Read (Okuma) ve Write (Yazma) yetkilerine sahip olması ve paylaşım alanında yedek dosyaları için yeterli disk alanının bulunması gerekmektedir.

Specify the file share location in Linux format bölümü altında yer alan senkronizasyon seçenekleri:

Join only seçeneğinde, Availability Group’a eklenecek her bir veritabanı için Full Backup ve Transaction Log Backup işlemlerinin manuel olarak alınmış olması gerekir. Bu yedeklerin, bu adıma geçilmeden önce manuel olarak Secondary sunucuya kopyalanmış ve veritabanlarının RESTORING durumunda hazır hale getirilmiş olması zorunludur.
Skip initial data synchronization seçeneğinde ise, yine veritabanlarının Full Backup ve Transaction Log Backup işlemleri manuel olarak alınır ve Secondary sunucuya manuel olarak kopyalanır. Ancak Join only seçeneğinden farklı olarak, bu işlemlerin daha sonra yapılmasına izin verilir. Bu yöntem, ilk kurulum sırasında senkronizasyonu ertelemek isteyen ortamlarda tercih edilir.

Select Initial Data Synchronization ekranında Secondary sunucu üzerine veritabanı senkronizasyonunun otomatik olarak gerçekleştirilmesi için Automatic seeding seçeneğini seçiyoruz.

Automatic seeding seçeneğini ile, veritabanlarının Primary Replica üzerinden Secondary Replica’lara ilk senkronizasyonu SQL Server tarafından otomatik olarak yapılacaktır. Herhangi bir File Share tanımlamasına veya manuel backup / restore işlemine ihtiyaç duyulmadan yapılandırma süreci hızlı ve pratik şekilde ilerler.

Select Initial Data Synchronization ekranında gerekli yapılandırmayı tamamladıktan sonra Next seçeneğine tıklayarak bir sonraki adıma geçiyoruz.

Validation ekranında NIHATCUBUKDB isimli Database (Veritabanı)’nı Availability Group yapısına dahil edebilmek için gerekli olan tüm kontrollerin otomatik olarak yapıldığını görüyoruz.

Validation ekranında gerçekleştirilen her bir kontrol adımının durumu listelenir ve NIHATCUBUKDB isimli Database (Veritabanı)’nı için tüm adımların Status bölümünde Success olarak sonuçlandığı görülür. Bu durum, yapılandırmada herhangi bir hata veya eksiklik olmadığını ve işlemin sorunsuz şekilde ilerleyebileceğini gösterir.

Eğer herhangi bir aşamada bir problem tespit edilseydi, ilgili adım Error olarak görüntülenirdi. Bu durumda Previous seçeneğini kullanarak önceki adımlara geri dönülebilir, hatalı yapılandırma düzeltildikten sonra Re-run validation seçeneği ile kontroller yeniden çalıştırılabilirdi.

Validation ekranında NIHATCUBUKDB isimli Database (Veritabanı)’in Availability Group yapısına dahil etmeye engel herhangi bir sorun bulunmadığı için Next seçeneğine tıklayarak bir sonraki adıma geçiyoruz.

Summary ekranında NIHATCUBUKDB isimli Database (Veritabanı)’nı Availability Group yapısına dahil etmek için gerçekleştirilen tüm yapılandırmaların bir özetini görüyoruz. Summary ekranında seçilen NIHATCUBUKDB isimli Database (Veritabanı)’nı, secondary replica’lar, senkronizasyon yöntemi (Automatic seeding) ve diğer ilgili ayarlar toplu olarak listelenir.

Summary ekranında yapılandırma özetini kontrol ettikten sonra Finish seçeneğine tıklayarak NIHATCUBUKDB isimli Database (Veritabanı)’in Availability Group yapısına dahil etme işlemini başlatıyoruz.

Summary ekranında ayrıca Script bölümü sayesinde, Availability Group’a veritabanı eklemek için yapılan tüm yapılandırmaları Script (Senaryo) olarak oluşturabilir ve kaydedebilirsiniz. Bu özellik; Dokümantasyon, Denetim (Audit) ve benzer ortamlar için tekrar kullanılabilir kurulumlar açısından önemli bir avantaj sağlar.

Results ekranında Adding databases to availability group ‘SQL25HAG’ ifadesini görüyoruz. Bu ekran, seçmiş olduğumuz NIHATCUBUKDB isimli Database (Veritabanı)’nın Microsoft SQL Server 2025 Always On Availability Group yapısına başarıyla eklendiğini göstermektedir.

Bu aşamada NIHATCUBUKDB isimli Database (Veritabanı), Availability Group içerisine dahil edilmiş olup primary ve secondary replikalar arasında veri senkronizasyon süreci başlatılmıştır. Senkronizasyon işlemi başarıyla tamamlandığında, veritabanının durumu Synchronized olarak görüntülenecek ve Availability Group → Availability Databases bölümü altında yer alacaktır.

Results ekranında gerçekleştirilen işlemin sonucunu özetleyen ve herhangi bir hata oluşup oluşmadığını gösteren son kontrol adımıdır. Bu ekranın sorunsuz şekilde tamamlanması, veritabanının Availability Group mimarisine başarılı bir şekilde entegre edildiğini doğrular.

Microsoft SQL Server Management Studio (SSMS) konsolunda Databases bölümü altında NIHATCUBUKDB isimli Database (Veritabanı)’nin başarıyla listelendiğini görüyoruz.

Ayrıca Database (Veritabanı) adının yanında NIHATCUBUKDB (Synchronized) ifadesinin yer aldığını fark ediyoruz. Bu durum, NIHATCUBUKDB isimli Database (Veritabanı)’nin Microsoft SQL Server 2025 Always On Availability Group yapısı içerisinde Primary ve Secondary replica’lar arasında senkronizasyonun başarıyla tamamlandığını ve verinin tutarlı bir şekilde eşitlendiğini gösterir.

Bu aşama, veritabanının Availability Group mimarisi içerisinde sağlıklı, aktif ve High Availability (Yüksek Erişilebilirlik) prensiplerine uygun şekilde çalıştığını doğrulayan en önemli göstergelerden biridir.

Microsoft SQL Server Management Studio (SSMS) konsolunda Always On High Availability bölümü altında yer alan Availability Groups kısmına geldiğimizde, SQL25HAG ismiyle yapılandırmış olduğumuz Availability Group yapısını görüyoruz.

İlgili Availability Group’u genişlettiğimizde, Availability Databases bölümü altında NIHATCUBUKDB isimli Database (Veritabanı)’nin başarıyla eklendiğini görüyoruz.

Bu görünüm, NIHATCUBUKDB isimli Database (Veritabanı)’nin SQL25HAG isimli Availability Group yapısına sorunsuz bir şekilde dahil edildiğini ve Always On mimarisi içerisinde aktif ve sağlıklı olarak çalıştığını doğrulamaktadır.

Microsoft SQL Server Management Studio (SSMS) konsolunda konsolunda Always On High Availability bölümü altında yer alan Availability Groups kısmına geldiğimizde, SQL25HAG ismiyle yapılandırmış olduğumuz Availability Group yapısını görüyoruz.

İlgili Availability Group’u genişlettiğimizde, Availability Databases bölümü altında NIHATCUBUKDB isimli Database (Veritabanı)’nin başarıyla eklendiğini görüyoruz.

Başka bir yazımızda görüşmek dileğiyle…