Question

Quels sont vos plans de récupération après sinistre pour Windows Sharepoint Services 3.0?

Actuellement, nous sauvegardons toutes les bases de données (1 contenu, admin, recherche et configuration) à l'aide d'outils de sauvegarde SQL, ainsi que le serveur frontal via le fournisseur de données.

Pour tester nos sauvegardes, nous utilisons une autre batterie de serveurs, restaurons la base de données de contenu (en suivant la procédure décrite à technet ) et créez une nouvelle application utilisant cette base de données. Nous devons simplement redéployer des solutions sur la nouvelle application SharePoint créée.

Toutefois, nous devons modifier les informations d'identification d'accès à la base de données (sur un serveur SQL): les comptes d'utilisateur utilisés en production ne sont pas les mêmes que ceux utilisés dans notre "test". ferme.

À la fin, nous pouvons restaurer notre base de données de contenu et accéder à tous nos sites. La recherche ne fonctionne pas, mais nous enquêtons.

Ce scénario de restauration est-il fiable (comme dans le cas de Microsoft)?

Était-ce utile?

La solution

Vous ne pouvez pas vraiment sauvegarder / restaurer la base de données de configuration et la base de données de recherche:

  • la restauration de la base de données de configuration ne fonctionne que si votre nouvelle batterie de serveurs a exactement le même nom de serveur
  • lorsque vous restaurez la base de données de recherche, l'index en texte intégral n'est pas synchronisé. cependant, ce n'est pas un problème car vous pouvez simplement réindexer.

En conséquence, je dirais que oui, il s’agit d’un contenu fiable. Mais prenez soin de:

  • Vous devrez peut-être refaire une configuration (AAM, chemin géré ...).
  • Ceci n'inclut pas la personnalisation, vous souhaitez conserver une sauvegarde de votre solution

Autres conseils

La fiabilité est dans l’oeil du spectateur. Dans ce cas, si vos tests du processus de restauration aboutissent, alors oui, ils sont fiables.

Un certain nombre de mes clients exécutent SharePoint (MOSS et WSS) dans des environnements virtuels. SQL Server est également virtualisé et sauvegardé à la fois avec des outils SQL et avec une copie Volume Shadow.

L'avantage d'un environnement virtuel réside dans le temps d'indisponibilité réside dans le temps nécessaire à l'hôte de votre serveur virtuel pour démarrer les images.

Si vous n'utilisez pas la virtualisation, n'oubliez pas de sauvegarder régulièrement les journaux de transactions, ce qui facilitera la restauration à un moment donné de la journée. Cela signifie également que vos journaux de transactions ne deviennent pas trop volumineux!

Je préfère utiliser la commande de sauvegarde stsadm -o 'pour une sauvegarde catastrophique', comme indiqué dans l'aide. Cela peut être planifié, mais nécessite une maintenance du fichier XML de métadonnées de sauvegarde lorsque vous commencez à manquer d’espace disque et que vous devez archiver des sauvegardes plus anciennes. Cela présente l'avantage de transférer (généralement) les travaux du minuteur et d'autres configurations car, comme le dit Nico, la restauration de la base de données de configuration ne fonctionnera pas dans la plupart des situations.

Pour restaurer, vous pouvez utiliser l'interface utilisateur, ce qui est agréable et ne pas avoir à vous soucier de rien d'autre. Je pense que cela restaure également vos solutions, mais je n'ai pas testé cela de manière approfondie.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top