dans le cadre d'installer SP1 de wss 3 et pour plus de sécurité j'ai lu
qu'il faut :
*******************************************
Faites toujours un backup de votre plateforme
- Stsadm –o backup pour la plateforme SharePoint
- Backup des bases SQL, notamment celles de configuration et
d'administration.
- Backup des serveurs avec des outils adaptés.
********************************************
mes questions sont:
1- est ce que "stsadm -o backup -directory c:\**** -backupmetod full"
équivaut à : {- Stsadm –o backup pour la plateforme SharePoint
- Backup des bases SQL, notamment celles de configuration et
d'administration. }
ou il y a un autre moyen meilleur de faire le backup des bases sql?????????
2- est ce que une image disque est équivalente à "Backup des serveurs avec
des outils adaptés. "?????
Il est préférable de s'en tenir au backup classique via STSADMIN. Le backup SQL s'avère avantageux lorsque les DB sont très grandes: le backup/restore SQL devient alors beaucoup plus rapide que via STSADM, tout cela sans impacter la couche applicative.
Sachez que STSADM, pour les bases de données de contenu, réalise tout simplement... un backup SQL full ou differentiel, piloté à distance. D'ailleurs, il vous est même possible de remonter un backup de STSADM simplement avec SQL Server, en allant chercher le fichier correspondant.
STSADM réalise en plus, notamment, un backup des search catalogs. Ceci -pour moi- se justifie en particulier pour une ferme contenant de nombreux documents. Sinon, lors du restore, il faudra relancer une indexation intégrale, ce qui peut être très long, et donc rallonger la durée de remise en service complète.
Pour la question de la taille des bases, vaste débat. Il est évident que manipuler des grosses bases est d'autant plus risqué qu'elles sont grandes, et monolithiques. En cas de crash partiel, on apprécie de ne restaurer qu'une partie, plutôt que la totalité.
Sauf à avoir fonctionnellement besoin de tout placer dans une même collection de sites (relations, droits d'accès...), je préconise personnellement de séparer chaque site collection dans une content db dédiée. En prévision de l'avenir, et d'une croissance souvent non maîtrisée.
Cdlt, -- TG2K
Bonjour,
On 2 avr, 13:30, "Lognoul, Marc (Private)" <logno...@hotmail.com>
wrote:
Il est préférable de s'en tenir au backup classique via STSADMIN.
Le backup SQL s'avère avantageux lorsque les DB sont très grandes: le
backup/restore SQL devient alors beaucoup plus rapide que via STSADM, tout
cela sans impacter la couche applicative.
Sachez que STSADM, pour les bases de données de contenu, réalise tout
simplement... un backup SQL full ou differentiel, piloté à distance.
D'ailleurs, il vous est même possible de remonter un backup de STSADM
simplement avec SQL Server, en allant chercher le fichier
correspondant.
STSADM réalise en plus, notamment, un backup des search catalogs. Ceci
-pour moi- se justifie en particulier pour une ferme contenant de
nombreux documents. Sinon, lors du restore, il faudra relancer une
indexation intégrale, ce qui peut être très long, et donc rallonger la
durée de remise en service complète.
Pour la question de la taille des bases, vaste débat. Il est évident
que manipuler des grosses bases est d'autant plus risqué qu'elles sont
grandes, et monolithiques. En cas de crash partiel, on apprécie de ne
restaurer qu'une partie, plutôt que la totalité.
Sauf à avoir fonctionnellement besoin de tout placer dans une même
collection de sites (relations, droits d'accès...), je préconise
personnellement de séparer chaque site collection dans une content db
dédiée. En prévision de l'avenir, et d'une croissance souvent non
maîtrisée.
Il est préférable de s'en tenir au backup classique via STSADMIN. Le backup SQL s'avère avantageux lorsque les DB sont très grandes: le backup/restore SQL devient alors beaucoup plus rapide que via STSADM, tout cela sans impacter la couche applicative.
Sachez que STSADM, pour les bases de données de contenu, réalise tout simplement... un backup SQL full ou differentiel, piloté à distance. D'ailleurs, il vous est même possible de remonter un backup de STSADM simplement avec SQL Server, en allant chercher le fichier correspondant.
STSADM réalise en plus, notamment, un backup des search catalogs. Ceci -pour moi- se justifie en particulier pour une ferme contenant de nombreux documents. Sinon, lors du restore, il faudra relancer une indexation intégrale, ce qui peut être très long, et donc rallonger la durée de remise en service complète.
Pour la question de la taille des bases, vaste débat. Il est évident que manipuler des grosses bases est d'autant plus risqué qu'elles sont grandes, et monolithiques. En cas de crash partiel, on apprécie de ne restaurer qu'une partie, plutôt que la totalité.
Sauf à avoir fonctionnellement besoin de tout placer dans une même collection de sites (relations, droits d'accès...), je préconise personnellement de séparer chaque site collection dans une content db dédiée. En prévision de l'avenir, et d'une croissance souvent non maîtrisée.
Cdlt, -- TG2K
Lognoul, Marc \(Private\)
"TG2K" wrote in message news:
Bonjour,
On 2 avr, 13:30, "Lognoul, Marc (Private)" wrote:
Il est préférable de s'en tenir au backup classique via STSADMIN. Le backup SQL s'avère avantageux lorsque les DB sont très grandes: le backup/restore SQL devient alors beaucoup plus rapide que via STSADM, tout cela sans impacter la couche applicative.
Sachez que STSADM, pour les bases de données de contenu, réalise tout simplement... un backup SQL full ou differentiel, piloté à distance. D'ailleurs, il vous est même possible de remonter un backup de STSADM simplement avec SQL Server, en allant chercher le fichier correspondant.
. Mais je sais ça :). Et je ne conteste pas l'utilité de STSADM ni celle des backups SQL d'ailleurs. Dans une farm de petite taille ou de taille moyenne, il me parait toujours plus facile de passer par STSADM plutôt que SQL. Toutefois, je maintiens que passer par STSADM accentue la charge sur le serveur qui l'exécute, et celui-ci est forcément un serveur WSS/MOSS.
Dans les grandes farms, celle donc je m'occupe principalement (c'est pour cette raison que je ne maitrise pas SBS :), selon certains), la couche DB est souvent gérée par une équipe différent et il en va de même pour les backups. De plus, utiliser SQL permet aussi d'utiliser des snapshots, impossibles avec STSADM
STSADM réalise en plus, notamment, un backup des search catalogs. Ceci -pour moi- se justifie en particulier pour une ferme contenant de nombreux documents. Sinon, lors du restore, il faudra relancer une indexation intégrale, ce qui peut être très long, et donc rallonger la durée de remise en service complète.
Rien n'empêche de prendre un backup de la DB de search, cela reste supporté et permet d'éviter les rebuilds complets. Restaurer une (grande) farm, de manière générale, dure beaucoup plus longtemps avec STSADM
Pour la question de la taille des bases, vaste débat. Il est évident que manipuler des grosses bases est d'autant plus risqué qu'elles sont grandes, et monolithiques. En cas de crash partiel, on apprécie de ne restaurer qu'une partie, plutôt que la totalité.
Sauf à avoir fonctionnellement besoin de tout placer dans une même collection de sites (relations, droits d'accès...), je préconise personnellement de séparer chaque site collection dans une content db dédiée. En prévision de l'avenir, et d'une croissance souvent non maîtrisée.
La taille des bases est le résultat de compris entre : al construction fonctionnelle (web application, site collection etc.) et la capacité et la performance de stockage et de backup/restore. Un bon environnement de test aide à valider tout cela. Même si, comme vous, je trouve que garder to 1-to-1 entre une site collection et une DB est idéal, il existe pas mal environnements dans lesquels cette méthode est inapplicable, vu les grand nombre de site collections.
Marc
Cdlt, -- TG2K
"TG2K" <ElGibs@gmail.com> wrote in message
news:ea060c0c-f235-4c64-92da-f10b705a0b0c@d45g2000hsc.googlegroups.com...
Bonjour,
On 2 avr, 13:30, "Lognoul, Marc (Private)" <logno...@hotmail.com>
wrote:
Il est préférable de s'en tenir au backup classique via STSADMIN.
Le backup SQL s'avère avantageux lorsque les DB sont très grandes: le
backup/restore SQL devient alors beaucoup plus rapide que via STSADM,
tout
cela sans impacter la couche applicative.
Sachez que STSADM, pour les bases de données de contenu, réalise tout
simplement... un backup SQL full ou differentiel, piloté à distance.
D'ailleurs, il vous est même possible de remonter un backup de STSADM
simplement avec SQL Server, en allant chercher le fichier
correspondant.
. Mais je sais ça :). Et je ne conteste pas l'utilité de STSADM ni celle des
backups SQL d'ailleurs. Dans une farm de petite taille ou de taille moyenne,
il me parait toujours plus facile de passer par STSADM plutôt que SQL.
Toutefois, je maintiens que passer par STSADM accentue la charge sur le
serveur qui l'exécute, et celui-ci est forcément un serveur WSS/MOSS.
Dans les grandes farms, celle donc je m'occupe principalement (c'est pour
cette raison que je ne maitrise pas SBS :), selon certains), la couche DB
est souvent gérée par une équipe différent et il en va de même pour les
backups. De plus, utiliser SQL permet aussi d'utiliser des snapshots,
impossibles avec STSADM
STSADM réalise en plus, notamment, un backup des search catalogs. Ceci
-pour moi- se justifie en particulier pour une ferme contenant de
nombreux documents. Sinon, lors du restore, il faudra relancer une
indexation intégrale, ce qui peut être très long, et donc rallonger la
durée de remise en service complète.
Rien n'empêche de prendre un backup de la DB de search, cela reste supporté
et permet d'éviter les rebuilds complets.
Restaurer une (grande) farm, de manière générale, dure beaucoup plus
longtemps avec STSADM
Pour la question de la taille des bases, vaste débat. Il est évident
que manipuler des grosses bases est d'autant plus risqué qu'elles sont
grandes, et monolithiques. En cas de crash partiel, on apprécie de ne
restaurer qu'une partie, plutôt que la totalité.
Sauf à avoir fonctionnellement besoin de tout placer dans une même
collection de sites (relations, droits d'accès...), je préconise
personnellement de séparer chaque site collection dans une content db
dédiée. En prévision de l'avenir, et d'une croissance souvent non
maîtrisée.
La taille des bases est le résultat de compris entre : al construction
fonctionnelle (web application, site collection etc.) et la capacité et la
performance de stockage et de backup/restore. Un bon environnement de test
aide à valider tout cela.
Même si, comme vous, je trouve que garder to 1-to-1 entre une site
collection et une DB est idéal, il existe pas mal environnements dans
lesquels cette méthode est inapplicable, vu les grand nombre de site
collections.
Il est préférable de s'en tenir au backup classique via STSADMIN. Le backup SQL s'avère avantageux lorsque les DB sont très grandes: le backup/restore SQL devient alors beaucoup plus rapide que via STSADM, tout cela sans impacter la couche applicative.
Sachez que STSADM, pour les bases de données de contenu, réalise tout simplement... un backup SQL full ou differentiel, piloté à distance. D'ailleurs, il vous est même possible de remonter un backup de STSADM simplement avec SQL Server, en allant chercher le fichier correspondant.
. Mais je sais ça :). Et je ne conteste pas l'utilité de STSADM ni celle des backups SQL d'ailleurs. Dans une farm de petite taille ou de taille moyenne, il me parait toujours plus facile de passer par STSADM plutôt que SQL. Toutefois, je maintiens que passer par STSADM accentue la charge sur le serveur qui l'exécute, et celui-ci est forcément un serveur WSS/MOSS.
Dans les grandes farms, celle donc je m'occupe principalement (c'est pour cette raison que je ne maitrise pas SBS :), selon certains), la couche DB est souvent gérée par une équipe différent et il en va de même pour les backups. De plus, utiliser SQL permet aussi d'utiliser des snapshots, impossibles avec STSADM
STSADM réalise en plus, notamment, un backup des search catalogs. Ceci -pour moi- se justifie en particulier pour une ferme contenant de nombreux documents. Sinon, lors du restore, il faudra relancer une indexation intégrale, ce qui peut être très long, et donc rallonger la durée de remise en service complète.
Rien n'empêche de prendre un backup de la DB de search, cela reste supporté et permet d'éviter les rebuilds complets. Restaurer une (grande) farm, de manière générale, dure beaucoup plus longtemps avec STSADM
Pour la question de la taille des bases, vaste débat. Il est évident que manipuler des grosses bases est d'autant plus risqué qu'elles sont grandes, et monolithiques. En cas de crash partiel, on apprécie de ne restaurer qu'une partie, plutôt que la totalité.
Sauf à avoir fonctionnellement besoin de tout placer dans une même collection de sites (relations, droits d'accès...), je préconise personnellement de séparer chaque site collection dans une content db dédiée. En prévision de l'avenir, et d'une croissance souvent non maîtrisée.
La taille des bases est le résultat de compris entre : al construction fonctionnelle (web application, site collection etc.) et la capacité et la performance de stockage et de backup/restore. Un bon environnement de test aide à valider tout cela. Même si, comme vous, je trouve que garder to 1-to-1 entre une site collection et une DB est idéal, il existe pas mal environnements dans lesquels cette méthode est inapplicable, vu les grand nombre de site collections.
Marc
Cdlt, -- TG2K
Lognoul, Marc \(Private\)
... Juste une petite note pour dire que le backup/restore de db de search n'est pas recommandé par MS à cause de l'inconsistance qui peut de créer à la restauration entre la DB et les fichiers d'index. Toutefois il existe des méthodes pour éviter cela. Donc, pour une petite farm ou une farm moyenne, votre conseil est évidemment applicable.
Marc
"Lognoul, Marc (Private)" wrote in message news:
"TG2K" wrote in message news:
Bonjour,
On 2 avr, 13:30, "Lognoul, Marc (Private)" wrote:
Il est préférable de s'en tenir au backup classique via STSADMIN. Le backup SQL s'avère avantageux lorsque les DB sont très grandes: le backup/restore SQL devient alors beaucoup plus rapide que via STSADM, tout cela sans impacter la couche applicative.
Sachez que STSADM, pour les bases de données de contenu, réalise tout simplement... un backup SQL full ou differentiel, piloté à distance. D'ailleurs, il vous est même possible de remonter un backup de STSADM simplement avec SQL Server, en allant chercher le fichier correspondant.
. Mais je sais ça :). Et je ne conteste pas l'utilité de STSADM ni celle des backups SQL d'ailleurs. Dans une farm de petite taille ou de taille moyenne, il me parait toujours plus facile de passer par STSADM plutôt que SQL. Toutefois, je maintiens que passer par STSADM accentue la charge sur le serveur qui l'exécute, et celui-ci est forcément un serveur WSS/MOSS.
Dans les grandes farms, celle donc je m'occupe principalement (c'est pour cette raison que je ne maitrise pas SBS :), selon certains), la couche DB est souvent gérée par une équipe différent et il en va de même pour les backups. De plus, utiliser SQL permet aussi d'utiliser des snapshots, impossibles avec STSADM
STSADM réalise en plus, notamment, un backup des search catalogs. Ceci -pour moi- se justifie en particulier pour une ferme contenant de nombreux documents. Sinon, lors du restore, il faudra relancer une indexation intégrale, ce qui peut être très long, et donc rallonger la durée de remise en service complète.
Rien n'empêche de prendre un backup de la DB de search, cela reste supporté et permet d'éviter les rebuilds complets. Restaurer une (grande) farm, de manière générale, dure beaucoup plus longtemps avec STSADM
Pour la question de la taille des bases, vaste débat. Il est évident que manipuler des grosses bases est d'autant plus risqué qu'elles sont grandes, et monolithiques. En cas de crash partiel, on apprécie de ne restaurer qu'une partie, plutôt que la totalité.
Sauf à avoir fonctionnellement besoin de tout placer dans une même collection de sites (relations, droits d'accès...), je préconise personnellement de séparer chaque site collection dans une content db dédiée. En prévision de l'avenir, et d'une croissance souvent non maîtrisée.
La taille des bases est le résultat de compris entre : al construction fonctionnelle (web application, site collection etc.) et la capacité et la performance de stockage et de backup/restore. Un bon environnement de test aide à valider tout cela. Même si, comme vous, je trouve que garder to 1-to-1 entre une site collection et une DB est idéal, il existe pas mal environnements dans lesquels cette méthode est inapplicable, vu les grand nombre de site collections.
Marc
Cdlt, -- TG2K
... Juste une petite note pour dire que le backup/restore de db de search
n'est pas recommandé par MS à cause de l'inconsistance qui peut de créer à
la restauration entre la DB et les fichiers d'index. Toutefois il existe des
méthodes pour éviter cela.
Donc, pour une petite farm ou une farm moyenne, votre conseil est évidemment
applicable.
Marc
"Lognoul, Marc (Private)" <lognoulm@hotmail.com> wrote in message
news:90DC2E0E-6E19-49C5-8F38-DFEDDC031EC2@microsoft.com...
"TG2K" <ElGibs@gmail.com> wrote in message
news:ea060c0c-f235-4c64-92da-f10b705a0b0c@d45g2000hsc.googlegroups.com...
Bonjour,
On 2 avr, 13:30, "Lognoul, Marc (Private)" <logno...@hotmail.com>
wrote:
Il est préférable de s'en tenir au backup classique via STSADMIN.
Le backup SQL s'avère avantageux lorsque les DB sont très grandes: le
backup/restore SQL devient alors beaucoup plus rapide que via STSADM,
tout
cela sans impacter la couche applicative.
Sachez que STSADM, pour les bases de données de contenu, réalise tout
simplement... un backup SQL full ou differentiel, piloté à distance.
D'ailleurs, il vous est même possible de remonter un backup de STSADM
simplement avec SQL Server, en allant chercher le fichier
correspondant.
. Mais je sais ça :). Et je ne conteste pas l'utilité de STSADM ni celle
des backups SQL d'ailleurs. Dans une farm de petite taille ou de taille
moyenne, il me parait toujours plus facile de passer par STSADM plutôt que
SQL. Toutefois, je maintiens que passer par STSADM accentue la charge sur
le serveur qui l'exécute, et celui-ci est forcément un serveur WSS/MOSS.
Dans les grandes farms, celle donc je m'occupe principalement (c'est pour
cette raison que je ne maitrise pas SBS :), selon certains), la couche DB
est souvent gérée par une équipe différent et il en va de même pour les
backups. De plus, utiliser SQL permet aussi d'utiliser des snapshots,
impossibles avec STSADM
STSADM réalise en plus, notamment, un backup des search catalogs. Ceci
-pour moi- se justifie en particulier pour une ferme contenant de
nombreux documents. Sinon, lors du restore, il faudra relancer une
indexation intégrale, ce qui peut être très long, et donc rallonger la
durée de remise en service complète.
Rien n'empêche de prendre un backup de la DB de search, cela reste
supporté et permet d'éviter les rebuilds complets.
Restaurer une (grande) farm, de manière générale, dure beaucoup plus
longtemps avec STSADM
Pour la question de la taille des bases, vaste débat. Il est évident
que manipuler des grosses bases est d'autant plus risqué qu'elles sont
grandes, et monolithiques. En cas de crash partiel, on apprécie de ne
restaurer qu'une partie, plutôt que la totalité.
Sauf à avoir fonctionnellement besoin de tout placer dans une même
collection de sites (relations, droits d'accès...), je préconise
personnellement de séparer chaque site collection dans une content db
dédiée. En prévision de l'avenir, et d'une croissance souvent non
maîtrisée.
La taille des bases est le résultat de compris entre : al construction
fonctionnelle (web application, site collection etc.) et la capacité et la
performance de stockage et de backup/restore. Un bon environnement de test
aide à valider tout cela.
Même si, comme vous, je trouve que garder to 1-to-1 entre une site
collection et une DB est idéal, il existe pas mal environnements dans
lesquels cette méthode est inapplicable, vu les grand nombre de site
collections.
... Juste une petite note pour dire que le backup/restore de db de search n'est pas recommandé par MS à cause de l'inconsistance qui peut de créer à la restauration entre la DB et les fichiers d'index. Toutefois il existe des méthodes pour éviter cela. Donc, pour une petite farm ou une farm moyenne, votre conseil est évidemment applicable.
Marc
"Lognoul, Marc (Private)" wrote in message news:
"TG2K" wrote in message news:
Bonjour,
On 2 avr, 13:30, "Lognoul, Marc (Private)" wrote:
Il est préférable de s'en tenir au backup classique via STSADMIN. Le backup SQL s'avère avantageux lorsque les DB sont très grandes: le backup/restore SQL devient alors beaucoup plus rapide que via STSADM, tout cela sans impacter la couche applicative.
Sachez que STSADM, pour les bases de données de contenu, réalise tout simplement... un backup SQL full ou differentiel, piloté à distance. D'ailleurs, il vous est même possible de remonter un backup de STSADM simplement avec SQL Server, en allant chercher le fichier correspondant.
. Mais je sais ça :). Et je ne conteste pas l'utilité de STSADM ni celle des backups SQL d'ailleurs. Dans une farm de petite taille ou de taille moyenne, il me parait toujours plus facile de passer par STSADM plutôt que SQL. Toutefois, je maintiens que passer par STSADM accentue la charge sur le serveur qui l'exécute, et celui-ci est forcément un serveur WSS/MOSS.
Dans les grandes farms, celle donc je m'occupe principalement (c'est pour cette raison que je ne maitrise pas SBS :), selon certains), la couche DB est souvent gérée par une équipe différent et il en va de même pour les backups. De plus, utiliser SQL permet aussi d'utiliser des snapshots, impossibles avec STSADM
STSADM réalise en plus, notamment, un backup des search catalogs. Ceci -pour moi- se justifie en particulier pour une ferme contenant de nombreux documents. Sinon, lors du restore, il faudra relancer une indexation intégrale, ce qui peut être très long, et donc rallonger la durée de remise en service complète.
Rien n'empêche de prendre un backup de la DB de search, cela reste supporté et permet d'éviter les rebuilds complets. Restaurer une (grande) farm, de manière générale, dure beaucoup plus longtemps avec STSADM
Pour la question de la taille des bases, vaste débat. Il est évident que manipuler des grosses bases est d'autant plus risqué qu'elles sont grandes, et monolithiques. En cas de crash partiel, on apprécie de ne restaurer qu'une partie, plutôt que la totalité.
Sauf à avoir fonctionnellement besoin de tout placer dans une même collection de sites (relations, droits d'accès...), je préconise personnellement de séparer chaque site collection dans une content db dédiée. En prévision de l'avenir, et d'une croissance souvent non maîtrisée.
La taille des bases est le résultat de compris entre : al construction fonctionnelle (web application, site collection etc.) et la capacité et la performance de stockage et de backup/restore. Un bon environnement de test aide à valider tout cela. Même si, comme vous, je trouve que garder to 1-to-1 entre une site collection et une DB est idéal, il existe pas mal environnements dans lesquels cette méthode est inapplicable, vu les grand nombre de site collections.
