Discussion :

[Ikebukuro]

Salut,

Quand je fais un backup avec SSMS, j'ai une fenêtre avec plein d'options que j'ai du mal à cerner. Il s'agit, ci-dessous, de la partie "Overwrite Media".

Ce que je comprends c'est que, chaque fois que je fais un backup full de ma base, un nouveau fichier .bak est créé. Avec les options choisies dans la fenêtre, le nouveau fichier .bak créé ira dans un backup set existant: on est OK?
Comment faire pour que ce .bak aille dans un NOUVEAU backup set SANS perdre aucun des backup sets déjà existants? Déjà, est-ce que ma question est pertinente, j'avoue avoir un peu de mal à voir la hiérarchie entre Media family, Media set, backup set etc etc
Les options "Overwrite all existing backup sets" et "Backup to a new media set, and erase all existing backup sets" me font très peur : on est d'accord pour dire que si je les utilise, tous mes backup sets précédents sont supprimés donc je n'ai plus aucune sauvegarde sauf celle que je vais faire?



Merci pour vos retours

[mikedavem]

Hello Ikebukuro,

Si tu passes par l'interface graphique, la section Overwrite Media te permet de définir la politique d'initialisation du média de destination.
Par défaut, l'option append correspond au paramètre NOINIT de la commande BACKUP DATABASE, ce qui signifie que chaque fois que tu feras une sauvegarde, celui-ci sera ajouté au média de destination. Si tu décides de réécrire le média, tu utiliseras le paramètre INIT et dans ce cas, le média de destination sera effacé avant que ta sauvegarde soit écrite.

Personnellement, je n'utilise jamais l'écriture des sauvegardes dans un seul média car cela peut devenir problématique si celui-ci venait à être perdu ou corrompu. Tout les sauvegardes contenues dans le média seraient alors perdues. Je préfère passer par un média unique par sauvegarde (backup set) mais il faut passer par scrit T-SQL pour rendre le média unique ou utiliser des outils largement utilisés par la communauté SQL Server comme Ola Hallengren.

++

[Ikebukuro]

Je te remercie pour ta réponse mais celle-ci ne me plait pas du tout... si je comprends bien, SSMS est bien plus pauvre que T-SQL pour les backups restore? A vrai dire je ne suis pas surpris mais cela ne m'amuse pas, ça complexifie les choses : idéalement j'aurais voulu tout faire en SSMS, être guidé mais bon... il va falloir que je grimpe d'un niveau!

[mikedavem]

Je me suis peut être mal exprimé mais non SSMS n'est pas du tout pauvre dans le sens où tu peux réaliser un bon nombre d'opérations que tu pourrais faire en T-SQL.
D'ailleurs tu as la possibilité d'obtenir le script des actions que tu exécutes depuis SSMS.

Mon propos était plutôt autour du rôle de SSMS dans ce contexte. Si tu cherches à réaliser des backups "one-shot" alors SSMS conviendra bien.
En revanche, si ton but est de répéter cette opération et de la planifier il faudra alors te tourner vers d'autres solutions:

- Les plans de maintenance SQL Server que tu peux créées depuis SQL Server pour faire des backups
- Des scripts T-SQL que tu exécuteras dans des jobs SQL Server via l'agent SQL (scheduler built-in SQL Server)

Dans le 2ème cas, soit tu écriras tes propres scripts, soit tu te regarderas probablement des outils de la communauté comme celui-ci cité précédemment.

++