Discussion :

[aziatedu13]

Bonjour,

J'ai trouvé ce site :
qui explique et illustre très clairement la sauvegarde,et la restauration des log dans SQLSERVER :
le scénario est bien fait , et simple à comprendre :
http://blog.capdata.fr/index.php/poi...fn_dump_dblog/

maintenant, je souhaite mettre en place la plannification de mes sauvegardes

Voici ce que je prévois :

Jour-J

00:00:00 : Sauvegarde Complete de ma base . nom du fichier mabdd_full.bak
01:15:00 : Sauvegarde de mes logs nom du fichier : mabdd_log_01:15:00.trn
01:30:00 : Sauvegarde de mes logs nom du fichier : mabdd_log_01:30:00.trn
....
23:59:00 : Sauvegarde sur support amovible tous les fichier trn et le fichier bak de la journée

Une fois la sauvegarde sur support amovible, je supprime tous les fichiers de log et mon fullbackup pour recommencer une journée.

Jour J+1
de Complete de ma base . nom du fichier mabdd_full.bak
01:15:00 : Sauvegarde de mes logs nom du fichier : mabdd_log_01:15:00.trn
01:30:00 : Sauvegarde de mes logs nom du fichier : mabdd_log_01:30:00.trn
....


Je pense comme ça pouvoir revenir à nimporte quel moment de la journée, sur n'importe quelle journée.

mes scripts pour la sauvegarde complete seront :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
BACKUP DATABASE mabdd
TO DISK = 'C:\test\ mabdd_full.bak'

mes scripts pour la sauvegarde de log seront :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
BACKUP LOG inetdb
TO DISK = 'C:\test\mabdd_log_01:15:00.trn'

Est ce une bonne méthode ?
Ce qui me parait bizarre, c'est de devoir effacer les fichiers bak et TRN.
N'y a t-il pas des options qui permettent de dire je recommence de 0 avec les même fichier ?

merci de vos conseils

SQL SERVER 2005 SP4
Windows SERVER 2003 R2

[mikedavem]

Hello,

Est ce une bonne méthode ?

Impossible de te répondre sans plus d'éléments. Ta méthode de sauvegarde doit être adaptée à ta stratégie de restauration et des contraintes business. Il faut te poser les questions suivantes :

- Quelle est la quantité acceptable de données que je peux me permettre de perdre ?
- Quelle est le temps d'indisponibilité acceptable de mon SI si je dois restaurer ma (ou mes) base(s) de données ?

En fonction de cela il faudra adapter ta stratégie de sauvegarde et de rétention de tes backups.

Ce qui me parait bizarre, c'est de devoir effacer les fichiers bak et TRN.
N'y a t-il pas des options qui permettent de dire je recommence de 0 avec les même fichier ?

Rien de bizarre là dedans . Cela fait parti de la politique de rétention de tes sauvegardes. Tu peux tout à fait définir un seul média de sauvegarde si tu le souhaites en utilisant l'option INIT de la commande BACKUP.

Dans ton exemple tu peux commencer tes 2 types de sauvegardes avec l'option init comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
BACKUP DATABASE mabdd
TO DISK = 'C:\test\ mabdd_full.bak' WITH INIT

...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
BACKUP LOG inetdb
TO DISK = 'C:\test\mabdd_log.trn' WITH INIT

...

Ensuite le reste des sauvegardes des journaux de transactions sans l'option init tout au long de la journée

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
BACKUP LOG inetdb
TO DISK = 'C:\test\mabdd_log.trn'

++

[aziatedu13]

merci de ta réponse.

Je comprend que je peux utiliser le même fichier trn, pour mes différentes sauvegarde de Log.

mais dans le scénario du site , il y a 4 fichier trn :

demorecovery_LOG1.trn
demorecovery_LOG2.trn
demorecovery_LOG3.trn
demorecovery_LOG4.trn

Si je mets tous ces fichiers , dans le même, comment pourrai je spécifier de ne rejouer que le demorecovery_LOG1.bak,demorecovery_LOG2.bak et demorecovery_LOG3.bak ?



De plus, je ne comprend pas vraiment à quoi sert la dernière partie :

--tail log backup
backup log demorecovery to disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_TAILLOG.bak' with init, stats, NO_TRUNCATE, NORECOVERY
GO

Je comprend que l'on sauvegarde juste la fin du journal de log ?
Est ce une précaution au cas ou on ne saurez pas exactement dans quel fichier de LOG se trouve notre mauvaise transaction , et garder toutes les transactions jusqu'à la fin ?
Une nécessité pour une quelconque raison ?

Merci de vos conseils.

[mikedavem]

Je comprend que je peux utiliser le même fichier trn, pour mes différentes sauvegarde de Log.

C'est exact un seul média de sauvegarde peut être utilisé.

Si je mets tous ces fichiers , dans le même, comment pourrai je spécifier de ne rejouer que le demorecovery_LOG1.bak,demorecovery_LOG2.bak et demorecovery_LOG3.bak ?

En spécifiant la position de fichier dans le média qui est stocké dans l'entête du média de sauvegarde (tu peux ce numéro en utilisant la commande RESTORE HEADERONLY)

De plus, je ne comprend pas vraiment à quoi sert la dernière partie :

--tail log backup
backup log demorecovery to disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_TAILLOG.bak' with init, stats, NO_TRUNCATE, NORECOVERY
GO

Je comprend que l'on sauvegarde juste la fin du journal de log ?
Est ce une précaution au cas ou on ne saurez pas exactement dans quel fichier de LOG se trouve notre mauvaise transaction , et garder toutes les transactions jusqu'à la fin ?
Une nécessité pour une quelconque raison ?

Le tail log backup est une sauvegarde qui permet de récupérer la partie du journal qui n'a pas encore été sauvegardé. Cette sauvegarde peut être utile en dernier recours pour tenter de récupérer le "delta" qui n'a pas été sauvegardé pour pouvoir restaurer les données au plus près du crash sans perte de données.

C'est une opération exceptionnelle et ne doit pas être incluse dans ta routine de sauvegarde.

++

[Ptit_Dje]

23:59:00 : Sauvegarde sur support amovible tous les fichier trn et le fichier bak de la journée

Une fois la sauvegarde sur support amovible, je supprime tous les fichiers de log et mon fullbackup pour recommencer une journée.

Pour ma part, je vois une légère incohérence dans ta stratégie de sauvegarde.
En effet, tu effectues un log backup toutes les 15 minutes, ce qui vise à un RPO (recovery point objective) de ~15 minutes ou moins (ou en autre terme, tu peux garantir une perte de données maximale de ~15 minutes).
Cependant tu effectues la remontée vers tape/infrastructure de backup ad-hoc, une seule fois par jour et donc tu as un RPO avec tes bandes de 24h ou moins.

Soit en effet tu viendrais à perdre tout ton serveur, ainsi que le disque contenant tes backups un soir à 22h, ton point de reprise serait de la veille à minuit, soit tu perds ~22h de données.

Personnellement, je te recommende, s'il est possible pour toi de procéder ainsi, de remonter chaque backup effectué sur bande directement.


A+