Discussion :

[Kropernic]

Bonjour,

Je suis en train de me documenter sur les backups et après lectures de nombreux articles et quelques tests, plusieurs questions restent toujours sans réponse...

1°
Il est possible de faire les backups de différentes DB sur un seul et même device. Est-ce une bonne idée ? (N.B. : Dans mon cas, toutes les DB se trouvent sur le même disque donc en cas de crash, je devrais de toute façon tout restaurer. Les index et les logs sont sur un disque séparé)

2°
Mon espace disque n'étant pas illimité, j'aimerais que les anciennes sauvegardes (disons de plus d'une semaine) soit écrasées. J'ai bien remarqué l'option RETAINDAYS (ou sa cousine EXPIRATIONDATE). Je pense également avoir compris qu'il fallait utiliser INIT pour l'écrasement mais le fonctionnement de cette option ne m'est toujours pas clair.

3°
Par manque de place sur le serveur (et aussi par ignorance), nous avons passé les DB en recovery model SIMPLE car nous avions des fichiers log incroyablement grands (forcément... aucun backup n'était fait jusqu'à il y a peu). Histoire de faire les choses convenablement, j'envisage de repasser les DB qui sont fréquemment mises à jour en recovery model FULL et d'adopter un plan de sauvegarde adapté (Full le dimanche, differential la nuit, log toutes les heures). Le journal de transaction est-il "purger" (est-ce le bon terme?) automatiquement après chaque sauvegarde ou bien y a-t-il une opération à effectuer manuellement ? J'aimerais éviter que l'espace disque restant soit grignoter par des journaux prenant de plus en plus de place.

4° (corollaire du 1°)
Pour les DB qui vont rester en recovery model SIMPLE, je pense créer un device par jour. Est-ce nécessaire ou puis-je tout mettre sur le même ?

5°
Nous sommes une moyenne entreprise et nous n'avons pas de serveur de réplication. Juste un serveur de production et un serveur de test. En cas de crash important du serveur de production, puis-je restaurer mes bases sur le serveur de test même si l'arborescence de fichiers n'est pas la même ?

Merci d'avance à ceux qui prendront le temps de me lire.

EDIT : (ajout de questions)

6°
Nous travaillons actuellement avec SQL SERVER 2005 (edition standard). J'ai bien lu que la compression n'est disponible qu'à partir de la version 2008. Pourtant, quand je consulte les headers d'un device de sauvegardes, il y a bien une colonne intitulée "Compressed". A quoi sert-elle dans ce cas ?

7°
Est-ce vraiment nécessaire de définir un nom et une description pour les backups ? Il y a de toute façon les informations de la DB sauvegarder et de la date de création du backup (et éventuellement la date d'expiration si elle est précisée).

[mikedavem]

1°
Il est possible de faire les backups de différentes DB sur un seul et même device. Est-ce une bonne idée ? (N.B. : Dans mon cas, toutes les DB se trouvent sur le même disque donc en cas de crash, je devrais de toute façon tout restaurer. Les index et les logs sont sur un disque séparé)

Oui c'est possible de faire cela. Personnellement je trouve que cela n'est pas une bonne idée. La raison principale est que si quelqu'un par mégarde fait une initialisation du média via la commande backup database with init toutes les sauvegardes seront perdues.

2°
Mon espace disque n'étant pas illimité, j'aimerais que les anciennes sauvegardes (disons de plus d'une semaine) soit écrasées. J'ai bien remarqué l'option RETAINDAYS (ou sa cousine EXPIRATIONDATE). Je pense également avoir compris qu'il fallait utiliser INIT pour l'écrasement mais le fonctionnement de cette option ne m'est toujours pas clair.

RETAINDAYS /EXPIRATIONDATE permettent de définir une période pendant laquelle on ne peut pas écraser le contenu d'une sauvegarde via l'option INIT. Cependant il faut noter que l'on peut tout à fait rendre invalide le contenu d'un média de sauvegarde via l'option FORMAT.

INIT sert à écraser le contenu d'un média de sauvegarde.

3°
Par manque de place sur le serveur (et aussi par ignorance), nous avons passé les DB en recovery model SIMPLE car nous avions des fichiers log incroyablement grands (forcément... aucun backup n'était fait jusqu'à il y a peu). Histoire de faire les choses convenablement, j'envisage de repasser les DB qui sont fréquemment mises à jour en recovery model FULL et d'adopter un plan de sauvegarde adapté (Full le dimanche, differential la nuit, log toutes les heures). Le journal de transaction est-il "purger" (est-ce le bon terme?) automatiquement après chaque sauvegarde ou bien y a-t-il une opération à effectuer manuellement ? J'aimerais éviter que l'espace disque restant soit grignoter par des journaux prenant de plus en plus de place.

Tu peux tout à fait revenir en mode recovery full en prenant soin de faire une sauvegardes du journal des transactions. Maintenant il faut également valider que ta nouvelle stratégie de restauration correspond à ton besoin. Est-ce que ton RPO (s'il existe) exige que tu ne dois pas perdre plus d'une heure de données voir restaurer tes bases au plus proche du crash ? Si tu peux te permettre de restaurer à J-1 il te sera inutile de passer en mode de recovery full si ce n'est que de complexifier ta stratégie de backup.

4° (corollaire du 1°)
Pour les DB qui vont rester en recovery model SIMPLE, je pense créer un device par jour. Est-ce nécessaire ou puis-je tout mettre sur le même ?

Voir 1°

5°
Nous sommes une moyenne entreprise et nous n'avons pas de serveur de réplication. Juste un serveur de production et un serveur de test. En cas de crash important du serveur de production, puis-je restaurer mes bases sur le serveur de test même si l'arborescence de fichiers n'est pas la même ?

Oui c'est tout à fait possible en utilisant l'option WITH MOVE quand tu vas restaurer tes bases et sous condition que ton serveur de test possède la même version que ton serveur de test.

++

[Kropernic]

Oui c'est possible de faire cela. Personnellement je trouve que cela n'est pas une bonne idée. La raison principale est que si quelqu'un par mégarde fait une initialisation du média via la commande backup database with init toutes les sauvegardes seront perdues.

D'instinct, cela me semblait également plus "propre" de séparer les backups de chaque DB sur différents device. Notez que je suis le seul à gérer la DB actuellement. Les risques que quelqu'un effectue un backup database with init sont proches de zéro je pense.

RETAINDAYS /EXPIRATIONDATE permettent de définir une période pendant laquelle on ne peut pas écraser le contenu d'une sauvegarde via l'option INIT. Cependant il faut noter que l'on peut tout à fait rendre invalide le contenu d'un média de sauvegarde via l'option FORMAT.

INIT sert à écraser le contenu d'un média de sauvegarde.

Je vais préciser ma question. Si je fais:

Code :

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

1
2
3
BACKUP DATABASE [DB_NAME]
TO [DEVICE_NAME]
WITH RETAINDAYS = 7, INIT

Est-ce bien comme cela que je dois utiliser la commande pour écraser les sauvegardes de plus de 7 jours ?

Tu peux tout à fait revenir en mode recovery full en prenant soin de faire une sauvegardes du journal des transactions. Maintenant il faut également valider que ta nouvelle stratégie de restauration correspond à ton besoin. Est-ce que ton RPO (s'il existe) exige que tu ne dois pas perdre plus d'une heure de données voir restaurer tes bases au plus proche du crash ? Si tu peux te permettre de restaurer à J-1 il te sera inutile de passer en mode de recovery full si ce n'est que de complexifier ta stratégie de backup.

C'est en effet une question que je me dois de poser à mon chef. C'est juste que que je me dis "si c'est possible, pourquoi s'en priver ?"

Oui c'est tout à fait possible en utilisant l'option WITH MOVE quand tu vas restaurer tes bases et sous condition que ton serveur de test possède la même version que ton serveur de test.

Cool ! J'avais un peu peur de cette réponse. Les versions étant rigoureusement les mêmes, cela ne posera donc pas de problème.

Un tout grand merci pour ces réponses !

P.S. : J'ai ajouté 2 questions le temps que vous écriviez votre message

[KookieMonster]

Bonjour Kropernic,

1. faire toutes les sauvegardes de tes bases de données sur un seul support est très logique. Un serveur dédié à cette tâche fera donc très bien l'affaire. Les logs devront toutefois si possible être sauvegardés sur un autre disque.
2. Si tu gardes les mêmes noms dans ton plan de sauvegarde (ex: backup_lundi.bak, backup_mardi.bak, ...) il faudra effectivement utiliser les options que tu donnes. Je préfère utiliser de nouveaux noms de mon côté.
3. Comme tu le dis, la sauvegarde du journal de transaction permet d'empêcher celui-ci de croitre indéfiniment. Combien de temps prennent tes différentes sauvegardes ? En fonction de celui-ci, tu pourrais éventuellement mettre des sauvegardes complètes la nuit. Si c'est une VLDB (very large database), alors le week-end est plus indiqué, voire même sauvegarder seulement certains groupes de fichiers).
4. Je mettrais tout sur le même de mon côté.
5. La fréquence de backup de l'environnement de test est la même que celle de prod? Tu peux choisir de sauvegarder "à la main" la base de prod et restaurer sur l'environnement de test, ou créer un package SSIS à ce sujet.

En espérant avoir répondu à tes question (et n'avoir pas dit trop de bêtises).
Kookie Monster

[Kropernic]

Bonjour Kropernic,

1. faire toutes les sauvegardes de tes bases de données sur un seul support est très logique. Un serveur dédié à cette tâche fera donc très bien l'affaire. Les logs devront toutefois si possible être sauvegardés sur un autre disque.
2. Si tu gardes les mêmes noms dans ton plan de sauvegarde (ex: backup_lundi.bak, backup_mardi.bak, ...) il faudra effectivement utiliser les options que tu donnes. Je préfère utiliser de nouveaux noms de mon côté.
3. Comme tu le dis, la sauvegarde du journal de transaction permet d'empêcher celui-ci de croitre indéfiniment. Combien de temps prennent tes différentes sauvegardes ? En fonction de celui-ci, tu pourrais éventuellement mettre des sauvegardes complètes la nuit. Si c'est une VLDB (very large database), alors le week-end est plus indiqué, voire même sauvegarder seulement certains groupes de fichiers).
4. Je mettrais tout sur le même de mon côté.
5. La fréquence de backup de l'environnement de test est la même que celle de prod? Tu peux choisir de sauvegarder "à la main" la base de prod et restaurer sur l'environnement de test, ou créer un package SSIS à ce sujet.

En espérant avoir répondu à tes question (et n'avoir pas dit trop de bêtises).
Kookie Monster

1°
Vous parlez de serveur dédié... Vous voulez dire que si mes DB se trouves sur un serveur X, c'est un serveur Y qui doit se charger d'en faire les sauvegardes ? Mes sauvegardes seront effectuées sur un disque réseau en utilisant un chemin UNC. Est-ce cela que vous vouliez dire ?

2°
J'imagine que s'il est possible de mettre plusieurs sauvegardes dans le même device, c'est justement pour éviter la prolifération de fichiers de ce genre. Non ? N'est-il pas plus facile de s'y retrouver lorsqu'on sait que le backup dont on a besoin se trouve dans un fichier bien précis ? Il serait intéressant de connaître les pratiques de chacun à ce niveau.

3°
Nous sommes très loin d'avoir un VLDB ^^. Pour ce qui est du temps des sauvegardes, je pourrai te répondre lorsque j'aurai fait les premières "vraies" sauvegardes. Je n'ai fait que des tests sur les bases du serveur de test pour le moment.

4°
Ok

5°
Pour le moment, le serveur de test n'est pas backuper (je croise les doigts ). Que voulez-vous dire par "sauvegarder à la main" ?

[KookieMonster]

1. C'est le serveur (X) hébergeant SQL Server qui fait la sauvegarde. Il est ensuite possible de l'envoyer vers un autre (Y) afin d'avoir une sauvegarde sur un autre système, si possible dans une salle et/ou lieu différent. Donc je pense à BACKUP DATABASE maBase TO \\monServeur\monrepertoire\monbackup.bak
2. De mon côté, j'ai choisi d'avoir un nom nouveau pour chaque base. Comme je ne conserve pas les bases indefiniment non plus, il me faut les supprimer. Tu peux avoir un travail dédié à cela ou l'intégrer par exemple dans un script de sauvegarde. Mais remplacer les bases est une très bonne (voire meilleure, je laisse d'autres personnes m'en expliquer les avantages) solution également.
3. Si la base n'est pas très grosse, je te conseille de faire une sauvegarde complète la nuit. En cas de pépin, cela sera plus facile à restaurer, et pourra éviter que les bases différentielles ne deviennent encombrantes au fur et à mesure de la semaine.
5. L'option MOVE est dans ton cas la plus pratique car les environnements sont identiques. Dans les cas où la base de test n'a guère besoin d'être mise à jour (ça peut arriver aussi), on peut se permettre de faire depuis la production click droit, sauvegarder... puis restaurer la base depuis ton autre environnement. Mais l'automatisation avec cette option pendant ton backup de nuit (ou du week-end) me semble la plus sage.

[mikedavem]

D'instinct, cela me semblait également plus "propre" de séparer les backups de chaque DB sur différents device. Notez que je suis le seul à gérer la DB actuellement. Les risques que quelqu'un effectue un backup database with init sont proches de zéro je pense.

Les erreurs sont vite arrivées ;-) mais effectivement ca limite la casse ...

Est-ce bien comme cela que je dois utiliser la commande pour écraser les sauvegardes de plus de 7 jours ?

Personnellement je ferai autrement. Je ferai d'une part une tâche de sauvegarde des bases et une seconde tâche de suppression des backups avec une retention de 7 jours.

C'est en effet une question que je me dois de poser à mon chef. C'est juste que que je me dis "si c'est possible, pourquoi s'en priver ?"

Effectivement mais complexifier sa stratégie de sauvegarde + restauration alors qu'on n'en a pas besoin c'est dommage :-)

Nous travaillons actuellement avec SQL SERVER 2005 (edition standard). J'ai bien lu que la compression n'est disponible qu'à partir de la version 2008. Pourtant, quand je consulte les headers d'un device de sauvegardes, il y a bien une colonne intitulée "Compressed". A quoi sert-elle dans ce cas ?

Rien dans ce cas avec SQL Server 2005. La valeur de cette colonne doit être à zéro dans tous les cas.

Est-ce vraiment nécessaire de définir un nom et une description pour les backups ? Il y a de toute façon les informations de la DB sauvegarder et de la date de création du backup (et éventuellement la date d'expiration si elle est précisée).

Non ces options sont optionnelles.

++