La plupart des opérations de restauration débutent par la re-création de la base de données à un instant précis, puis appliquent des sauvegardes ulterieures pour ramener la base de données à un point précis dans le temps.

exemple :

RESTORE DATABASE PUBS FROM DISK 'C:\DEMOPUBS.BAK' WITH REPLACE

WITH RECOVERY : la base de données est mise en ligne.
WITH NORECOVERY : la base de données reste fixée à RESTORING, on peux appliquer une nouvelle restauration sur la base.

Sauvegarde différentielle.

exemple :
RESTORE DATABASE PUBS FROM DISK ‘C:\DEMOPUBS_FULL.BAK‘ WITH NORECOVERY
RESTORE DATABASE PUBS FROM DISK ‘C:\DEMOPUBS_DIFF.BAK‘ WITH RECOVERY

Restauration d’une sauvegarde de journal de transaction.

Récupérer une base de données sans aucune perte de données serait plus facile si les problèmes arrivait juste apres une sauvegarde, avant meme que l’application n’est effectue une quelconque transaction. Malheureusement, nous n’avons pas cette chance. Aussi dans tout scénario catastrophe, le journal contient toujours des transactions qui n’ont pas ete sauvegarde.
c’est pour cette raison que la premiere etape de toute operation de recuperation doit toujours consister à emettre une derniere commande backup log. Ce processus capture toute transaction validée non encore sauvegarde et est sauvent nomme sauvegarde de queue de journal. comme vous pouvez executer une commande back up log sur une base de donnée meme en l’indisponibilite de tout fichier de donnees. La sauvegarde de la queue de journal est le dernier journal que vous restaurez dans un processus de restauration. Ainsi, vous ne perdez aucune données.

exemple :

RESTORE DATABASE AdventureWorks FROM DISK ‘c: estawf.bak’ WITH NORECOVERY
RESTORE LOG AdventureWorks FROM DISK ‘c: estaw1.trn’ WITH NORECOVERY
RESTORE LOG AdventureWorks FROM DISK ‘c: estaw2.trn’ WITH RECOVERY