Récupération après sinistre Sharepoint

Question

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

Actuellement, nous backuping toutes les bases de données (1 contenu, admin, recherche et config) à l'aide des outils de sauvegarde SQL et backuping le serveur frontal via DataProtector. Pour tester nos sauvegardes, nous utilisons une autre batterie de serveurs, restaurez la base de données de contenu (en suivant la procédure sur technet) et créez une nouvelle application qui utilise cette base de données. Nous devons simplement redéployer des solutions sur l'application sharepoint nouvellement créée.

Cependant, nous devons modifier les informations d'identification d'accès de base de données (sur le serveur SQL): les comptes d'utilisateurs utilisés sur la production ne sont pas les mêmes que ceux utilisés sur notre ferme « test ».

À 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 étudions.

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

Answer 1

Vous ne pouvez pas vraiment de sauvegarde/restauration à la fois la base de données de configuration et la base de données de recherche:

• base de données restauration config ne fonctionne que si votre nouvelle ferme ont exactement les mêmes noms de serveur
• lorsque vous restaurez la base de données de recherche, l'index de texte intégral n'est pas synchronisé. Cependant, ce n'est pas un problème car vous pouvez juste réindexer.

En conséquence, je dirais que oui, ceci est fiable pour le contenu. Mais prenez soin de:

• Vous devrez peut-être refaire une configuration (AAM, chemin géré ...).
• Cela ne comprend pas la personnalisation, vous souhaitez conserver une copie de sauvegarde de votre solution

Answer 2

La fiabilité est dans l'oeil du spectateur. Dans ce cas, si vos tests du processus de restauration réussissent, alors oui, c'est fiable.

Answer 3

Un certain nombre de mes clients exécuter SharePoint (à la fois MOSS et WSS) dans des environnements virtuels, SQL Server est également virtualisé et soutenu à la fois avec des outils SQL et avec la copie Volume Shadow. L'avantage d'un environnement virtuel est que les temps d'arrêt ne durent que le temps nécessaire à l'hôte du serveur virtuel pour amorcer les images. Si vous n'utilisez pas la virtualisation, n'oubliez pas de sauvegarder régulièrement les journaux de transactions, car cela facilitera la restauration à un moment donné de la journée. Cela signifie également que vos journaux de transactions ne deviennent pas trop volumineux!

Answer 4

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 certaine maintenance du fichier XML de métadonnées de sauvegarde lorsque vous commencez à manquer d'espace disque et devez archiver des sauvegardes plus anciennes. Il a l'avantage de transférer des tâches de minuteur (en général) 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 cas.

Pour restaurer, vous pouvez utiliser l'interface utilisateur qui est agréable et ne pas avoir à faire avec beaucoup d'autres choses. Je pense que cela restaure également vos solutions, mais ne les a pas testées de manière approfondie.