Cómo hacer más eficiente la generación de respaldos y su restauración en SharePoint 2007

Cuando comenzamos a trabajar en planear nuestro DRP (Disaster Recovery Plan) de SharePoint 2007 para considerarlo como parte de nuestro SLA (Service Level Agreement), tenemos que revisar los distintos escenarios, opciones y herramientas disponibles para generar los respaldos de nuestra información y su restauración en un momento necesario.

Ahora, con conocer las distintas opciones que podemos manejar no es suficiente, es importante también estar al tanto de cuando una opción de respaldo es mejor que otra.

A continuación compartimos una tabla que habla de datos puntuales que valen la pena tomar en cuenta.

 

Tool Maximum backup size supported

System Center Data Protection Manager

32-bit systems: 150 data sources

64-bit systems: 300 data sources

For more information, see Data Protection Manager 2007 Frequently Asked Questions (http://go.microsoft.com/fwlink/?LinkId=126629).

SharePoint farm backup and recovery

< 200 GB

VSS Writer

No known limit

SQL Server

Content databases > 200 GB  may require additional management

Stsadm site collection backup and recovery

15 GB

Stsadm import and export

100 GB

SharePoint Designer backup

24 MB

MSIT Site Delete Capture tool

15 GB

 

Referencia: http://technet.microsoft.com/en-us/library/cc901593.aspx

Preparación de respaldos y restauración de una granja (implementación) de SharePoint

 

Les recomiendo estos tres artículos de TechNet en cuanto a respaldos y recuperación de SharePoint se refiere:

Plan for backup and recovery (Office SharePoint Server) 

http://technet.microsoft.com/en-us/library/cc261687.aspx

 

Prepare to back up and restore a farm (Office SharePoint Server 2007)

http://technet.microsoft.com/en-us/library/cc262704.aspx

 

Backup, Recovery, and Availability Resource Center for SharePoint Server 2007 (Disaster recovery, data protection, and high availability for SharePoint Server)

http://technet.microsoft.com/en-us/office/sharepointserver/bb736212.aspx

SharePoint 64bits vs 32 bits, Performance and Capacity planning

Ya van algunas veces que la gente me pregunta cuales son las ventajas de usar 64 bits sobre 32 bits para una implemetación de MOSS 2007 (32 bits o 64 bits para SharePoint o MOSS 2007). Por eso decidí compartir con ustedes esta información que se encuentra en TechNet, esperemos les sea de utilidad para apoyarles en tomar una decisión.

Planning for capacity vs. availability

This chapter assumes that you have already used the Plan for redundancy (Office SharePoint Server) article to plan for availability requirements. As a result of using the “Plan for availability” article, you will start the capacity planning exercise with a topology that meets your organization’s minimum availability requirements. Given the topology you have determined you will deploy, this chapter will help you determine:

  • If you need to add additional servers to meet your goals for capacity and performance.

  • If you need to adjust the configuration of application server roles to optimize capacity and performance of the server farm.

  • If you need to plan for more than one server farm based on your capacity requirements.

In some cases, an organization’s requirements for availability can result in a server farm size that provides greater capacity or performance than is otherwise required. If this is the case, your capacity planning process can focus on sizing the server hardware economically, rather than on adding additional server computers (scaling out) or scaling up with higher-performing hardware.

In many cases, the topology that meets an organization’s minimum availability requirements is used as a starting point and server computers are added or scaled up to meet capacity and performance goals.

64-bit vs. 32-bit

Although Microsoft Office SharePoint Server 2007 can be deployed on 32-bit servers, Microsoft recommends that you employ 64-bit servers in Office SharePoint Server 2007 farm deployments. The guidance presented in this guide is based on testing conducted on 64-bit servers. Therefore, if you are planning to deploy to 32-bit servers, you should perform additional testing on the 32-bit servers in your environment. The best practices and performance trends in this guide will still generally apply to 32-bit environments, but actual results may vary.

The 64-bit system architecture has several characteristics that contribute to superior server scalability and performance:

  • Memory addressability   A 32-bit system can directly address only a 4-GB address space. Windows Server 2003 SP1 running on a 64-bit system architecture supports up to 1,024 gigabytes of both physical and addressable memory.

  • Larger numbers of processors and more linear scalability per processor   Improvements in parallel processing and bus architectures enable 64-bit platforms to support larger numbers of processors (up to 64) while providing close to linear scalability with each additional processor. Server platforms that offer more than 32 CPUs are available exclusively on 64-bit architecture.

  • Enhanced bus architecture   The bus architecture on current 64-bit chipsets is faster and wider than earlier generations. More data is passed to the cache and processor; this is somewhat analogous to the improvement that broadband connections offer over dial-up connections.

For more information on deploying Office SharePoint Server 2007 on 32-bit servers, see Planning recommendations for Web servers (Office SharePoint Server).

Referencia: http://technet.microsoft.com/en-us/library/cc261700.aspx

Si alguien más desea compartir sus comentarios sobre este tema con mucho gusto le invito a que deje sus comentarios.

Reporting Services y su integración con SharePoint

A cotinuación me gustaría compartir con ustedes una recopilación de ligas interesantes que nos podrían ser de utilidad en un momento dado, respecto a Reporting Services y SharePoint


 


How to: Add Report Server Content Types to a Library (Reporting Services in SharePoint Integrated Mode)


http://msdn.microsoft.com/en-au/library/bb326289.aspx


Microsoft SQL Server Reporting Services – Installation and Configuration Guide for SharePoint Integration Mode (Important)


http://yasirbutt.spaces.live.com/Blog/cns!A8677D5751E6B4DA!1135.entry


Microsoft SQL Server 2008 Reporting Services Add-in for Microsoft SharePoint Technologies


http://www.microsoft.com/downloads/details.aspx?FamilyID=200fd7b5-db7c-4b8c-a7dc-5efee6e19005&DisplayLang=en


Integración de Reporting Services con SharePoint


http://geeks.ms/blogs/ciin/archive/2007/03/02/integraci-n-de-reporting-services-con-sharepoint-i.aspx


WSS 3.0 & MOSS: ¿Qué pasa con la integración con SSRS 2008?


http://geeks.ms/blogs/ciin/archive/2008/08/10/wss-3-0-amp-moss-191-qu-233-pasa-con-la-integraci-243-n-con-ssrs-2008.aspx


Information Integration: SSRS and MOSS 2007


http://officesharepointpro.com/content/1879/Information-Integration–SSRS-and-MOSS-2007–.aspx


FIX: You receive an error message when you try to access a report after you configure SQL Server 2005 Reporting Services to run under the SharePoint integrated mode


http://support.microsoft.com/kb/939942


Update 29 de Agosto de 2008


El buen amigo Juan Carlos González nos ha proporcionado la liga de un nuevo post que an hecho desde el Blog del CIIN al respecto, MOSS 2007 con SQL Server Reporting Services (SSRS) 2008, que recomendamos mucho también, aqui la liga.


http://geeks.ms/blogs/ciin/archive/2008/08/25/sharepoint-y-ssrs-2008-i.aspx


Si alguien quiere añadir o compartir otras con gusto lo puede hacer mediante el uso de comentarios a este post.

Que enfoque debo de tomar para migrar mi servidor de SharePoint a la nueva versión 2007

Determinación del enfoque de actualización (Office SharePoint Server)

En este artículo:

Antes de ejecutar cualquier proceso de actualización, debe determinar qué enfoque de actualización va a tomar. Use la información de este artículo para comparar las ventajas y los inconvenientes de cada enfoque y revise la información acerca de casos especiales que pueden afectar al enfoque elegido. Además de la información de este artículo, asegúrese de leer Revisión de rutas de actualización admitidas y no admitidas para entender exactamente qué situaciones de actualización son válidas y tienen resultados correctos.

Elección de un enfoque de actualización

En la tabla siguiente se muestran y comparan distintos enfoques de actualización.

Enfoque Descripción Ventajas Inconvenientes Óptimo para

Actualización inmediata (In-Place Update)

Actualiza el esquema de las bases de datos de contenido ahí mismo sin hacer copias ni replicas de una nueva versión.

Enfoque más sencillo. Los sitios conservan las direcciones URL originales. Actualiza las bases de datos  utilizando las rutas y hardware actual.

 

El entorno está sin conexión mientras se ejecuta, ya que todos los sites se van actualizando uno por uno sin necesidad de especificar el proceso manual o seleccionar cual se desea actualizar. No es posible revertir al sitio original. (No Rollback)

Servidor único o granja de servidores pequeña.

Actualización gradual (Gradual Update)

Instala la nueva versión en paralelo con la versión anterior (en el mismo servidor). El administrador del servidor determina qué colecciones de sitios se actualizarán y cuándo se actualizarán.

 

Permite usar un enfoque más granular: se actualiza a nivel colección de sitio. Reduce el tiempo durante el que se ve afectado cualquier usuario individual. Ya que se puede seleccionar por site collection individual cual se desea migrar y mientras los demás site collections estarán disponibles para los usuarios. Los sitios nuevos o migrados a la nueva versión automáticamente tomarán la ruta original, y los sitios originales (versión anterior) tomarán una nueva ruta especificada por el administrador durante la migración.Se puede revertir por lo tanto al sitio original. Usa el hardware existente.

 

Es un método más complejo y usa más recursos. Debe redirigir direcciones URL durante el proceso de actualización, lo cual provoca problemas en el caso de algunas aplicaciones cliente como Microsoft Office. Requiere almacenamiento adicional en SQL Server. No se admite el modo de hospedaje escalable de Microsoft Windows SharePoint Services 2.0.

Granjas de servidores medianas o grandes (sin servicios compartidos) con muchos sitios para las que debe limitar el tiempo de inactividad. Conveniente cuando el entorno tiene numerosas personalizaciones.

Migración de bases de datos (avanzada)

Requiere que el administrador del servidor instale la nueva versión en una granja de servidores separada o en hardware separado y que después migre manualmente las bases de datos (de contenido de las Aplicaciones Web) al nuevo entorno.

Permite la migración a una nueva granja de servidores o nuevo hardware. El entorno de SharePoint Portal Server 2003 está disponible y queda intacto tras la actualización.

Proceso complejo que requiere muchos pasos manuales y conlleva un mayor riesgo de errores. Requiere pasos manuales adicionales para conservar las direcciones URL originales de los sitios. Se deben volver a crear los ámbitos de búsqueda y se debe volver a aplicar la configuración de búsqueda. Requiere una nueva granja de servidores y el doble de espacio de almacenamiento en SQL Server.

 

Quienes van a pasar a un nuevo hardware o una nueva arquitectura. Quienes necesitan maximizar el rendimiento de la actualización. Este enfoque es necesario para entornos con Windows SharePoint Services 2.0 que usan el modo de hospedaje escalable o el modo de creación de cuentas del servicio de directorio de Active Directory.

Migración de Windows SharePoint Services 2.0 a Microsoft Office SharePoint Server 2007.

Actualización gradual para servicios compartidos

Igual que la actualización gradual, pero con pasos de actualización separados para actualizar sitios de portal primarios y secundarios.

Igual que la actualización gradual, pero podrá actualizar sitios de portal primarios y secundarios de forma individual.

 

Igual que la actualización gradual, pero además: dos rastreos de búsqueda están activos en el mismo momento para los entornos de Microsoft Office SharePoint Portal Server 2003 y Office SharePoint Server 2007.

Granja de servidores de cualquier tamaño con servicios compartidos.

Enfoque híbrido (avanzado) de actualización gradual más migración de bases de datos

 

Use un enfoque de actualización gradual para crear un proyecto piloto del proceso de actualización con varias colecciones de sitios y determinar si hay algún problema que necesita resolverse. A continuación, cuando esté seguro de que la actualización se está llevando a cabo sin problemas, use la migración de bases de datos en una copia de las bases de datos para acelerar el proceso de actualización.

Más rápido que usar sólo la actualización gradual.

Le permite probar el proceso de actualización con unos pocos sitios en la actualización gradual, con la opción de revertir los sitios si es necesario.

Sin reversión para la migración de bases de datos, de modo que debe tener una copia de seguridad de las bases de datos originales o realizar la migración en copias de las bases de datos.

Quienes necesitan maximizar el rendimiento de la actualización.

Para obtener más información acerca del funcionamiento de las actualizaciones inmediata y gradual, consulte Funcionamiento del proceso de actualización (Office SharePoint Server).

Casos especiales

Es posible que tenga otros requisitos u objetivos adicionales que desea lograr al realizar la actualización. En la siguiente tabla se incluyen casos especiales y se indica qué enfoque de actualización resulta más apropiado para cada caso.

Caso Enfoque de actualización que hay que adoptar

¿Va a cambiar el idioma?

Tiene dos opciones, dependiendo de si va a cambiar de idioma un único sitio o todo el entorno:

  • Para cambiar el idioma de un sitio específico, realice la actualización en el mismo idioma y luego instale el nuevo paquete de idioma y cambie a ese idioma.

    Precaución:

    Debe tener los paquetes de idioma adecuados instalados para actualizar cualquier sitio basado en una definición del sitio localizada. Si no tiene el nuevo paquete de idioma, no se podrá tener acceso a los sitios. Espere a que se publiquen los nuevos paquetes de idioma antes de intentar actualizar estos sitios.

 

  • Para cambiar el idioma de instalación de los servidores, use el enfoque de migración de bases de datos para migrar los datos desde la versión y el idioma anteriores a la versión y el idioma nuevos.

¿Va a pasar a Windows Server® 2008?

 

Primero actualice a Office SharePoint Server 2007 mediante una actualización inmediata o gradual y, a continuación, actualice a Windows Server 2008.

¿Va a actualizar desde SharePoint Portal Server 2001?

 

Actualice a SharePoint Portal Server 2003 y luego actualice a Office SharePoint Server 2007. Para obtener más información acerca de la migración de SharePoint Portal Server 2001 a SharePoint Portal Server 2003, consulte Recursos de migración a SharePoint Portal Server 2003 (http://office.microsoft.com/es-es/sharepointserver/default.aspx). La actualización directa desde SharePoint Portal Server 2001 no es soportada. Sin embargo, puede usar una solución de algún socio de negocio o Partner de Microsoft para actualizar el contenido del sitio directamente. Para obtener más información acerca de los socios de actualización, consulte la página sobre migración y actualizaciones de TechNet (http://technet.microsoft.com/es-es/sharepointserver/bb421259.aspx).

¿Va a actualizar desde SharePoint Team Services?

 

Actualice a Windows SharePoint Services 2.0 y luego a Windows SharePoint Services 3.0. Después puede instalar Office SharePoint Server 2007 o migrar el contenido a Office SharePoint Server 2007. Para migrar el contenido, use una herramienta (suministrada, creada por usted o usada bajo la licencia de un socio de Microsoft) para importar el contenido a su sitio de Office SharePoint Server 2007. La actualización directa desde SharePoint Team Services no se admite.

¿Va a actualizar desde Windows SharePoint Services 2.0?

 

Use el método de migración de bases de datos para migrar las bases de datos de contenido de Windows SharePoint Services 2.0 a Office SharePoint Server 2007. Este proceso de migración realiza una actualización inmediata del contenido del sitio. Para obtener más información, consulte Introducción al capítulo: implementación de una granja de servidores nueva y migración de bases de datos (Office SharePoint Server).

¿Va a actualizar desde Microsoft Content Management Server 2002?

 

Consulte Migración de Microsoft Content Management Server 2002 a Office SharePoint Server 2007 y la página sobre migración y actualizaciones de TechNet (http://technet.microsoft.com/es-es/sharepointserver/bb421259.aspx).

¿Va a actualizar desde SharePoint Portal Server 2003 con el conector SPARK para Microsoft Content Management Server 2002?

 

Consulte Migración de Microsoft Content Management Server 2002 a Office SharePoint Server 2007 y la página sobre migración y actualizaciones de TechNet (http://technet.microsoft.com/es-es/sharepointserver/bb421259.aspx). Enfoque recomendado: actualice los sitios de portal de SharePoint Portal Server 2003 y luego use las herramientas de migración de MCMS para migrar el contenido de MCMS 2002 a los sitios de portal actualizados.

¿Va a actualizar desde un entorno que incluía Microsoft Office Web Components (http://www.microsoft.com/downloads/details.aspx?displaylang=es&FamilyID=7287252c-402e-4f72-97a5-e0fd290d4b76)?

 

Estos componentes seguirán funcionando en la nueva versión si usa una actualización inmediata o gradual. Sin embargo, el enfoque de migración de bases de datos no funciona para estos componentes, porque sólo se pueden instalar en un entorno con Windows SharePoint Services 2.0 o SharePoint Portal Server 2003. Si va a actualizar a la Licencia de acceso de cliente (CAL) Enterprise de Office SharePoint Server 2007, considere la posibilidad de usar las capacidades de Excel Services en el nuevo entorno en lugar de Office Web Components.

Versiones de SharePoint 2007 – HotFixes, SPs e Infrastructure Update

Para cuando sea necesario…

Service Pack/Hotfix Version WSS V3.0 MOSS 2007

Infrastructure Update (KB951695 & KB951297)

12.0.0.6318

12.0.0.6318

Post-SP1 hotfix (KB953137 & KB953138)

12.0.0.6316.500

12.0.0.6316.500

Post-SP1 hotfix (KB952698 & KB952704)

12.0.0.6315

12.0.0.6315

Post-SP1 hotfix (KB948945)

12.0.0.6303

12.0.0.6303

Post-SP1 hotfix (KB941274)

12.0.0.6301

12.0.0.6301

Post-SP1 hotfix (KB941422)

12.0.0.6300

12.0.0.6300

Service Pack 1

12.0.0.6219

12.0.0.6219

Release To Manufacturing (RTM)

12.0.0.4518

12.0.0.4518

 

Referencia: http://blogs.msdn.com/aaronsaikovski/archive/2008/07/31/quick-field-reference-moss-2007-wss-v3-0-version-guide.aspx

Planeación de un ambiente redundante para SharePoint

Hace unos días tuve que diseñar una arquitectura redundante para un cliente. Revisando si había nueva información al respecto me tope con información en technet, donde se habla de redundancia (disponibilidad) y performance.


Es muy importante definir con el clienre cual o cuáles son sus prioiridades al momento de definir el alcance y objetivo de dicho diseño. El artículo que les recomiendo a continuación maneja de una forma muy sencilla estos conceptos y nos da recomendaciones de como podemos configurar los distintos roles de sharePoint según el hardware con el que se cuente.


A continuación comparto los temas que trata el artículo.


In this article:


El artículo empieza explicando los conceptos básicos de redundancia y performance, y comienza a dar recomendaciones empezando con una topología mínima, recomendando por small server farm, y de ahí hacia delante.

Otro punto importante en esta definición fue que el cliente comprendiera de los distintos roles que maneja SharePoint cuales si puede configurarse de forma redundante y cuales no.

Por último y me parece muy valioso, tenemos la información de que pasaría si perdemos temporalmente cada uno de los distintos roles que manejamos con SharePoint y cuál sería el impacto.

Existen también otros whitepapers muy interesantes para planeación de storage por ejemplo en SQL para SharePoint e incluso recomendaciones para SQL Server especialmente para tener un mejor performance para las bases de SharePoint. No olvidemos la información también para recuperación de desastres o distintos escenarios para configurar un ambiente de alta disponibilidad en el backend (Mirroring o Log Shipping), estos son algunos de los whitepapers que también hablan de recomendaciones y mejores prácticas que no debemos de dejar pasar, aunque hay mucha información adicional que también vale la pena tener en cuenta.


Update 18 Agosto, 2008


Otro punto sumamente importante cuando estamos pensando en planear la disponibilidad y/o redundancia requerida para que nuestro ambiente de SharePoint siempre esté arriba . Pero que pasa cuando algo imprevisto sucede y perdemos el acceso o disponibilidad a nuestro contenido, siempre es importante considerar formas, escenarios, posibles maneras o estrategias de recuperar nuestra información. Preguntas tan importantes y necesarias, como ¿Cómo puedo respaldar la información de SharePoint?, ¿Cómo puedo respaldar o generar backups de la información que tengo almacenada en SharePoint? y no solo respaldarla sino restaurarla, ¿Cómo puedo recuperar la información que tengo en SharePoint?, de listas de bibliotecas de documentos, de sites, o sub sites, de site Collections, de bases de datos o a nivel Web Applications, incluso de toda la granja…y de otras variaciones, como ¿Cómo puedo recuperar la información almacenada en Mis Sitios personales o como puedo recuperar Mis Sitios personales?, o ¿Cómo puedo respaldar la información y configuración de mi Shared Servics Provider o Proveedor de Servicios Compartidos?, incluso ¿Qué puedo o como puedo respaldar o guardar lo disponible de mis forms de InfoPath?, Incluso ¿Cómo respaldar la configuración del Single Sign-On?, estas y otras preguntas interesantes pueden ser respondidas en el Resource Center de TechNet para SharePoint 2007, enfocado a BackUp (Respaldos), Restore (Restauración), y planeación de Disponibilidad (Availability), justo aquí.