none
Questions sur la migration de serveurs SharePoint 2010 RRS feed

  • Question

  • Bonjour à tous,

    Je suis actuellement en train de mener un projet de migration de serveur SharePoint 2010, d'un serveur A à un serveur B tout neuf.

    Sur ce serveur B tout doit être réinstallé from scratch. J'ai bien étudié la documentation fournie sur le Technet à propos du déplacement de serveurs et il en ressort quelques interrogations:

    - Il existe une méthode de sauvegarde directement dans SP2010, mais il y est indiqué dans la documentation qu'on ne peut pas les restaurer par les outils sharepoint... J'ai lu également qu'une simple sauvegarde SQL ne couvre pas tout et qu'il est nécesaire de passer par la sauvegarde intégrée SharePoint. D'où ma question, quelle méthode dois-je employer ? Dois je à la fois sauvegarder les BDD SQL2008R2 puis les restaurer et également faire une sauvegarde SP2010 que je restaure ensuite ? Ou alors l'un est à privilégier par rapport à l'autre ?

    - Pour SQL il y est indiqué 2 méthodes, la première consiste à Déplacer les BDD (avec les fichiers mdf, ldf et ndf) et la deuxième à sauvegarder puis restaurer les BDD par SQL Studio. Quelle méthode est à préférer ? Quels sont leurs avantages respectifs ?

    - J'ai deux serveurs Web et un serveur de BDD. Je dois appliquer la procédure choisie aux 3 serveurs. Cependant, dois je installer SharePoint puis configurer quoi que ce soit dès le départ ? Où la restauration me restaurera l'ensemble de mes paramètres ?

    - Il existe des pool d'applications, visibles depuis IIS. Sont-ils sauvegardés en même temps que la sauvegarde complète du serveur SharePoint ?

    Par avance merci !


    • Modifié Chesmet lundi 29 avril 2013 14:23
    lundi 29 avril 2013 13:45

Réponses

  • Bonjour à vous,

    Si vos serveurs de destination doivent être réinstallés from scratch la meilleure méthode est le backup et restore ou le déplacement des BDD, les avantages et inconvénient ?

    - backup & restore

    ->permet de garder la ferme accessible aux utilisateurs pendant la migration: avantage

    ->les BDD seront en read-only, donc lecture seule pour les utilisateurs: inconvénient

    ->vous ne pouvez réutiliser ces même serveur pour la nouvelle ferme (forcement sinon pas d'accés...)

    - move database

    -> la ferme sera inactive pendant la durée de la migration : inconvenient

    -> la cohérence des données est garantie : avantage

    Pour finir il n'y a pas de mauvaise ou bonne méthode cela dépend de comment vous le prennez... Microsoft recommande l'un des 2 après à vous de voir laquelle voulez vous choisir sachant que les 2 restes simples.

    De mon point de vue, je vous conseil donc de faire la méthode backup and restore si toutefois vous le souhaitez bien évidemment.les étapes:

    - Mettez les BDD en read only sur votre ferme A

    - Backup de vos BDD sur votre ferme A

    - restore de vos BDD sur votre ferme B

    - passez vos BDD en read/write sur votre ferme B

    Ensuite sur vos serveurs tout neuf, installez SharePoint, lancez le wizard en spécifiant votre SQL de la ferme B et basta.

    Sachant que vous ne faites pas de migration mais juste un changement de serveur la méthode move database marche très bien aussi...

    Bon courage à vous,

    valentin


    Mon blog sur SharePoint
    Site du Groupe AFG
    viadeotwitter

    lundi 29 avril 2013 14:24
  • Bonjour,

    Il me semble que bon nombre de fichiers et notamment de configuration de l'applicatif Sharepoint sont sauvegardés pendant cette étape. N'est il pas alors nécessaire de faire un backup/restore par le portail d'administration, le restore ayant lieu après la reconnexion à la base SQL restaurée ?

    Non, on recommence souvent "from scratch" et on copie les Content DB..

    Autre question, j'imagine que cela ne pose pas problème d'appeler les serveurs B différemment des serveurs A ?

    Non aucun problème non plus..

    Pouvez-vous simplement me dire quelle est la meilleur solution pour move un serveur SP2010 avec sa base ?

    Difficile à répondre.. Le mieux est de faire un "backup/restore" des content DB de la platforme A vers platforme B .. Ou encore via PowerShell spbackup-site .. ca depend des tailles de vos db et sites..

    Courage,

    Gokan


    My New Technical Blog: WWW.GKNZCFC.NET
    SharePoint Community Expert

    mardi 30 avril 2013 18:40
  • Bonjour

    Pour ma part si j'ai un peu de temps je préfère une approche un poil différente :

    Je monte ma nouvelle ferme (donc serveurs B ds votre cas) en y faisant :

    • création de l'ensemble des applications de services (BCS, Search, userprofile, bref tout ce dont vous allez avoir besoin...
    • création des webapplications (avec les même hostnames que les webapp existantes sur la ferme A) mais à ce niveau je crée pas de site collection (juste la webapp, les pool , ce qui va bien pour acceuillir mes contenus...)

    Une fois que je suis sûr que tout ça fonctionne :

    • Mise en lecture seule des bases de contenus (seulement les contenus des webapps) sur la ferme A
    • Backup des bases (c'est plus sûr qu'un déplacement de fichier mdf qui peut être 'inconsistant' alors que le backup vous garanti la validité du fichier)
    • Restore des bases sur le sql server de la ferme B (soit sur les nouvelles bdd de contenu crée lors du setup de la nouvelle ferme, soit sur des nouvelle bases)
    • Si besoins attach des bdds au niveau de sharepoint (powershell : mount-spcontentdatabase)

    Avantages : 

    • Vous montez votre nouvelle ferme et la validez sans impacter la ferme existante (et sans bloquer les utilisateurs)
    • Vous faites si possible une meilleure config (il est fort probable que la ferme A ne soit pas très bien configurée, tous les pré requis / best pratices ne sont pas forcement tjrs suivis...)

    Inconvénients :

    • Plus long
    • Beaucoup de setup manuel (mais qui peut etre scripté en powershell)

    et enfin pour conclure, pourquoi moi je choisis aussi cette approche , c'est que j'ai rarement réussi à remonter les services tiers (search, bcs, userprofile, etc...) correctement en passant par de simples backups / restore des bdd correspondantes (c'est là que le backup/restore par sharepoint est pertinent) mais surtout il est au final rare de vouloir faire un migration 100% ISO, souvent on profite pour corriger un peu la config de la nouvelle ferme par rapport à l'ancienne....


    Blog Sharepoint : www.paslatek.net Twitter : @LimozinLionel

    • Marqué comme réponse Chesmet jeudi 2 mai 2013 12:33
    • Non marqué comme réponse Chesmet jeudi 2 mai 2013 12:33
    • Marqué comme réponse Gokan OzcifciMVP vendredi 10 mai 2013 12:01
    jeudi 2 mai 2013 12:18

Toutes les réponses

  • Bonjour à vous,

    Si vos serveurs de destination doivent être réinstallés from scratch la meilleure méthode est le backup et restore ou le déplacement des BDD, les avantages et inconvénient ?

    - backup & restore

    ->permet de garder la ferme accessible aux utilisateurs pendant la migration: avantage

    ->les BDD seront en read-only, donc lecture seule pour les utilisateurs: inconvénient

    ->vous ne pouvez réutiliser ces même serveur pour la nouvelle ferme (forcement sinon pas d'accés...)

    - move database

    -> la ferme sera inactive pendant la durée de la migration : inconvenient

    -> la cohérence des données est garantie : avantage

    Pour finir il n'y a pas de mauvaise ou bonne méthode cela dépend de comment vous le prennez... Microsoft recommande l'un des 2 après à vous de voir laquelle voulez vous choisir sachant que les 2 restes simples.

    De mon point de vue, je vous conseil donc de faire la méthode backup and restore si toutefois vous le souhaitez bien évidemment.les étapes:

    - Mettez les BDD en read only sur votre ferme A

    - Backup de vos BDD sur votre ferme A

    - restore de vos BDD sur votre ferme B

    - passez vos BDD en read/write sur votre ferme B

    Ensuite sur vos serveurs tout neuf, installez SharePoint, lancez le wizard en spécifiant votre SQL de la ferme B et basta.

    Sachant que vous ne faites pas de migration mais juste un changement de serveur la méthode move database marche très bien aussi...

    Bon courage à vous,

    valentin


    Mon blog sur SharePoint
    Site du Groupe AFG
    viadeotwitter

    lundi 29 avril 2013 14:24
  • Ok merci pour votre réponse.

    Qu'en est-il de la sauvegarde SharePoint ? Il n'est pas nécessaire de faire cette dernière ?

    Il me semble que bon nombre de fichiers et notamment de configuration de l'applicatif Sharepoint sont sauvegardés pendant cette étape. N'est il pas alors nécessaire de faire un backup/restore par le portail d'administration, le restore ayant lieu après la reconnexion à la base SQL restaurée ?


    Autre question, j'imagine que cela ne pose pas problème d'appeler les serveurs B différemment des serveurs A ?
    • Modifié Chesmet lundi 29 avril 2013 14:45
    lundi 29 avril 2013 14:38
  • Pouvez-vous simplement me dire quelle est la meilleur solution pour move un serveur SP2010 avec sa base ?

    • Déco/Reco sa base par SQL ?
    • Utiliser l'utilitaire save/restore de SP2010 ?
    • Les 2 ?
    mardi 30 avril 2013 12:59
  • Bonjour,

    Il me semble que bon nombre de fichiers et notamment de configuration de l'applicatif Sharepoint sont sauvegardés pendant cette étape. N'est il pas alors nécessaire de faire un backup/restore par le portail d'administration, le restore ayant lieu après la reconnexion à la base SQL restaurée ?

    Non, on recommence souvent "from scratch" et on copie les Content DB..

    Autre question, j'imagine que cela ne pose pas problème d'appeler les serveurs B différemment des serveurs A ?

    Non aucun problème non plus..

    Pouvez-vous simplement me dire quelle est la meilleur solution pour move un serveur SP2010 avec sa base ?

    Difficile à répondre.. Le mieux est de faire un "backup/restore" des content DB de la platforme A vers platforme B .. Ou encore via PowerShell spbackup-site .. ca depend des tailles de vos db et sites..

    Courage,

    Gokan


    My New Technical Blog: WWW.GKNZCFC.NET
    SharePoint Community Expert

    mardi 30 avril 2013 18:40
  • Merci beaucoup pour ces précisions.

    Au total, j'ai environ 65Go de DB.

    • Cette solution est-elle correcte:

    L'idéal serait alors d'arriver sur le serveur en production, faire par exemple un spbackup-site et récupérer les fichiers backupé. Dans le technet il parle de la commande Backup-SPFarm par contre.

    De là, je passe sur la nouvelle plateforme - comment cette dernière doit-être configurée:

    • De base et peu importe puisque tout sera écrasé par la restore ? J'imagine qu'elle doit être couplée au serveur de DB mais ça c'est configuré pendant l'install...)
    • Et je lance un sprestore-site avec ces fichiers et tout devrait remarcher comme avant ?

    Soit je fais comme ça, soit je détache, rattache mes DB.

    • Un spbackup-site ne va pas inclure une coupure de service, mais ne serait-il pas préférable de passer les DB en read-only avant la sauvegarde pour éviter tout delta ?

    Avec 65Go vous me conseillez-quoi ?

    • Si je comprends bien, la fonctionnalité backup/restore est recommandée en cas de crash de la plateforme et pas en cas de move ?

    • Modifié Chesmet mercredi 1 mai 2013 12:53
    mercredi 1 mai 2013 12:42
  • Avec 65 GB, je vous conseille de faire un BACKUP / RESTORE de base de donnée de contenu .. Vous pouvez avoir des problèmes avec PowerShell .. c'est une best practice de ne pas dépasser 15GB ..

    C'est ca, il faut la mettre en read-only et prendre un backup et la restaurer sur la platforme B.

    Courage,

    Gokan


    My New Technical Blog: WWW.GKNZCFC.NET
    SharePoint Community Expert

    mercredi 1 mai 2013 19:35
  • Très bien merci beaucoup.

    Je pense faire un backup/restore dans ce cas.

    Il y a aussi la possibilité de détacher/rattacher les bases, le soucis c'est qu'on aura une interruption de service dans ce cas.

    En restaurant mes bases l'ensemble de mes paramètres SharePoint seront restaurés intégralement ?

    Je veux simplement m'assurer que le restore est "si tout va bien" la dernière étape pour retrouver l'intégralité des fonctionnalités de la plateforme source.

    jeudi 2 mai 2013 07:22
  • Bonjour à vous,

    Oui c'est la bonne solution si vous voulez garder du service par contre votre sharepoint doit être en read only pour éviter les problémes d'incohérence de données!

    pour résumer:

    - mettre vos BDD en read only sur le serveur A

    - backup des BDD du serveur A

    - restore des BDD sur le serveur B

    - executer le wizard sharepoint et quitter la ferme

    - executer le wizard et joindre une ferme existante autrement dit utiliser la BDD de config de votre nouveau serveur.

    - vérifier que la config est bonne et faites les modifications si besoin surtout sur les BDD de service.

    Bon courage

    valentin


    Mon blog sur SharePoint
    Site du Groupe AFG
    viadeotwitter

    MCP | Microsoft Certified Professional - SharePoint 2010 Administrator

    jeudi 2 mai 2013 09:35
  • Ok c'est noté,

    Par contre après un sp-backup, je viens de me rendre compte que la sauvegarde faisait 6,5Go...

    Bizarre, mais je pourrais peut être de ce fait passer par PowerShell pour le faire.

    Si je fais par SQL, il faut d'abord restaurer SQL avec l'installation de SharePoint si j'ai bien compris et dire lors de l'install qu'on se connecte à des bases SP existantes.

    Si je le fais par PowerShell, j'installe avant Sharepoint puis je fais un restaure avec le Sharepoint powershell admin après installation ?

    jeudi 2 mai 2013 10:08
  • Bonjour

    Pour ma part si j'ai un peu de temps je préfère une approche un poil différente :

    Je monte ma nouvelle ferme (donc serveurs B ds votre cas) en y faisant :

    • création de l'ensemble des applications de services (BCS, Search, userprofile, bref tout ce dont vous allez avoir besoin...
    • création des webapplications (avec les même hostnames que les webapp existantes sur la ferme A) mais à ce niveau je crée pas de site collection (juste la webapp, les pool , ce qui va bien pour acceuillir mes contenus...)

    Une fois que je suis sûr que tout ça fonctionne :

    • Mise en lecture seule des bases de contenus (seulement les contenus des webapps) sur la ferme A
    • Backup des bases (c'est plus sûr qu'un déplacement de fichier mdf qui peut être 'inconsistant' alors que le backup vous garanti la validité du fichier)
    • Restore des bases sur le sql server de la ferme B (soit sur les nouvelles bdd de contenu crée lors du setup de la nouvelle ferme, soit sur des nouvelle bases)
    • Si besoins attach des bdds au niveau de sharepoint (powershell : mount-spcontentdatabase)

    Avantages : 

    • Vous montez votre nouvelle ferme et la validez sans impacter la ferme existante (et sans bloquer les utilisateurs)
    • Vous faites si possible une meilleure config (il est fort probable que la ferme A ne soit pas très bien configurée, tous les pré requis / best pratices ne sont pas forcement tjrs suivis...)

    Inconvénients :

    • Plus long
    • Beaucoup de setup manuel (mais qui peut etre scripté en powershell)

    et enfin pour conclure, pourquoi moi je choisis aussi cette approche , c'est que j'ai rarement réussi à remonter les services tiers (search, bcs, userprofile, etc...) correctement en passant par de simples backups / restore des bdd correspondantes (c'est là que le backup/restore par sharepoint est pertinent) mais surtout il est au final rare de vouloir faire un migration 100% ISO, souvent on profite pour corriger un peu la config de la nouvelle ferme par rapport à l'ancienne....


    Blog Sharepoint : www.paslatek.net Twitter : @LimozinLionel

    • Marqué comme réponse Chesmet jeudi 2 mai 2013 12:33
    • Non marqué comme réponse Chesmet jeudi 2 mai 2013 12:33
    • Marqué comme réponse Gokan OzcifciMVP vendredi 10 mai 2013 12:01
    jeudi 2 mai 2013 12:18
  • Merci pour le scénario,

    Comme je disais, après un simple Backup-SPFarm, mon fichier de sauvegarde fait à peine 6Go non-compressé... Je pensais donc passer par un Restore-SPFarm, ce qui est plus simple et m'évite de déconnecter les bases et d'avoir quelque chose d'intégré à SharePoint.

    J'ai donc comme plan d'action:

    • Installation d'une config vierge de SQL avec son instance par défaut sur mon serveur DB.
    • Instalaltion d'une config vierge SharePoint connectée au serveur de DB
    • Bases en R/W, je fais un Backup-SPFarm
    • Restauration sur le serveur SharePoint avec Restore-SPFarm
    • Tests
    • Bases en Read-Only, je refais un Backup-SPFarm en delta.
    • Restauration sur le serveur SharePoint avec Restore-SPFarm
    • Tests

    Est-ce que celà vous semble également cohérent de cette façon ?


    jeudi 2 mai 2013 12:37
  • En effet le backup / restore sql peut parfois donner des difficultés sur la remontée des services mais bref.

    Pour votre plan d'action de trouve ça cohérent.Par contre je ne connais pas la topologie de votre ferme mais il ne faut pas oublier de prendre en compte le wizard à lancer sur votre nouveau serveur SQL afin de refaire votre BDD de configuration sharepoint.

    Bon courage,

    valentin


    Mon blog sur SharePoint
    Site du Groupe AFG
    viadeotwitter

    MCP | Microsoft Certified Professional - SharePoint 2010 Administrator

    jeudi 2 mai 2013 18:06
  • Bonjour,

    Coherent pour moi aussi .. Donc un grand OK .. Prenez également en compte les recomendation de Lionel Limozin..

    Bàv,

    Gokan


    My New Technical Blog: WWW.GKNZCFC.NET
    SharePoint Community Expert

    vendredi 3 mai 2013 06:32
  • Alors, j'ai lancé ma restore, mais j'ai un soucis assez trouble. J'ai regardé sur le net et apparemment la solution la plus adaptée serait de downgrader le serveur SQL 2008R2 en SQL2008.... j'ai ça sur l'ensemble des bases à restaurer quasiment.

    SqlException: The operation did not proceed far enough to allow RESTART. Reissue the statement without the RESTART qualifier. RESTORE DATABASE is terminating abnormally.

    Mais ça signifie que je dois donc réinstaller l'ensemble de SharePoint et de SQL...

    Sinon je pensais détacher toutes mes bases, les copier et les remonter de l'autre côté. Mais bon, pas de filet de secours sur ça, si j'ai un problème une fois remonté c'est coupure de service...

    vendredi 3 mai 2013 15:05
  • Quelle est la version de votre SQL Server source ?

    sur qu'elle base vous avez ce soucis ?

    Et enfin si vous avez l'intention de tester le détachement des bases, faites au préalable un backup Full côté serveur source, ça fera au moins ça en filet de secours....

    Et sinon rassurez moi, vous avez tout de même un environnement de "testing" pour la restore ou vous travaillez directement sur la future nouvelle PROD ?


    Blog Sharepoint : www.paslatek.net Twitter : @LimozinLionel

    vendredi 3 mai 2013 15:12
  • La version du SQL source est 2008R2.

    Le problème survient lors de la restauration de la ferme SharePoint.

    Je ne vois que le détachement ré-attache des bases maintenant... Puisqu'apparemment la restau SharePoint est bien bloquée, par PS ça revient au même...

    Et oui évidemment, je vous rassure, je travaille sur une copie en environnement de test, de la prod.

    dimanche 5 mai 2013 20:44
  • Bonsoir,

    Pourrions-nous en conclure que les membres de la communauté ont répondu a vos questions?

    Merci,

    Gokan


    My New Technical Blog: WWW.GKNZCFC.NET
    SharePoint Community Expert

    lundi 6 mai 2013 19:19
  • Malheureusement la manipulation n'a pas eu l'effet escompté.

    J'ai recréé une plateforme de zéro, j'ai ensuite créé des sites ayant le même nom sur mon SP, la base est bien crée sur mon serveur SQL avec le même nom que sur le précédent SP.

    Une fois l'ensemble du nouveau site créé de façon vierge, je détache sa nouvelle base et je viens rattacher l'ancienne base préalablement détachée possédant le même nom. Mais cela ne fonctionne pas.

    Malgré mon erreur à la restauration lors de l'étape de restauration des bases des applications de services, je l'ai fait en deux parties. J'ai restauré par le backupsp-restore et pour les bases non restaurées je les ai détachées de l'ancien et réattachées sur le nouveau. Là encore, rien ne fonctionne...

    Une connaissance m'a mentionné qu'il était nécessaire de faire un backup avec le service arrêté, ou qu'en tout cas sans aucune connexion dessus ni activité, est-ce possible ?

    Nous avions également comme idée potentielle de rajouter le nouveau serveur comme membre de la batterie SharePoint, puis ajouter le SQL comme partie du cluster SQL puis de supprimer les anciens membres pour ne finir qu'avec les deux nouveaux... Qu'en pensez-vous ?

    Les nouveaux serveurs SP et SQL ont bien évidemment des noms différents des anciens.

    dimanche 12 mai 2013 09:10