SQL Server yedeklemesi neden ayrı bir konu?
Dosya yedeklemede klasörü kopyalamak çoğu zaman yeterlidir. SQL Server veritabanlarında ise durum farklıdır: SQL Server çalışırken .mdf ve .ldf dosyalarını doğrudan kopyalamak tutarlı bir yedek vermeyebilir. Dosyalar kilitlidir, yazma işlemleri sürer ve kopyalanan dosya, farklı anlardan alınmış parçaların bozuk bir karışımı olabilir.
Doğru yöntem, SQL Server'ın kendi yedekleme mekanizmasını (BACKUP DATABASE) kullanmaktır. Bu komut, veritabanını tutarlı bir anlık görüntü olarak, çalışırken, .bak uzantılı bir yedek dosyasına yazar.
Çalışan bir SQL Server'ın veri dosyalarını elle kopyalamak yedek değildir. Yedeklemeyi her zaman SQL Server'ın kendi yedekleme komutlarıyla yapın.
Üç yedek türü
| Tür | İçeriği | Geri yüklemede |
|---|---|---|
| Tam (Full) | Veritabanının tamamı | Her geri yüklemenin başlangıç noktası |
| Fark (Differential) | Son tam yedekten bu yana değişen veri sayfaları | Tam yedekle birlikte uygulanır |
| İşlem günlüğü (Transaction log) | Son log yedeğinden bu yana yapılan tüm işlemler | Belirli bir ana kadar geri dönmeyi sağlar |
Kurtarma modelleri (Recovery Model)
Hangi yedek türlerini alabileceğinizi veritabanının kurtarma modeli belirler:
| Model | Log yedeği | Ne zaman? |
|---|---|---|
| Simple | Alınamaz | Kayıp verinin önemli olmadığı test/geliştirme veritabanları. Yalnızca son tam/fark yedeğine dönülebilir. |
| Full | Alınır | Kritik üretim veritabanları (ERP, muhasebe). Belirli bir ana kadar geri dönüş mümkündür. |
| Bulk-logged | Alınır | Toplu veri yükleme dönemlerinde geçici olarak kullanılan özel bir model. |
Sık yapılan hata: Veritabanı Full modelde, ama log yedeği alınmıyor. Bu durumda işlem günlüğü dosyası sürekli büyür ve diski doldurabilir. Full model kullanıyorsanız log yedeklerini mutlaka zamanlayın.
Temel yedekleme komutları
Aşağıdaki komutlar örnektir. Veritabanı adını ve yolları kendi ortamınıza göre değiştirin.
BACKUP DATABASE [ERP] TO DISK = N'D:\Yedek\ERP_Tam.bak' WITH COMPRESSION, CHECKSUM, INIT, NAME = N'ERP Tam Yedek';
BACKUP DATABASE [ERP] TO DISK = N'D:\Yedek\ERP_Fark.bak' WITH DIFFERENTIAL, COMPRESSION, CHECKSUM, INIT;
BACKUP LOG [ERP] TO DISK = N'D:\Yedek\ERP_Log.trn' WITH COMPRESSION, CHECKSUM;
CHECKSUM: Yedek sırasında sayfaların bütünlüğünü doğrular.COMPRESSION: Yedeği sıkıştırır; alan ve süre kazandırır. SQL Server sürümüne ve edisyonuna göre desteği değişebilir.INIT: Aynı dosyanın üzerine yazar. Her çalışmada benzersiz dosya adı kullanmak (tarih/saat ile) geçmişi korur.
Belirli bir ana geri dönmek (Point-in-time Restore)
Full kurtarma modeli ve düzenli log yedekleri, veritabanını belirli bir ana geri döndürme imkânı verir. Örneğin yanlış bir DELETE komutu 14:32'de çalıştırıldıysa, veritabanını 14:31'e dönecek şekilde geri yükleyebilirsiniz. Bunun için son tam yedek, varsa son fark yedeği ve o ana kadarki tüm log yedekleri sırayla uygulanır.
Kırmızı çizgi seçtiğiniz geri dönüş noktasıdır. Tam yedek, fark yedeği ve çizgiye kadarki log yedekleri sırayla uygulanır.
-- 1) Tam yedek: veritabanı henüz açılmaz RESTORE DATABASE [ERP_Test] FROM DISK = N'D:\Yedek\ERP_Tam.bak' WITH NORECOVERY, REPLACE; -- 2) Fark yedeği RESTORE DATABASE [ERP_Test] FROM DISK = N'D:\Yedek\ERP_Fark.bak' WITH NORECOVERY; -- 3) Log yedeği, belirli bir ana kadar; sonra veritabanı açılır RESTORE LOG [ERP_Test] FROM DISK = N'D:\Yedek\ERP_Log.trn' WITH STOPAT = '2026-10-15 14:31:00', RECOVERY;
Geri yüklemeyi önce farklı bir ada (ör. ERP_Test) yapın. Böylece canlı veritabanınızı riske atmadan içeriği kontrol edebilirsiniz. Dosya yolları farklıysa MOVE seçeneği gerekebilir.
Yedeğin işe yaradığını nasıl doğrularsınız?
- CHECKSUM ile yedek alın. Bozuk sayfaları yedek sırasında yakalar.
- RESTORE VERIFYONLY ile okunabilirliği kontrol edin. Bu komut yedek dosyasının okunabilir olduğunu doğrular; ancak gerçek bir geri yüklemenin yerine geçmez.
- Düzenli test geri yüklemesi yapın. Yedeği ayrı bir sunucuya ya da farklı bir veritabanı adına geri yükleyin ve verileri kontrol edin.
- DBCC CHECKDB çalıştırın. Veritabanındaki bozulma, yedeğe de yansır; bozulmayı erken fark etmek için bütünlük kontrolünü zamanlayın.
RESTORE VERIFYONLY FROM DISK = N'D:\Yedek\ERP_Tam.bak' WITH CHECKSUM;
Örnek zamanlama
Doğru sıklık, kabul edebileceğiniz veri kaybına (RPO) bağlıdır. Kritik bir muhasebe ya da ERP veritabanı için sık kullanılan bir şablon:
| Yedek | Sıklık (örnek) | Amaç |
|---|---|---|
| Tam | Haftada bir (hafta sonu gecesi) | Geri yüklemenin temeli |
| Fark | Her gece | Geri yükleme zincirini kısa tutmak |
| Log | 15-60 dakikada bir (RPO'ya göre) | Veri kaybını dakikalara indirmek |
Log yedeği almıyorsanız (Simple model ya da yalnızca tam/fark), olası veri kaybınız son yedekten bu yana geçen süredir.
Unutulan ayrıntılar
- Sistem veritabanları:
mastervemsdb(işler, kullanıcılar, yapılandırma) sunucunun yeniden kurulumunda gerekir; bunları da yedekleyin. - Yedeği başka yere kopyalayın. Yedek, veritabanıyla aynı diskte kalırsa disk arızasında ikisini de kaybedersiniz. 3-2-1 kuralını uygulayın.
- Yedeği şifreleyin. Yedek dosyası, veritabanınızın tamamını taşır. Çalınırsa tüm veri sızar. Şifreleme kullanıyorsanız sertifika ve anahtarlarını da yedekleyin; olmadan geri yükleme yapılamaz.
- Yer kontrolü yapın. Hedef disk dolarsa yedekler sessizce başarısız olabilir; bildirimleri izleyin.
- Geri yükleme sürenizi bilin. Büyük bir veritabanının geri yüklenmesi saatler sürebilir; RTO hedefinizi buna göre belirleyin.
DenizBackup ile SQL Server yedekleme
Yukarıdaki işlemleri her gece elle çalıştırmak ya da kendi betiklerinizi bakımını yapmak yerine, DenizBackup SQL Server veritabanlarınızı otomatik olarak .bak formatında yedekler. Zamanlamayı bir kez kurarsınız; yedekler AES-256 ile şifrelenir, FTP/SFTP sunucusuna aktarılır, eski yedekler politikaya göre temizlenir. Her çalışma loglanır ve sonuç e-posta ile bildirilir.
SQL yedekleme kurulumunda destek almak isterseniz, satın alma formunda notunuza SQL Server kullanımınızı yazmanız yeterli; ekibimiz dönüş yapar.
