Discussion :

[yannick_c4]

Bonjour,

j'aimerai mettre en place cette politique de sauvegarde :

- Arret de la base sql (net stop...)
- Copie des fichier mdf, ldf, ndf avec le logiciel de sauvegarde
- Redemarrage de la base SQL.

Questions :
- Ceci est-il possible ? (est-ce restaurable ?)
- Doit on faire des post/pre opérations (sp_detachs...?)
- Avez vous déjà vu cela chez des grands comptes ?

Cordialement

[elsuket]

Bonjour,

C'est possible mais absurde, parce qu'en plus de supprimer tout accès des utilisateurs de le temps de la copie des fichiers de la base de données, vous perdrez tout le cache de données et les statistiques collectées par SQL Server pour optimiser son fonctionnement ...
Client grand compte ou pas, je doute qu'il soit content d'une coupure d'accès aux base de données : c'est le cœur de l'entreprise !

Il existe pourtant une instruction qui parle d'elle-même : BACKUP DATABASE.
Elle ne vous oblige pas à arrêter la base de données ou l'instance, vous permet de conserver l'intégrité de la base de données, et surtout vous permet de la restaurer à un point dans le temps, avec l'option STOPAT.

Il est de plus possible, à l'aide d'un job de l'agent SQL Server, d'effectuer ces sauvegardes automatiquement au cours de la journée, soit avec une procédure stockée si votre stratégie de sauvegarde est très simple, soit avec un plan de maintenance.
Dans les deux cas vous pourrez suivre vos sauvegardes, savoir quand elles ont été faites, combien de temps elles ont duré, quand aura lieu la prochaine sauvegarde, et connaître la taille du fichier de sauvegarde (ce qui en plus vous permettra de suivre l'évolution de la taille de votre base de données).

Vous l'aurez donc compris : vous avez tout avantage à ne pas faire ce que vous cherchez à faire.
Je vous invite à un peu de lecture :

- Présentation des stratégies de sauvegarde et de restauration dans SQL Server

- Déplacement, sauvegardes et restauration de bases sous MS-SQL Server par Fabien Celaia

- MS SQL Server et les problématiques du journal de transaction, par SQLPro

- Suivre les sauvegardes de base de données avec MSDB

@++

[yannick_c4]

Re,

merci pour votre réponse.

1a. pour les interruption de service et le fait que la base ne soit pas dispnonile, je m'en fiche, j'ai des plages de maintenance la nuit.

1b. de plus, en géneral on arrete les applications en plus de la base pour sauvegarder.

2. Le backup database impose d'avoir une double volumétrie quasiment (si je pars du principe d'une sauvegarde full). Ceci n'est pas possible dans certain cas (taille d'une base de plusieurs To)...

>Dans les deux cas vous pourrez suivre vos sauvegardes, savoir quand elles >ont été faites, combien de temps elles ont duré, quand aura lieu la >prochaine sauvegarde, et connaître la taille du fichier de sauvegarde (ce qui >en plus vous permettra de suivre l'évolution de la taille de votre base de >données).
Certes, mais j'ai déjà mon outils de sauvegarde et son reporting qui me dit cela.

Idéalement, vous proposez le scénario suivant :

- Sauvegarde de la base avec BACKUP database sur un fichier en local
- Sauvegarde du fichier .bak avec l'outil de sauvegarde
- Suppression du fichier .bak

Ceci impose un ordonnanceur pour ces tâches. Imaginons que la cmd BACKUP DATABASE plante, l'outil de sauvegarde viendra chercher un fichier "pourri".

En fait, les bases SQL Serveur ne sont en général pas critiques. De plus en plus de produits prépackagés viennent avec une base SQL Serveur Express ou demande une version Entreprise. Je souhaiterais juste trouver une solution simple pour toutes ces petites bases (<5 Go) qui fleurissent dans le SI et que personne ne pense à backuper.

Une arret de base est beaucoup plus simple que de créer un plan de maintenance, devinner à quelle heure la sauvegarde va se terminer, lancer l'outils de sauvegarde en fonction de cela...
En cas de reconstruction apres destruction du datacenter, il faut restaurer les .bak, ensuite restraurer la base...

Avec ma solution, il faut juste restaurer les fichiers.

Qu'en pensez vous ?

Merci.

[elsuket]

1a. pour les interruption de service et le fait que la base ne soit pas dispnonile, je m'en fiche, j'ai des plages de maintenance la nuit.

Et alors ? Si on souhaite reconstruire les index, on fait comment ?

2. Le backup database impose d'avoir une double volumétrie quasiment (si je pars du principe d'une sauvegarde full). Ceci n'est pas possible dans certain cas (taille d'une base de plusieurs To)...

C'est la même chose si vous copiez la base de données, vous dupliquez les fichiers, en plus le BACKUP copie seulement les pages de données qui ne sont pas vides.
Ce n'est pas le cas quand on copie les fichiers de base de données.

Idéalement, vous proposez le scénario suivant :

- Sauvegarde de la base avec BACKUP database sur un fichier en local
- Sauvegarde du fichier .bak avec l'outil de sauvegarde
- Suppression du fichier .bak

Je ne vous ai proposé aucune stratégie de sauvegarde parce que je ne connais pas les contraintes du métier de votre entreprise ou de votre client.

Je ne vois pas non plus l'intérêt de sauvegarder la base de données dans un fichier pour ensuite supprimer celui-ci ... comment la restaurerait-on en cas de crash ?

Ceci impose un ordonnanceur pour ces tâches. Imaginons que la cmd BACKUP DATABASE plante, l'outil de sauvegarde viendra chercher un fichier "pourri".

A vous de le vérifier en fin de sauvegarde avec l'instruction RESTORE VERIFYONLY.

Une arret de base est beaucoup plus simple que de créer un plan de maintenance, devinner à quelle heure la sauvegarde va se terminer, lancer l'outils de sauvegarde en fonction de cela...

Faire les choses proprement et finement a toujours pris du temps
Je vous accorde que c'est plus simple, mais vous n'avez aucune garantie de l'intégrité de votre base de données.
Sauvegarder des base de données d'une aussi petite taille prend moins de 5 minutes
Vous pouvez "génériser" votre plan de maintenance ou votre procédure stockée de sauvegarde de sorte qu'elle exécute la sauvegarde pour toutes les base de données utilisateur de l'instance en cours (vue système sys.databases)

Qu'en pensez vous ?

Vous vous doutez que je suis contre

@++

[SQLpro]

Il y a beaucoup d'erreur et une méconnaissance grave de ce qu'est la maintenance d'un base de données. Pensez que DBA c'est un vrai métier... Je vous renvoie à ce qu'en dit Wikipedia :
http://fr.wikipedia.org/wiki/Adminis...e_donn%C3%A9es

Alors reprenons...

Re,

merci pour votre réponse.

1a. pour les interruption de service et le fait que la base ne soit pas dispnonile, je m'en fiche, j'ai des plages de maintenance la nuit.

Le problème c'est que faisant cela vous perdez le contenu de tous les caches et de toutes les statistiques d'exécution.

• Pour les caches, cela veut dire que toutes les requêtes qui vont arriver mettrons environ 1000 (je dit bien MILLE) fois plus de temps après l'arrêt du serveur...
• Pour les statistiques, d'exécution cela veut sir que vous ne pourrez pas remonter dans l'historique de la santé du serveur afin de savoir ce qui s'est passé lors d'un incident.

Je comprend que vous puissiez vous en fiche mais si j'étais votre boss, je vous flanquerais à la porte avec un politique aussi absurde !

Je vous invite donc à lire ce que sont les sauvegarde de SQL Server à l'aide de l'article que j'ai rédigé à cet effet.

En sus l'arrêt du serveur et la copie des fichiers des bases ne garantie en aucune manière que la restauration se passera bien. En effet lors du shutdown du serveur les écritures dans le JT ne sont pas systématiquement reportées.
Si vous voulez réellement faire cette chose idiote, alors il faut finaliser les écritures en faisant un détachement des fichiers de la base (ce qui a l'autre énorme avantage de conserver les stats d'exécution de SQL Server, mais de quand même vider le cache pour la base détachée).

1b. de plus, en géneral on arrete les applications en plus de la base pour sauvegarder.

Ceci est un autre problème et il n'y a pas d'autre solution pour le code !

2. Le backup database impose d'avoir une double volumétrie quasiment (si je pars du principe d'une sauvegarde full). Ceci n'est pas possible dans certain cas (taille d'une base de plusieurs To)...

Ou avez vous lu ça ? Le backup même full est souvent bien moins grand que la base incluant données et JT. De plus vous pouvez compresser le backup depuis la version 2008.
Enfin vous pouvez paralléliser la sauvegarde sur plusieurs système à la fois afin d'accélérer le traitement et pour les VLDB. (sauvegarde réparties).

[...]

Ceci impose un ordonnanceur pour ces tâches. Imaginons que la cmd BACKUP DATABASE plante, l'outil de sauvegarde viendra chercher un fichier "pourri".

SQL Server intégre un ordonnanceur de nom SQL Agent qui de plus possède un opérateur d'alerte de fail safe en cas de dysfonctionnement.
De plus vous pouvez vérifier l'état de votre sauvegarde en ligne pendant la sauvegarde comme après exécution à l'aide de
RESTORE VERIFYONLY
Quand à un éventuel plantage il vous sera notifié et journalisé...

En fait, les bases SQL Serveur ne sont en général pas critiques. De plus en plus de produits prépackagés viennent avec une base SQL Serveur Express ou demande une version Entreprise. Je souhaiterais juste trouver une solution simple pour toutes ces petites bases (<5 Go) qui fleurissent dans le SI et que personne ne pense à backuper.

Il suffit tout simplement d'utiliser dans ce cas un device afin d'empiler toutes les sauvegardes (y compris les bases système qui sont vitalement importantes) comme je l'indique dans cet article :
http://blog.developpez.com/sqlpro/p5...ur-les-sauveg/
Et pour toutes les bases d'un seul coup :
http://blog.developpez.com/sqlpro/p6...es-de-donnees/

Une arret de base est beaucoup plus simple que de créer un plan de maintenance, devinner à quelle heure la sauvegarde va se terminer, lancer l'outils de sauvegarde en fonction de cela...
En cas de reconstruction apres destruction du datacenter, il faut restaurer les .bak, ensuite restraurer la base...

Je crois que vous n'avez rien compris !!! D'où tenez vous cette double restauration ???

Avec ma solution, il faut juste restaurer les fichiers.

Qu'en pensez vous ?

Sincèrement ? De la merde... !

A +

[yannick_c4]

Je comprend que vous puissiez vous en fiche mais si j'étais votre boss, je vous flanquerais à la porte avec un politique aussi absurde !

Mon boss pense pareil que moi Cette solution est déjà en place pour les bases Oracle.

Je crois que vous n'avez rien compris !!! D'où tenez vous cette double restauration ???

Si SQL Serveur sauvegarde ses bases dans un .bak, si je veux externaliser ce fichiers sur un site secondaire, la restauration va se passer en 3 étapes :
- Restauration du système
- Restauration du .bak
- Restauration des bases depuis le .bak

Imaginons maintenant que j'éteigne les bases SQL (avec un sp_detach pour bien synchroniser les datas) : je peux juste sauvegarder mon systèmes (c:\), mon moteur (d:\) et mes datas (e:\). En cas de restauration à grande echelle cela va plus vite.

Ou avez vous lu ça ? Le backup même full est souvent bien moins grand que la base incluant données et JT. De plus vous pouvez compresser le backup depuis la version 2008.
Enfin vous pouvez paralléliser la sauvegarde sur plusieurs système à la fois afin d'accélérer le traitement et pour les VLDB. (sauvegarde réparties).

[...]

Nule part, c'était une supposition (fausse apparement!)

je suis très interessé par les méthodes de sauvegarde de SQL Serveur 2008. J'ai une assez grosse base (~20 To) avec et je ne sais absolument pas comment la sauvegarder quotidiennement.

Je vous invite donc à lire ce que sont les sauvegarde de SQL Server à l'aide de l'article que j'ai rédigé à cet effet.

Je le lirai.

SQL Server intégre un ordonnanceur de nom SQL Agent

OK, donc SQL agent est capable de demander à l'application de s'éteindre (en vérifiant toutes les contraintes fonctionnelles applicatives), de lancer sa sauvegarde, de lancer l'outil de sauvegarde pour l'externalisation, de redemarrer l'applicatif, tout cela en vérifiant toutes les contraintes, en proposant un reporting sur toutes les bases... ?

Le probleme d'utiliser SQL pour se sauvegarde impose une "double" sauvegarde. Une fois par SQL et une fois par l'outil de sauvegarde.
L'outil de sauvegarde gère lui même les différentes versions...

Et il est impossible (financierement) de sauvegarder la base depuis l'outils de sauvegarde (comme le fait la plus part des outils de sauvegarde)...

Sincèrement ? De la merde... !

La sincerité a du bon !

[elsuket]

Si SQL Serveur sauvegarde ses bases dans un .bak, si je veux externaliser ce fichiers sur un site secondaire, la restauration va se passer en 3 étapes :
- Restauration du système
- Restauration du .bak
- Restauration des bases depuis le .bak

Non :

- Restauration du système
- Restauration des bases depuis le .bak, même si celui-ci est compressé par SQL Server 2008.

Imaginons maintenant que j'éteigne les bases SQL (avec un sp_detach pour bien synchroniser les datas) : je peux juste sauvegarder mon systèmes (c:\), mon moteur (d:\) et mes datas (e:\). En cas de restauration à grande echelle cela va plus vite.

Qu'est-ce qui vous empêche de faire la sauvegarde des disques C et D si vous faites le BACKUP ?

je suis très interessé par les méthodes de sauvegarde de SQL Serveur 2008. J'ai une assez grosse base (~20 To) avec et je ne sais absolument pas comment la sauvegarder quotidiennement.

Vous pouvez par exemple faire une sauvegarde complète toutes les semaines, un différentielle tous les jours, un une du fichier du journal de transactions selon les contraintes du métier de votre entreprise.

OK, donc SQL agent est capable de demander à l'application de s'éteindre (en vérifiant toutes les contraintes fonctionnelles applicatives), de lancer sa sauvegarde, de lancer l'outil de sauvegarde pour l'externalisation, de redemarrer l'applicatif, tout cela en vérifiant toutes les contraintes, en proposant un reporting sur toutes les bases... ?

Mais pourquoi donc voulez-vous éteindre l'applicatif ?
Les sauvegardes avec l'instruction BACKUP se font à chaud, sans interruption de service !

Le probleme d'utiliser SQL pour se sauvegarde impose une "double" sauvegarde. Une fois par SQL et une fois par l'outil de sauvegarde.

Pourquoi se servir d'un outil de sauvegarde quand vous avez déjà un outil intégré à ce que vous avez déjà payé en licence SQL Server pour le faire ?
Votre outil de sauvegarde ne permet-il pas de spécifier les disques à sauvegarder ?

Mon boss pense pareil que moi Cette solution est déjà en place pour les bases Oracle.

J'espère que vous ne travaillez pas pour une banque par exemple, qui ne peut pas prendre en compte une interruption de service.

@++

[SQLpro]

Mon boss pense pareil que moi Cette solution est déjà en place pour les bases Oracle.

Et bien c'est totalement navrant et prouve que votre entreprise n'a aucune culture bases de données ! Je vous plaint le jour ou vous aurez un gros crash !

Si SQL Serveur sauvegarde ses bases dans un .bak, si je veux externaliser ce fichiers sur un site secondaire, la restauration va se passer en 3 étapes :
- Restauration du système
- Restauration du .bak
- Restauration des bases depuis le .bak

Restaurer un système n'a pas d'intérêt car il y a fort peu de chance que le jour ou vous ayez à faire cela vous soyez EXACTEMENT sur le même type de machine...A moins que ce soit des VM,et là c'est autre chose (pire pour les performances des SGBDR que tout mais bon... http://blog.developpez.com/sqlpro/p8...irtualisation/

Donc vous partez d'emblez sur une fausse piste... 95 % des restaurations en pratique sont due à des sinistres graves comme incendie, dégât des eaux... sur lequel les machines sont HS et il faut prendre de nouveau serveurs, car je suppose que vous avez quand même une solution de haute dispo ?

Imaginons maintenant que j'éteigne les bases SQL (avec un sp_detach pour bien synchroniser les datas) : je peux juste sauvegarder mon systèmes (c:\), mon moteur (d:\) et mes datas (e:\). En cas de restauration à grande echelle cela va plus vite.

Votre hypothèse étant fausse au départ....

Apparament vous avez peu d'expérience en matière de secours...

je suis très interessé par les méthodes de sauvegarde de SQL Serveur 2008. J'ai une assez grosse base (~20 To) avec et je ne sais absolument pas comment la sauvegarder quotidiennement.

Vous n'étes pas obligé de tout sauvegardé. Si votre base est bien organisée (gestion des fichiers et des groupes de fichiers adéquats, alors vous pouvez faire des sauvegardes partielles à différentes fréquences. Par exemple pour une base OLTP de text mining, je sauvegarde les storage actif toutes les nuits (15% du volume de la base) et les index statiques un fois pas mois. Et c'est une base de 2 To...

OK, donc SQL agent est capable de demander à l'application de s'éteindre (en vérifiant toutes les contraintes fonctionnelles applicatives), de lancer sa sauvegarde, de lancer l'outil de sauvegarde pour l'externalisation, de redemarrer l'applicatif, tout cela en vérifiant toutes les contraintes, en proposant un reporting sur toutes les bases... ?

Pourquoi voulez-vous "éteindre" votre application ? Un SGBDR sauvegarde à chaud, même quand des transactions sont en cours, cela n'a aucune importance !
Encore une fois votre culture DBA est nullissime ! Formez vous !!!

Le probleme d'utiliser SQL pour se sauvegarde impose une "double" sauvegarde. Une fois par SQL et une fois par l'outil de sauvegarde.
L'outil de sauvegarde gère lui même les différentes versions...

Là je ne comprend même plus de quoi vous parlez !

Et il est impossible (financierement) de sauvegarder la base depuis l'outils de sauvegarde (comme le fait la plus part des outils de sauvegarde)...

Rien compris ...

A +