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 +

[mikedavem]

Personnellement je n'implémenterais pas cette stratégie de sauvegarde pour les raisons suivantes :

- Même si vous n'avez aucune contrainte de performance, de disponibilité vis à vis de vos utilisateurs, vous multipliez les chances que votre processus génére une erreur. En effet regardez le nombre d'étapes qu'il faudra implémenter pour votre sauvegarde :

1 - arrêter vos applications
2- arrêter sqlserver ou faire un sp_detach
3- copier vos fichiers via votre utilitaire de sauvegarde
4- faire un sp_attach / ou redémarrer sqlserver
5- redémarrer vos applications.

En procédant à une sauvegarde native via SQL Server avec une planification vous réduisez considérablement les efforts d'administrations :

1 - Sauvegarde et génération fichier .BAK
2- Copie fichier BAK via votre utilitaire


- Concernant votre volumétrie comme le confirme SQL Pro pour votre base de 20To vous avez effectivement intérêt à réfléchir à une stratégie de sauvegarde par groupes de fichiers et fichiers afin de ne sauvegarder que l'essentiel. Mais encore une fois avec SQL SErver 2008 pensez à la compression des backups....

- A la restauration de votre système vous n'irez pas spécialement plus vite :

Avec votre méthode :
- Restauration système
- Restauration des bases via sp_attach

Avec l'autre méthode
- Restauration système
- Restauration des bases via les .BAK

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

Marrant un collègue qui travaille avec Oracle fait exactement la même chose... je lui ai dit qu'il se fait bien c....
D'ailleurs sa principale préoccupation le matin est de savoir si les appli ont bien redemarré .... dommage quand même .... moi je prends le café et je suis serein le matin (C'est un peu exagéré mais bien qu'il existe des systèmes de contrôle je trouve cela plus lourd que d'implémenter une sauvegarde à chaud qui plus est existe en natif ...)

Enfin sachez qu'il existe une solution sans arrêter SQL Server en activant le service SQL Writer et qui fonctionne avec VSS qui permet la copie à chaud des fichiers de bases .. A creuser car cette solution comporte certains restrictions comme la non prise en charge des sauvegardes du JT et risque de ne pas convenir à vos besoins.

++

[yannick_c4]

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/

Les gros outils du marche permettent de restaurer sur du materiel differents.
BESR, TSM... ou avec des outils permettent de le faire.
Il ne faut pas etre EXACTEMENT sur le meme type de machine, pour un windows par exemple, il suffit d'injecter les drivers de la carte RAID avant le boot du windows si l'on restaure sur un materiel different. Le reste n'empeche pas le boot (drivers video, on s'en fou sur un serveur, drivers reseau, carte FC, peut etre reinstalles apres en appliquant un ensemble un bundle de drivers du constructeur.

Pour un Linux, pareil.
Pour un HP-UX, AIX, il n'existe pas x materiels differents de toute facon.

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 ?

Il existe des services chez HP, IBM, Sunguard... qui dispose de materiels et de reconstruction du site apres crash. Pas besoin d'acheter des nouveaux serveurs.

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

Exact.

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...

Et vous sauvegardez ou ? en local ? sur un lecteur de bande attache en direct ? via le LAN ? via le SAN ?

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 !!!

La plus part des vraies sauvegardes sont beaucoup plus compliquees que cela.
Elles impliquent des mecanismes de replication synchrones d'espaces de stockage, quand on veut sauvegarder on detache une des copie et on la monte sur un serveur qui lui est sauvegarde.

Merci du debat !

[yannick_c4]

Marrant un collègue qui travaille avec Oracle fait exactement la même chose... je lui ai dit qu'il se fait bien c....
D'ailleurs sa principale préoccupation le matin est de savoir si les appli ont bien redemarré .... dommage quand même .... moi je prends le café et je suis serein le matin (C'est un peu exagéré mais bien qu'il existe des systèmes de contrôle je trouve cela plus lourd que d'implémenter une sauvegarde à chaud qui plus est existe en natif ...)

Enfin sachez qu'il existe une solution sans arrêter SQL Server en activant le service SQL Writer et qui fonctionne avec VSS qui permet la copie à chaud des fichiers de bases .. A creuser car cette solution comporte certains restrictions comme la non prise en charge des sauvegardes du JT et risque de ne pas convenir à vos besoins.

OK, mais Oracle s'engage sur sa sauvegarde en natif a chaud sans son outils RMAN ?
Microsoft s'engage sur sa coherence de sa sauvegarde a chaud ?

[yannick_c4]

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

Je parle de base SQL serveur, vous connaissez un grand compte bancaire qui fait tourner ses bases critiques sur SQL Serveur ?

Je ne veux pas denigrer SQL Serveur, nous avons des bases SQL de plusieurs dizaines de tera. mais rien d'hyper / super / hypra critique.

Je veux parler pour les petites bases SQL qui viennent embarquees avec des produits comme Backup Exec Recovery, HP System Insight Manager, tous les outils Microsoft (SCOM, MOM, SCVMM...), VMware Virtual Center, tous les petits outils de reporting, les serveurs antivirus...
Dans un gros SI fleurissent des petites bases SQL Serveur qui ne sont pas critiques en soit et ou les perfmances on s'en tampone royalement... mais il faut les sauvegarder proprement.
Mettre en place des sql cmd BACKUP est (je pense) plus compliquee pour chaque base (il faut disposer d'un login / mot de passe, ce qui n'est pas forcement evident sur des bases embarquees..., il faut savoir quelle base sauvegardee...)
Je veux juste trouver une solution facilement industrialisable.

A mon avis, ceci est assez simple :

Voici mon script executee via mon ordonnanceur (taches planifiees ou $u/Ctrl m...)

net stop service applicatif
net stop SQLServeur
execution du logiciel de sauvegarde qui vient chercher les bases
net start SQL Serveur
net start service applicatif

L'arret de l'applicatif n'est certes pas forcement obligatoire, mais ceci est facilement industrialisable et marche a tous les coups.

- Concernant votre volumétrie comme le confirme SQL Pro pour votre base de 20To vous avez effectivement intérêt à réfléchir à une stratégie de sauvegarde par groupes de fichiers et fichiers afin de ne sauvegarder que l'essentiel. Mais encore une fois avec SQL SErver 2008 pensez à la compression des backups....

OK, est ce que ceci peut marcher si
- votre serveur est deja ras la guelle en termes d'espace disque. Il n'est abosolument impossible d'en rajouter.
- votre serveur est en DMZ, implique que les flux LAN de sauvegarde passent par un firewall (ce qui n'est pas forcement la meilleure idee, mais dans la plus part des cas, c'est comme cela. (pas de VLAN de sauvegarde dedie))
- Le cycle de sauvegardee est court (8h)

Enfin sachez qu'il existe une solution sans arrêter SQL Server en activant le service SQL Writer et qui fonctionne avec VSS qui permet la copie à chaud des fichiers de bases .. A creuser car cette solution comporte certains restrictions comme la non prise en charge des sauvegardes du JT et risque de ne pas convenir à vos besoins.

Mon parc Windows et SQL Serveur est ultra classique :
+ Windows : Cela va de NT4 qui boot du disquette au dernier w2008 x64
+ SQL : de SQL 6.5 a 2008

Donc VSS, adieu Je veux une solution facile, simple et industrialisable

[SQLpro]

Je parle de base SQL serveur, vous connaissez un grand compte bancaire qui fait tourner ses bases critiques sur SQL Serveur ?

La société générale par exemple.

Dans les site web de vente en lgne les plus important on trouve essentiellement du SQL Server : Fnac.com, ooshop,

Je ne veux pas denigrer SQL Serveur, nous avons des bases SQL de plusieurs dizaines de tera. mais rien d'hyper / super / hypra critique.

Les plus grosses bases que je connaisse en SQL Serveur font 20 To

Je veux parler pour les petites bases SQL qui viennent embarquees avec des produits comme Backup Exec Recovery, HP System Insight Manager, tous les outils Microsoft (SCOM, MOM, SCVMM...), VMware Virtual Center, tous les petits outils de reporting, les serveurs antivirus...
Dans un gros SI fleurissent des petites bases SQL Serveur qui ne sont pas critiques en soit et ou les perfmances on s'en tampone royalement... mais il faut les sauvegarder proprement.
Mettre en place des sql cmd BACKUP est (je pense)

Le problème est que vous pensez mal et vous n'avez aucune culture de DBA. Commencez par vous former car là c'est le dialogue de sourd. On ne peut pas résumer n7h de cours sur la sauvegardes et la restauration en 3 échanges de posts...

plus compliquee pour chaque base (il faut disposer d'un login / mot de passe, ce qui n'est pas forcement evident sur des bases embarquees..., il faut savoir quelle base sauvegardee...)
Je veux juste trouver une solution facilement industrialisable.

et bien justement, le script que je vous ais indiqué est parfaitement adéquat pare ce que générique.

mais vous êtes a ce point borné que vous ne lisez même pas les articles que l'on vous donne !!!

A mon avis, ceci est assez simple :

Voici mon script executee via mon ordonnanceur (taches planifiees ou $u/Ctrl m...)

net stop service applicatif
net stop SQLServeur
execution du logiciel de sauvegarde qui vient chercher les bases
net start SQL Serveur
net start service applicatif

L'arret de l'applicatif n'est certes pas forcement obligatoire, mais ceci est facilement industrialisable et marche a tous les coups.

Vous radotez vous nous avez déjà présenté votyre solution immonde ! Vous parlez à vous même ?

OK, est ce que ceci peut marcher si
- votre serveur est deja ras la guelle en termes d'espace disque. Il n'est abosolument impossible d'en rajouter.
- votre serveur est en DMZ, implique que les flux LAN de sauvegarde passent par un firewall (ce qui n'est pas forcement la meilleure idee, mais dans la plus part des cas, c'est comme cela. (pas de VLAN de sauvegarde dedie))
- Le cycle de sauvegardee est court (8h)

1) vous pouvez sauvegardez sur une ressources externe au serveur à partir de la comande BACKUP et même directement sur bande
2) vous pouvez créer un lot SSIS qui fait la sauvegarde et la pousse par une tâche FTP ou vous le souhaitez

Mon parc Windows et SQL Serveur est ultra classique :
+ Windows : Cela va de NT4 qui boot du disquette au dernier w2008 x64
+ SQL : de SQL 6.5 a 2008

Donc VSS, adieu Je veux une solution facile, simple et industrialisable

Donc BACKUP éventuellement encapsulé dans un lot SSIS.

A +

[yannick_c4]

mais vous êtes a ce point borné que vous ne lisez même pas les articles que l'on vous donne !!!

Si !

Je vais tenter votre solution.

Je reviendrai d'ici 1 an avec un retours d'experience...

Cordialement

[mikedavem]

Microsoft s'engage sur sa coherence de sa sauvegarde a chaud ?

Bien sûr et c'est cela bien l'intêrêt ne trouvez vous pas ? ... SQL Server a tout ce qu'il faut en natif pour sauvegarder ses bases à chaud et de manière cohérente.

Je parle de base SQL serveur, vous connaissez un grand compte bancaire qui fait tourner ses bases critiques sur SQL Serveur ?

Il me semble bien que pour la caisse d'éparge c'est le cas du moins pour l'une de ses applications (il me semble) ... avec des topologies cluster et mirroring

Là ou je travaille (compte important) l'application critique tourne sur du SQL Server ... (j'entends par critique du 24/24H, 7j/7 , 365j par an)

Dans un gros SI fleurissent des petites bases SQL Serveur qui ne sont pas critiques en soit et ou les perfmances on s'en tampone royalement... mais il faut les sauvegarder proprement.

Détrompez vous, c'est quand les problèmes arrivent (donc trop tard) qu'on commence à regarder les performances ... "avant ca marchait et pourquoi ca ne fonctionne plus maintenant ?" ... J'ai dû auditer 2 applications pour mettre en place des plans de maintenance adéquates pour qu'elles refonctionnent normalement. A l'orgine ... on s'en cognait des performances (un logiciel d'antivirus était concerné et bientôt je sens que VM Center va arriver ...)

Mettre en place des sql cmd BACKUP est (je pense) plus compliquee pour chaque base (il faut disposer d'un login / mot de passe, ce qui n'est pas forcement evident sur des bases embarquees..., il faut savoir quelle base sauvegardee...)
Je veux juste trouver une solution facilement industrialisable.

Iil vous faudra également un login et un mot de passe pour détacher proprement vos bases et savoir quelles bases sont à détacher .. cela reviendra au même je crois ... Je comprends votre souci d'industrialisation mais l'appliquer aux sauvegardes de bases de données n'est à mon avis pas une chose aisée ... Je pense que dans votre cas générer des modèles de procédures de sauvegarde en fonction de critères que vous aurez choisi (application critique, bases à grosses volumétrie, base non critique) me paraît plus judicieux .. vous pourez par exemple créer des templates SQL de sauvegarde etc ou encore utilisez la procédure donnée par SQL Pro et tout à fait générique ... qu'en pensez vous ?

- votre serveur est deja ras la guelle en termes d'espace disque. Il n'est abosolument impossible d'en rajouter.

Vous avez une base de 20To... J'ose espérer que vous pouvez prévoir un budget pour de la place disque ... mais vous pouvez procéder à un backup sur une ressource distante ... cela est tout à fait possible

- votre serveur est en DMZ, implique que les flux LAN de sauvegarde passent par un firewall (ce qui n'est pas forcement la meilleure idee, mais dans la plus part des cas, c'est comme cela. (pas de VLAN de sauvegarde dedie))

En DMZ votre base de 20To ? He be ... quoi qu'il en soit vous avez intérêt à ne sauvegarder que l'essentiel et à compresser vos backups avec 2008 en local et de transférer dans un second temps vos sauvegardes pour éviter des flux réseaux trop importants.

-

Le cycle de sauvegardee est court (8h)

Encore une fois réfléchissez bien à votre stratégie de sauvegarde pour ce type de base et en fonction de votre cycle de sauvegarde ... Il ne faut pas oublier que votre base hébergera de plus en plus de données et que plus les temps de sauvegardes seront de plus en plus long alors que le cycle de sauvegarde lui sera tjrs le même.

++

[elsuket]

Je citerai Chevallier et Laspalès pour parler des sauvegardes de fichiers de base de données qui sont plus rapides que les sauvegardes que l'on peut faire avec BACKUP :

Y'en a qu'ont essayé, ils ont eu des problèmes ... cela dit, il est très rapide

@++

[yannick_c4]

Iil vous faudra également un login et un mot de passe pour détacher proprement vos bases et savoir quelles bases sont à détacher .. cela reviendra au même je crois ... Je comprends votre souci d'industrialisation mais l'appliquer aux sauvegardes de bases de données n'est à mon avis pas une chose aisée ... Je pense que dans votre cas générer des modèles de procédures de sauvegarde en fonction de critères que vous aurez choisi (application critique, bases à grosses volumétrie, base non critique) me paraît plus judicieux .. vous pourez par exemple créer des templates SQL de sauvegarde etc ou encore utilisez la procédure donnée par SQL Pro et tout à fait générique ... qu'en pensez vous ?

Effectivement il faudra un login/pass pour detacher la base

je vais tenter sa procedure stockee.

Vous avez une base de 20To... J'ose espérer que vous pouvez prévoir un budget pour de la place disque ... mais vous pouvez procéder à un backup sur une ressource distante ... cela est tout à fait possible

Non, pas de budget.

Pour le backup sur ressources distantes c'est complique. Le moyen ideal serait de mettre une instance de serveur de sauvegarde dans la DMZ. mais, pareil, trop risque, pas de budget.

En DMZ votre base de 20To ? He be ... quoi qu'il en soit vous avez intérêt à ne sauvegarder que l'essentiel et à compresser vos backups avec 2008 en local et de transférer dans un second temps vos sauvegardes pour éviter des flux réseaux trop importants.

Je vais voir pour les sauvegardes compresses.

[SQLpro]

j'ai oublié de vous dire qu'en matière critique de bases de données, l'une des plus sensible en France est celle des pompiers de Paris (gestion des appels d'urgences).
Au vu des tests de sécurité et de la fiabilité jugée aujourd'hui supérieurs à celle d'Oracle, ils ont opté pour cette plateforme depuis les débuts de la version 2005.

A +