SQL Server ASP.NET C# Kitabı

Veri tabanlarını Yeniden Kurma(RECOVERY işlemi)

Önceki yazıda yedekleme stratejilerinden ve backup işlemlerinin nasıl yapılacağından bahsettik. Şimdi bu yedekleri sistem çöktüğü zaman veya herhangi bir durumda nasıl kullanacağımızı, bunları kullanarak nasıl bir geri yükleme yapacağımızı işleyeceğiz. Alınmış yedeklerden veri tabanını ayağa kaldırmadan önce elimizdeki yedek dosyalarının doğruluğundan, formatından emin olmalıyız. Bu işlem için Management Studio kullanılabildiği gibi aşağıdaki T-SQL komutları da kullanılabilir.

1 – RESTORE HEADERONLY : Alınmış olan yedeÄŸin header bilgilerini listeler. Aynı yedek dosyası veya aygıtında birden fazla yedek varsa hepsinin header bilgisi listelenir. Header bilgisi, veri tabanı adını, yedek dosyasının adını, yedekleme ortamının tipini(disk, type), yedekleme metodunu(full database, Differential, transaction log), yedekleme tarihini, yedek boyutunu, LSN numaralarını, Collation gibi birçok bilgiyi içerir.

RESTORE HEADERONLY FROM disk='C:\Deneme.bak'

2 – RESTORE FILELISTONLY : Backup dosyasında bulunan orjinal veritabanı ve transaction log dosyaları hakkındaki bilgileri döndürür. Böylece o yedek aygıtı veya dosyası içerisinde hangi veri tabanının yedeÄŸinin bulunduÄŸunu öğrenmiÅŸ olur yanlış yedek dosyalarını restore etmemiÅŸ oluruz.

RESTORE FILELISTONLY FROM disk='C:\Deneme.bak'

3 – RESTORE LABELONLY : Yedek dosyasının tutulduÄŸu yedekleme ortamı hakkynda bilgiyi döndürür.

RESTORE LABELONLY FROM disk='C:\Deneme.bak'

4 – RESTORE VERIFYONLY : Yedekleme iÅŸleminin doÄŸru yapılıp yapılmadığını, yedek dosyasının geçerli bir backup dosyası olup olmadığını, sistem tarafından okunabilir olup olmadığını kontrol eder. EÄŸer dosya, SQL Server tarafından uygunsa “The backup set on file X is valid.” mesajı döner.

RESTORE VERIFYONLY FROM disk='C:\Deneme.bak'

Bu komutları çalıştırarak hem yedek dosyasının doğruluğunu denetlemiş olur hem de yedeği restore ettiğimizde karşımızda ne tür özellik ve seçeneklere sahip bir veri tabanının çıkacağını öğrenmiş oluruz.

Elimizdeki backup dosyalarının doÄŸruluÄŸunu denetledikten sonra tavsiye edilen diÄŸer adımlar, kullanıcıların veri tabanına eriÅŸmesini kısıtlamak için “dbo use only” seçeneÄŸi aktifleÅŸtirilmesi ve istenmeyen bir durumda geri dönülmek üzere güncel bir log backup’ın alınmasıdır.

RESTORE Komutu

SQL Server üzerinde backup’lardan geri dönme için RESTORE komutu kullanılır. Bu komutla birlikte RECOVERY veya NORECOVERY veya STANDBY parametreleri kullanılır. Default seçenek olarak RECOVERY seçeneÄŸinde restore iÅŸlemi son transaction log ile birlikte gerçekleÅŸtirilir. Yazının başında alttığımız gibi SQL Server, transaction logdaki onaylanmamış iÅŸlemleri geri döndürür ve onaylanmış iÅŸlemleri ileri gönderir. EÄŸer full backup’tan sonra elimizde restor edilmeyi bekleyen bir Differential backup veya log backup varsa bu seçeneÄŸi kullanmamalıyız. Böyle bir durum için NORECOVERY seçeneÄŸi tercih edilmelidir. Bu seçenek, çoklu yedek dosyalasının restore edileceÄŸi anlamına gelir. NORECOVERY seçeneÄŸi son yedek hariç bütün yedekler için kullanılır. STANDBY parametresi, NORECOVERY seçeneÄŸine alternatif olarak kullanılır. Veri tabanını NORECOVERY ile restor ettiÄŸimizde veri tabanı, “Restoring” moduna girer bu durumda kullanıcılar veri tabanına eriÅŸemez, veri tabanı üzerinde herhangi bir sorgulama yapılamaz. STANDBY seçeneÄŸindeyse kullanıcıların yalnızca veri çekmelerine(SELECT) izin verilmez.

Aynı yedek dosyası veya aygıtı içerisinden birden fazla yedek dosyası varsa bunları FILE parametresi verilerek seçilir.

Elimizdeki yedekleri farklı bir sunucu veya disk pathine restore etmek için MOVE TO parametresi kullanılır.

RESTORE komutuyla birlikte kullanılan diğer parametre REPLACE parametresidir. Veri tabanı yedek dosyasının, varolan veri tabanının üzerine yazılması, onun yerini alması için kullanılır.

AÅŸağıdaki örnekte daha önce aldığımız full backup’ı restore etmeye çalışalım.

RESTORE DATABASE Deneme
FROM DISK = N'C:\Deneme.bak'

Bu komut sonrası SQL Server 2005′te The tail of the log for the database “Deneme” has not been backed up. Use BACKUP LOG WITH NORECOVERY to backup the log if it contains work you do not want to lose. Use the WITH REPLACE or WITH STOPAT clause of the RESTORE statement to just overwrite the contents of the log. hata mesajıyla karşılaşırız. Bu özellik, SQL Server 2005 ile birlikte gelmiÅŸ olup elimizdeki yedek dosyasının restore etmeye çalıştığımız güncel veri tabanından daha eski olduÄŸunu konusunda bizi uyarmaktadır. Son yedekten bu yana yapılan deÄŸiÅŸiklikleri kaybetmemek için bir log backup almamız istenmektedir(Tail log backup). Bunun için ya NO_TRUNCATE ve NORECOVERY parametrelerini kullanarak güncel bir log backup alacağız ya da REPLACE komutuyla güncel veri tabanının üzerine yazacağız. Åžimdi bu adımları tek tek gerçekleÅŸtirelim. Öncelikle veri tabanının güncel log backup’ını alalım.

--Database eriÅŸiliyorsa
BACKUP LOG Deneme TO DISK = 'C:\DenemeLog.bak'
WITH NORECOVERY;
GO
--Database eriÅŸilmez durumdaysa
BACKUP LOG Deneme TO DISK = 'C:\DenemeLog.bak'
WITH NO_TRUNCATE;

Ardından elimizdeki güncel full backup’ı restore ediyoruz. Full backup’tan sonra aldığımız güncel log backup’ı da restore edeceÄŸimiz için NORECOVERY parametresini kullanıyoruz.

--En güncel full backup'ı restore et
RESTORE DATABASE Deneme
	FROM DISK = 'C:\DenemeFull.bak'
	WITH FILE=1, NORECOVERY;

Eğer elimizde bir de differential backup varsa onu da restore ediyoruz. Eğer differential backup yoksa bu adımı geçebiliriz.

--En günce differential backup'ı restore et
RESTORE DATABASE Deneme
	FROM DISK = 'C:\DenemeDiff.bak'
	WITH FILE=1,
	NORECOVERY;

Bu adımdan sonra eğer elimizde birden fazla log backup varsa onları da WITH NORECOVERY parametresiyle sırasıyla restore ediyoruz. Hatta en son log dosyasında belli bir ana dönmek için de aşağıda vereceğimiz parametreleri girebiliriz.

--En günce differential backup'ı restore et
RESTORE DATABASE Deneme
	FROM DISK = 'C:\DenemeLog1.bak'
	WITH FILE=1,
	NORECOVERY;

Bu aşamaya kadar veri tabanı kullanıcılar tarafından erişilemez çünkü hala restoring modundadır. Bütün transaction logları restore ettikten sonra veri tabanını kullanıma açmak için aşağıdaki satırı yazalım.

RESTORE DATABASE Deneme WITH RECOVERY;

Veya ilk başta yaptığımız güncel log backup alınmaz. Full backup var olan veri tabanının üzerine yazılır.

RESTORE DATABASE Deneme
	FROM DISK = N'C:\Deneme.bak' WITH REPLACE

En son güncel log backup kullanılarak yedek dosyasını tümüyle restore etmek yerine belli bir tarihe kadar restore edilmesi için STOPAT parametresi kullanılır. AÅŸağıdaki örnekte log dosyasındaki 10 Haziran’a kadarki iÅŸlemlerin restore edilmesi istenmiÅŸtir.

RESTORE LOG Deneme
FROM DISK = 'C:\DenemeLog.bak'
WITH FILE = 1
	RECOVERY
	STOPAT = 'June 10, 2007 1:00'

Elimizdeki yedek dosyasını var olan veri tabanı üzerinde değil de başka bir veri tabanı olarak restore etmek için WITH MOVE parametresi kulanılır.

RESTORE DATABASE Deneme1
	FROM DISK = 'C:\DenemeFull.bak'
	WITH MOVE 'Deneme' TO 'C:\Deneme1.mdf',
	MOVE 'Deneme_log' TO 'C:\Deneme1.ldf',
	REPLACE

Buradaki Deneme ve Deneme_log yedek dosyalarındaki data dosyalarının mantıksal ismidir. Bunu öğrenmek için de aşağıdaki satır kullanılır.

RESTORE FILELISTONLY FROM DISK = 'C:\DenemeFull.bak'

COPY_ONLY Seçeneği

SQL Server 2005 ile birlikte gelmiş olan bu özellik sistem tarafından oluşturulan LSN zincirini(sağladığımız düzenli backup alma sistemini) bozmadan full database veya transaction log backup almayı sağlar. Bilindiği gibi yedekler senaryolarında ilk önce full backup alınır ve ardından Differential veya Log backup alınır. Alınan backuplar en son alınmış full backup ile ilişkili olur. Belli aralıklarla aşağıdaki şekilde backuplar aldığımız düşünelim.

USE master
GO
BACKUP DATABASE Deneme TO DISK='C:\Dnm_Full1.BAK'
	WITH INIT, NAME='Dnm_Full1'
GO
UPDATE Deneme..Musteri SET AdSoyad='A' WHERE MusteriId=1
GO
BACKUP DATABASE Deneme TO DISK='C:\Dnm_Diff1.BAK'
	WITH DIFFERENTIAL, INIT, NAME='Dnm_Diff1'
GO
UPDATE Deneme..Musteri SET AdSoyad='B' WHERE MusteriId=1
GO
BACKUP DATABASE Deneme TO DISK='C:\Dnm_Diff2.BAK'
	WITH DIFFERENTIAL, INIT, NAME='Dnm_Diff2'
GO
UPDATE Deneme..Musteri SET AdSoyad='C' WHERE MusteriId=1
GO
BACKUP LOG Deneme TO DISK='C:\Dnm_Log1.BAK'
	WITH INIT, NAME='Dnm_Log1'
GO
UPDATE Deneme..Musteri SET AdSoyad='D' WHERE MusteriId=1
GO
BACKUP LOG Deneme TO DISK='C:\Dnm_Log2.BAK'
	WITH INIT, NAME='Dnm_Log2'
GO

Burada görüldüğü gibi ilk önce bir full backup ardından 2 kez differential backup ve son olarak 2 log backup alınmış ve her backup aralığında database üzerinde deÄŸiÅŸiklik yapılmış. Alınan her backup kendisine en yakın full backup’ın LSN(log sequence number) deÄŸerini de taşır. msdb.dbo.backupset tablosundan alınmış olan backupların LSN aralıklarına bakalım.

SELECT name, backup_start_date, type, first_lsn, last_lsn, database_backup_lsn
FROM msdb.dbo.backupset WHERE database_name = 'Deneme';

Buradaki type kolonu, alınan yedek dosyasının türünü belirtir. Aşağıdaki değerleri alabilir:
D = Database
I = Database Differential
L = Log
F = File or Filegroup
G = File Differential
P = Partial
Q = Partial Differential

database_backup_lsn kolonu en son alınmış full backup’a ait database_backup_lsn LSN deÄŸerini berir.

Åžekilde görüldüğü gibi en son alınmış olan full backup’ın ilk LSN deÄŸeri “21000000008000159″ deÄŸerine sahip. Ondan sonra alınmış tüm backupların database_backup_lsn kolunu bu deÄŸeri göstermektedir.

Şimdi aynı şekilde en sonki log backuptan sonra bir full backup daha alalım ve ardından birer tane Differential ve Log backup alalım.

--Yeni bir full backup alalım
BACKUP DATABASE Deneme TO DISK='C:\Dnm_Full2.BAK'
	WITH INIT, NAME='Dnm_Full2'
GO
UPDATE Deneme..Musteri SET AdSoyad='E' WHERE MusteriId=1
GO
BACKUP DATABASE Deneme TO DISK='C:\Dnm_Diff3.BAK'
	WITH DIFFERENTIAL, INIT, NAME='Dnm_Diff3'
GO
UPDATE Deneme..Musteri SET AdSoyad='F' WHERE MusteriId=1
GO
BACKUP LOG Deneme TO DISK='C:\Dnm_Log3.BAK'
	WITH INIT, NAME='Dnm_Log3'

Görüldüğü gibi son alınan backuplar daha önce alınmış full backup’ı(Dnm_Full1) deÄŸil en son alınmış full backup’ı referans aldılar(Dnm_Full2). Bundan sonra alınacak tüm backuplar, Dnm_Full2 isimli full backup’a baÄŸlı olacaktır. Bu durumda recovery iÅŸlemini de aldığımız full backup bazında yapabiliriz.

RESTORE DATABASE Deneme FROM DISK='C:\Dnm_Full1.BAK' WITH NORECOVERY, REPLACE
RESTORE LOG Deneme FROM DISK='C:\Dnm_Log1.BAK' WITH NORECOVERY
RESTORE LOG Deneme FROM DISK='C:\Dnm_Log2.BAK' WITH RECOVERY 

Eğer Dnm_Full1 ile birlikte ikinci full backuptan sonra alınmış olan Dnm_Log3 dosyasını kullanmak istersek hatalı bir durum oluşmuş olur.

RESTORE DATABASE Deneme FROM DISK='C:\Dnm_Full1.BAK' WITH NORECOVERY, REPLACE
--RESTORE LOG Deneme FROM DISK='C:\Dnm_Log1.BAK' WITH NORECOVERY
RESTORE LOG Deneme FROM DISK='C:\Dnm_Log3.BAK' WITH RECOVERY 

Processed 176 pages for database 'Deneme', file 'Deneme' on file 1.
Processed 5 pages for database 'Deneme', file 'Deneme_log' on file 1.
RESTORE DATABASE successfully processed 181 pages in 0.097 seconds (15.222 MB/sec).
Msg 4305, Level 16, State 1, Line 3
The log in this backup set begins at LSN 21000000017100001, which is too recent to apply to the database. An earlier log backup that includes LSN 21000000014800001 can be restored.
Msg 3013, Level 16, State 1, Line 3
RESTORE LOG is terminating abnormally.

EÄŸer gerçekten bundan sonraki backuplar için baÅŸlangıç noktası olarak Dnm_Full2′yi alacaksak daha önce aldığımız Dnm_Full1, Dnm_Diff1, Dnm_Diff2, Dnm_Log1 ve Dnm_Log2 backuplarının bir anlamı kalmamaktadır. Peki amacımız daha önce aldığımız backupları geçersiz kılmak deÄŸil de sadece o anda güncel bir full backup’a ihtiyacımız olursa ne yapacağız. Ä°ÅŸte bunun için SQL Server 2005 WITH COPY_ONLY seçeneÄŸini sunmaktadır. WITH COPY_ONLY seçeneÄŸi, backup alma düzenimizi bozmayacak ÅŸekilde backup aldırır.

USE master
GO
BACKUP DATABASE Deneme TO DISK='C:\Dnm_Full1.BAK'
	WITH INIT, NAME='Dnm_Full1'
GO
BACKUP DATABASE Deneme TO DISK='C:\Dnm_Diff1.BAK'
	WITH DIFFERENTIAL, INIT, NAME='Dnm_Diff1'
GO
BACKUP DATABASE Deneme TO DISK='C:\Dnm_Diff2.BAK'
	WITH DIFFERENTIAL, INIT, NAME='Dnm_Diff2'
GO
BACKUP LOG Deneme TO DISK='C:\Dnm_Log1.BAK'
	WITH INIT, NAME='Dnm_Log1'
GO
BACKUP LOG Deneme TO DISK='C:\Dnm_Log2.BAK'
	WITH INIT, NAME='Dnm_Log2'
GO
--Yeni bir full backup alalım
BACKUP DATABASE Deneme TO DISK='C:\Dnm_Full2.BAK'
	WITH INIT, COPY_ONLY, NAME='Dnm_Full2'
GO
BACKUP DATABASE Deneme TO DISK='C:\Dnm_Diff3.BAK'
	WITH DIFFERENTIAL,COPY_ONLY, INIT, NAME='Dnm_Diff3'
GO
BACKUP LOG Deneme TO DISK='C:\Dnm_Log3.BAK'
	WITH INIT,COPY_ONLY, NAME='Dnm_Log3'
GO
--Normal bir Log backup alalım
BACKUP LOG Deneme TO DISK='C:\Dnm_Log4.BAK'
	WITH INIT, NAME='Dnm_Log4'

Aynı şekilde tekrar msdb.dbo.backupset tablosunu sorgulayalım. Bu arada tablodaki is_copy_only kolonunu da okuyalım.

SELECT name, backup_start_date, type, first_lsn,
last_lsn, database_backup_lsn,is_copy_only
FROM msdb.dbo.backupset WHERE database_name = 'Deneme';

Görüldüğü gibi ikinci full backup’tan sonraki backup’ların Bu durumda aÅŸağıdaki gibi recovery iÅŸlemlerinde bulunabiliriz.

RESTORE DATABASE Deneme FROM DISK='C:\Dnm_Full1.BAK' WITH NORECOVERY, REPLACE
RESTORE LOG Deneme FROM DISK='C:\Dnm_Log1.BAK' WITH NORECOVERY
RESTORE LOG Deneme FROM DISK='C:\Dnm_Log4.BAK' WITH RECOVERY 

Copy-only seçeneğinin kullanıldığı differential backup recovery amaçlı kullanılamaz.

--BAÅžARILI
RESTORE DATABASE Deneme FROM DISK='C:\Dnm_Full1.BAK' WITH NORECOVERY, REPLACE
RESTORE DATABASE Deneme FROM DISK='C:\Dnm_Diff1.BAK' WITH RECOVERY
--BAÅžARISIZ
RESTORE DATABASE Deneme FROM DISK='C:\Dnm_Full2.BAK' WITH NORECOVERY, REPLACE
RESTORE DATABASE Deneme FROM DISK='C:\Dnm_Diff3.BAK' WITH RECOVERY

Processed 176 pages for database 'Deneme', file 'Deneme' on file 1.
Processed 1 pages for database 'Deneme', file 'Deneme_log' on file 1.
RESTORE DATABASE successfully processed 177 pages in 0.074 seconds (19.497 MB/sec).
Msg 3136, Level 16, State 1, Line 2
This differential backup cannot be restored because the database has not been restored to the correct earlier state.
Msg 3013, Level 16, State 1, Line 2
RESTORE DATABASE is terminating abnormally.

Ekran sonuçlarında ÅŸunu da görünüyoruz; Transaction Log backup bir önceki backupa ait en sonki LSN’dan itibaren yedekleme yapmaktadır.

SQL Server, kullanıcı veri tabanlarını yedeklediği gibi sistem veri tabanlarının da yedeklenmesine izin verir.

SQL Server üzerinde backup işlemlerini yapabilmek için sysadmin,db_owner veya db_backupoperator rolüne sahip olmak gerekir.

Yedekleme Senaryoları

1 – Simple recovery – Full backup örneÄŸi
Her gün saat 23:00′de full backup aldığımızı ve veri tabanının saat 15:00′da zarar gördüğünü ve transaction log’un tüm iÅŸlemleri kaydetmediÄŸini(Simple recovery model) düşünelim. Bu senaryoda ancak dün gece alınmış full backup’tan geri dönülür. Bu durumda dün geceden bu yana yapılan deÄŸiÅŸiklikler kaybedilmiÅŸ olur.

2 – Full recovery – Full backup örneÄŸi
Her gün saat 23:00′de full backup aldığımızı ve veri tabanının saat 15:00′da zarar gördüğünü ve transaction log’un tüm iÅŸlemleri kaydettiÄŸini(Full recovery model) düşünelim. Bu senaryoda öncelikle veri tabanı kullanıcıların eriÅŸimine kapatılır ve hemen güncel bir log backup alınır (WITH NO_TRUNCATE). Dün gece alınmış full backup, bozulmuÅŸ veri tabanının üzerine yüklenir ve az önce alınmış olan log backup yüklenir.

3 – Full recovery – Full ve Log backup örneÄŸi
Her gün saat 23:00′de full backup aldığımızı ayrıca gün içerisinde 10:00 – 14:00 – 18:00 saatlerinde log backup aldığımızı ve veri tabanının saat 15:00′da zarar gördüğünü düşünelim. Öncelikle veri tabanı kullanıcıların eriÅŸimine kapatılır ve hemen güncel bir log backup alınır (WITH NO_TRUNCATE). Dün gece alınmış full backup, bozulmuÅŸ veri tabanının üzerine yüklenir ardından 10:00 ve 14:00′te alınmış olan log backup sırasıyla recovery edilir ve son olarak az önce alınmış olan log backup yüklenir.

4 – Full recovery – Full, Differential ve Log backup örneÄŸi
Her hafta pazar günü full backup ve her gün 23:00′da differential backup alıyoruz. Ayrıca gün içerisinde 10:00 – 14:00 – 18:00 saatlerinde log backup aldığımızı ve veri tabanının hafta içi perÅŸembe günü saat 15:00′da zarar gördüğünü düşünelim. Öncelikle veri tabanı kullanıcıların eriÅŸimine kapatılır ve hemen güncel bir log backup alınır (WITH NO_TRUNCATE). GeçtiÄŸimiz pazar günü alınmış olan full backup, bozulmuÅŸ veri tabanına yüklenir ardından çarÅŸamba günü 23:00′da alınmış differential backup yüklenir. Böylece pazar günününde çarÅŸamba günü gece 23:00′a kadar yapılmış deÄŸiÅŸiklikler yüklenmiÅŸ olur. Ardından perÅŸembe günü 10:00 ve 14:00′te alınmış transaction log recovery edilir ve son olarak az önce alınmış olan log backup yüklenir.

5 – Full recovery – Full, Differential ve Log backup örneÄŸi(NO_TRUNCATE)
Aşağıdaki örneği inceleyelim.

BACKUP DATABASE Deneme TO DISK='C:\Dnm_Full1.BAK'
	WITH NAME='Dnm_Full1', INIT
GO
BACKUP LOG Deneme TO DISK='C:\Dnm_Log1.BAK'
	WITH NAME='Dnm_Log1', INIT
GO
BACKUP LOG Deneme TO DISK='C:\Dnm_Log2.BAK'
	WITH NAME='Dnm_Log2', INIT
GO
BACKUP DATABASE Deneme TO DISK='C:\Dnm_Diff1.BAK'
	WITH NAME='Dnm_Diff1', INIT, DIFFERENTIAL
GO
BACKUP LOG Deneme TO DISK='C:\Dnm_Log3.BAK'
	WITH NAME='Dnm_Log3', INIT
GO
BACKUP DATABASE Deneme TO DISK='C:\Dnm_Diff2.BAK'
	WITH NAME='Dnm_Diff2', INIT, DIFFERENTIAL
GO
--Sistem crash oldu
--Güncel Log backup alalım
BACKUP LOG Deneme TO DISK='C:\Dnm_Log4.BAK'
	WITH NAME='Dnm_Log4', INIT

Bu örnekte, sırasıyla Full, Dnm_Full1, Dnm_Log1, Dnm_Log2, Dnm_Diff1, Dnm_Log3, Dnm_Diff2, Dnm_Log4 yedek dosyaları alınmıştır. Böyle bir senaryoda log dosyaları birbirilerine zincirleme baÄŸlı oldukları için sadece log backup kullanılarak recovery edilebilir veya daha mantıklı olanı son diferensiyal yedeÄŸi ve güncel log backup’ı kullanmaktır.

RESTORE DATABASE Deneme FROM DISK='C:\Dnm_Full1.BAK' WITH NORECOVERY, REPLACE
--RESTORE LOG Deneme FROM DISK='C:\Dnm_Log1.BAK' WITH NORECOVERY
--RESTORE LOG Deneme FROM DISK='C:\Dnm_Log2.BAK' WITH NORECOVERY
--RESTORE DATABASE Deneme FROM DISK='C:\Dnm_Diff1.BAK' WITH NORECOVERY
--RESTORE LOG Deneme FROM DISK='C:\Dnm_Log3.BAK' WITH NORECOVERY
RESTORE DATABASE Deneme FROM DISK='C:\Dnm_Diff2.BAK' WITH NORECOVERY
RESTORE LOG Deneme FROM DISK='C:\Dnm_Log4.BAK' WITH RECOVERY

Aradaki log backupları kullanmayarak adımları kısaltımış olduk. Çünkü differential backup aldığımız zaman en son alınmış full backup’tan bu yana alınmış log backuplar birleÅŸtirilmiÅŸ olur.

Veya sadece loglaları da kullanabiliriz.

RESTORE DATABASE Deneme FROM DISK='C:\Dnm_Full1.BAK' WITH NORECOVERY, REPLACE
RESTORE LOG Deneme FROM DISK='C:\Dnm_Log1.BAK' WITH NORECOVERY
RESTORE LOG Deneme FROM DISK='C:\Dnm_Log2.BAK' WITH NORECOVERY
--RESTORE DATABASE Deneme FROM DISK='C:\Dnm_Diff1.BAK' WITH NORECOVERY
RESTORE LOG Deneme FROM DISK='C:\Dnm_Log3.BAK' WITH NORECOVERY
--RESTORE DATABASE Deneme FROM DISK='C:\Dnm_Diff2.BAK' WITH NORECOVERY
RESTORE LOG Deneme FROM DISK='C:\Dnm_Log4.BAK' WITH RECOVERY

Son olarak en kötü senaryodan bahsedelim. Elimizde herhangi bir full backup yoksa ve hatalı bir durum gerçekleştiyse bunu şimdiye kadar anlattığımız yöntemlerle çözmemiz imkansız. Bunun için third-party toollar kullanılabilir. Bu işlemlerde kullanılan en ünlü araçlar şunlardır;
Red-Gate SQL Log Rescue
Lumigent Log Explorer
ApexSQL Log

Management Studio Kullanmak

Şimdiye kadar anlattığımız tüm işlemler Management Studio ekranından da kolaylıkla yapılabilir. Yedeği alınacak veri tabanı sağ tıklanarak Tasks bölümünden Backup ve Restore işlemleri yapılabilir.

Restore bölümünün sağladığı kolaylık, daha önce alınmış backup dosyalardan hangilerini yüklememizin yeterli olacağını işaretlemesidir.

Aynı zamanda bu ekrandaki Options bölümünden REPLACE, WITH RECOVERY, WITH NORECOVERY seçenekleri de aktifleştirilebilir.

SQL Server yedek alımının otomatikleştirilmesi(Maintenance Plan)

SQL Server, veri tabanı için hayati önem arzeden database integrity, rebuild index, backup yönetimi, denetleme, koruma iÅŸlemleri için, rutin bir ÅŸekilde backup dosyalarını saklamak ve zamanı geldiÄŸinde en eski dosyaları silmek gibi süreçleri oluÅŸturmak için etkili bir bakım programı sunmaktadır. Management Studio’da altında bulunan Maintenance Plan isimli bu program, daha önceki versiyonlarda da olup SQL Server 2005′te daha yönetimsel hala getirilmiÅŸ oldu. Programın üzerinde Wizard’ı kullanılarak oluÅŸturulacak tasklarla birçok yönetimsel iÅŸlemler gerçekleÅŸtirilebilir, sql serverin bakımı ve denetimi daha kolayca gerçekleÅŸtirilebilir. Bu programın Wizardı gerekli yönlendirmeleri yaptığı için ekran görüntülerini buraya koymadım.