Procedimientos recomendados y estrategias de recuperación ante desastres para la búsqueda de SharePoint

SE APLICA A:2013 2016 2019 Subscription Edition SharePoint en Microsoft 365

Obtenga información sobre cómo implementar la recuperación ante desastres de procedimientos recomendados para la búsqueda en una granja de servidores de SharePoint Server.

En este artículo se proporcionan instrucciones de procedimientos recomendados que puede usar para desarrollar una estrategia de recuperación ante desastres (DR) compatible para la búsqueda en SharePoint Server. Muchos de los enfoques usados para la recuperación ante desastres en versiones anteriores de SharePoint Server no proporcionan el mismo nivel de recuperación para SharePoint Server. Analizamos estos enfoques y brindamos opciones de reemplazo junto con los beneficios y las limitaciones que debe conocer.

Introducción

En este artículo se cierra la brecha entre la documentación que proporciona una hoja de ruta para implementar una estrategia de recuperación ante desastres y documentación que proporciona los comandos específicos para configurar la recuperación ante desastres para la aplicación de servicio SharePoint ServerSearch (SSA). Describimos varios escenarios de recuperación ante desastres típicos y analizamos los beneficios y las limitaciones de cada enfoque. Es poco realista pensar que estos escenarios se adaptan a la perfección a su organización, pero puede usarlos como guía para una estrategia de recuperación ante desastres que cumpla con los requisitos específicos de su organización.

La recuperación ante desastres para SharePoint Server y sus tecnologías auxiliares es un tema complejo y hay muchas fuentes de información dedicadas a explicar el planeamiento necesario para ayudar a garantizar que se cumplen los objetivos empresariales si hay un evento que activa el plan de recuperación ante desastres.

Como procedimiento recomendado, sugerimos empezar por identificar y cuantificar claramente los objetivos de tiempo de recuperación (RTO) y los objetivos de punto de recuperación (RPO) para su organización. El RTO, el tiempo requerido para recuperarse de un desastre, y el RPO, los datos medidos en tiempo que puede perder ante el mismo desastre, son las métricas clave para la planeación de recuperación ante desastres. Estas dos métricas basadas en la empresa preparan el camino para lo siguiente:

• Almacenamiento, medios y procedimientos de copia de seguridad y restauración

• Ubicación en la que se realiza la recuperación

• Tamaño y complejidad de la solución de recuperación

No se puede desarrollar una estrategia de recuperación eficaz y evaluar soluciones técnicas sin estos puntos de referencia.

Aunque el ámbito de este artículo es la recuperación ante desastres para la búsqueda de SharePoint Server, se recomienda leer Elegir una estrategia de recuperación ante desastres para SharePoint Server como preparación para desarrollar una estrategia de recuperación ante desastres.

Arquitectura de la aplicación de servicio de búsqueda

Antes de examinar las diferentes formas de desarrollar una estrategia de recuperación ante desastres, en la tabla siguiente se proporciona una descripción de los componentes de la búsqueda de SharePoint Server y cómo contribuyen a la experiencia de búsqueda del usuario final. Las bases de datos y los componentes de la aplicación de búsqueda descritos en la tabla siguiente proporcionan un contexto para una estrategia de recuperación ante desastres.

Componentes del servicio de búsqueda

Hay varias formas de distribuir los componentes de búsqueda para proporcionar una topología de búsqueda altamente escalable y disponible, tal como se muestra en el diagrama siguiente. En este diagrama, los componentes de búsqueda se implementan en distintos servidores de aplicaciones a fin de proporcionar redundancia. Asimismo, los servidores de aplicación se implementan en distintos servidores de host de virtualización, lo que proporciona otro nivel de tolerancia a errores y brinda escalabilidad.

Para obtener más información sobre la distribución de componentes de búsqueda en servidores de granja de servidores, vea Planear la arquitectura de búsqueda empresarial en SharePoint Server 2016 y buscar diagramas técnicos en Buscar en SharePoint Server 2016.

Para apreciar las complejidades del desarrollo de una estrategia de recuperación ante desastres de búsqueda, debe comprender cómo se hace referencia a los documentos dentro del índice y las bases de datos de la aplicación de servicio de búsqueda. Es este sistema de referencia lo que actualmente hace imposible usar cualquier forma de tecnología de replicación o trasvase de registros para copiar los índices de búsqueda entre granjas de servidores de SharePoint Server.

Información general de la estructura del índice de la aplicación de servicio de búsqueda

Debido a que la estructura del índice de la aplicación de servicio de búsqueda de SharePoint es tan compleja, en este artículo no es posible proporcionar una descripción muy detallada. En términos sencillos, el índice consta de muchas piezas pequeñas que son una serie de grupos de datos que se pueden actualizar. Imagínese que estos grupos que se pueden actualizar son como particiones de las columnas de una tabla. De forma predeterminada, hay seis grupos de este tipo en el índice de búsqueda. Estos grupos son los siguientes:

• Principal: contiene los campos en bloque, el texto completo se almacena aquí.

• ACL: comprende el recorte de seguridad y el rastreo de seguridad veloz.

• Ruta de acceso y título: contiene la ruta de acceso y el título.

• Recomendaciones: tenga en cuenta que estos datos se actualizan diariamente.

• Compañeros sociales (Personas): comprende un grupo de actualización separado para los campos de las personas.

• Etiquetas temáticas: contiene etiquetas temáticas.

Considere cada grupo de actualización como una estructura de índice para los campos que forman parte de ese grupo, similar en estructura a una base de datos de SQL Server. Los grupos de actualización se particionan en el nivel de almacenamiento en archivos, cada uno de los cuales contiene un fragmento de la estructura del índice. Cada uno de estos archivos contiene una parte diferente del índice general. El contenido se distribuye por estas particiones mediante un identificador para cada documento exclusivo. Este identificador es el DocID, que es además un contador.

Cuando se crea una aplicación de servicio de búsqueda nueva, el contador empieza en cero. El DocID se incrementa de a uno cada vez que se detecta un elemento nuevo durante un rastreo, y el contador continúa aumentando con el transcurso del tiempo a medida que se detectan elementos nuevos. El valor del contador nunca disminuye. Incluso si un documento se elimina, el valor correspondiente del contador jamás se vuelve a utilizar. El hecho de agregar y quitar documentos o elementos de las bibliotecas y las listas con el tiempo también implica que el DocID no tenga una numeración consecutiva dentro de algún sitio o biblioteca. Por lo tanto, es imposible predecir el DocID de algún documento en el conjunto de búsqueda.

Lo que representa un desafío para cualquier estrategia de replicación de búsqueda es el hecho de que en dos granjas no hay garantía, ni siquiera la probabilidad, de que los valores de DocID coincidan para algún documento de la granja. Dado que los valores de DocID no coincidirán, es imposible replicar los datos del índice o los datos de análisis que están vinculados al valor de DocID. Los resultados de la búsqueda no serán válidos porque el mismo documento tendrá un DocID diferente en cada granja.

Al analizar cómo se debe crear una estrategia de recuperación ante desastres de total fidelidad para la aplicación de servicio de búsqueda, es importante que sucedan dos cosas:

• Los componentes y las bases de datos que almacenan los datos necesarios para la configuración y las consultas se identifican y se restauran correctamente en la granja de recuperación ante desastres de destino mediante un método apropiado.

• La granja de recuperación ante desastres de destino se escala como corresponde según el número correcto de componentes para soportar el tamaño del servicio de búsqueda.

En las siguientes secciones se hará referencia a estas dos actividades y se proporcionarán detalles técnicos en las secciones de implementación.

Técnicas frecuentes de recuperación ante desastres

En las versiones anteriores de SharePoint, había varias formas de asegurarse de que tenía una aplicación de servicio de búsqueda de conmutación por error rellenada con índices actualizados y casi el 100 % de actualización de búsqueda. En los ejemplos siguientes se muestran los enfoques que se usaban con frecuencia para la recuperación ante desastres.

• El rastreo de las bases de datos de contenido de solo lectura era una opción, en la que se usaban los métodos de envío del registro de SQL Server para mantener una copia de las bases de datos de contenido de producción conectadas a la granja de recuperación ante desastres en modo de solo lectura. Esto significa que podía configurarse una SSA hospedada en la granja de recuperación ante desastres para rastrear las bases de datos mediante una aplicación web de solo lectura en la granja de recuperación ante desastres. Cualquier cambio en la configuración debía implementarse en el nivel de SSA en ambas granjas a fin de garantizarles a los usuarios finales una experiencia de total fidelidad en el caso de una conmutación por error.

• Con la opción de rastreo doble, la granja de recuperación también rastreaba la granja de producción y, por ende, se detectó e indexó el mismo contenido. Los cambios en la configuración de las propiedades administradas o los tipos de archivos rastreados, los IFilters instalados, etc. debían implementarse tanto en las granjas de producción como en las de recuperación ante desastres, pero esto se administraba fácilmente mediante una directiva de control de cambio apropiada.

Otras opciones de estrategias de recuperación ante desastres no ofrecían el mismo nivel de actualización del índice de búsqueda, pero si la actualización del índice o el tiempo de recuperación no eran críticos, entonces se consideran opciones válidas. Por lo general, estas opciones son más complejas de configurar e implementar. Los siguientes ejemplos son enfoques típicos.

• Podía hacerse una copia de seguridad de la base de datos de la Administración de búsqueda de SSA de forma independiente. La base de datos de administración de búsqueda de SSA se realiza una copia de seguridad independientemente mediante enfoques de copia de seguridad de SQL Server convencionales y se usa en la granja de servidores de recuperación ante desastres para crear una SSA mediante Microsoft PowerShell. Esto restaura la configuración de búsqueda pero no los índices. Se necesita un rastreo total para rellenar los índices de búsqueda y completar la recuperación.

• Copia de seguridad y restauración total de SSA. Una copia de seguridad y restauración completa de SSA se realiza mediante Microsoft PowerShell o mediante la interfaz del sitio web de Administración central de SharePoint. De esta forma, se realiza una copia de seguridad de las bases de datos y los índices de búsqueda de SSA, lo que permite restaurarlos en la granja de recuperación ante desastres para rellenar el SSA en dicha granja.

A partir de SharePoint Server 2013, los cambios significativos en la arquitectura de búsqueda y cómo se almacenan los elementos de configuración significan que tenemos que pensar de manera diferente en la recuperación ante desastres de búsqueda. En las secciones siguientes se describen estos cambios y de qué manera afectan a las opciones de recuperación ante desastres que están disponibles.

Configuración y cambios funcionales en la experiencia de búsqueda

Las páginas Administración del sitio de SharePoint Server proporcionan opciones que admiten una configuración flexible de la experiencia de búsqueda. Las nuevas opciones de configuración para sitios y colecciones de sitios significan que los administradores de sitios pueden realizar cambios de configuración de búsqueda que anteriormente solo podían realizar los administradores de la granja de servidores o de búsqueda. En la siguiente captura de pantalla se muestran las dos ubicaciones en las que puede configurar opciones de búsqueda: en Administración de la colección de sitios o en Búsqueda.

Puede hacer un cambio en la configuración de un elemento de búsqueda, como reglas de consulta u orígenes de resultados, desde la lista que se encuentra debajo de Administración de la colección de sitios o Búsqueda, y el resultado será el mismo. No obstante, la ubicación donde se almacena un cambio afecta a la recuperación ante desastres. Todos los cambios realizados en una colección de sitios o una aplicación web se almacenarán únicamente en la base de datos de administración de la aplicación de servicio de búsqueda (SSA). A menos que esta base de datos se restaure a partir de una copia de seguridad de una granja de recuperación ante desastres, los cambios en la configuración no estarán disponibles en el entorno recuperado.

Otra característica nueva de la búsqueda de SharePoint Server es la funcionalidad ReIndex Now que permite a los administradores de los niveles Colección de sitios, Web y Lista solicitar una reindexación del contenedor durante el siguiente rastreo. Esta característica se administra por completo dentro de la base de datos de contenido y, por ende, el administrador que la solicita dentro de la granja de recuperación ante desastres desencadenará el mismo evento en la granja de producción cuando el siguiente rastreo se ejecute en la graja de recuperación ante desastres.

Recomendaciones del usuario controladas por el análisis de búsqueda

En SharePoint Server Search, el procesamiento del análisis de uso y búsqueda se controla mediante un componente denominado procesador de Análisis. Este componente tiene las siguientes responsabilidades:

• Controla el procesamiento de la información del análisis de búsqueda.

• Procesa el análisis de uso.

• Proporciona información relacional que el procesador de contenido usa para admitir la función de recomendaciones de la búsqueda.

• Proporciona información sobre estadísticas sobre la popularidad del documento (por ejemplo, visitas y clic en las páginas) que el procesador de contenido usa para mejorar la relevancia y los cálculos de clasificación.

Para obtener más información sobre los procesos de análisis individuales, vea Información general sobre el procesamiento de análisis en SharePoint Server para obtener información detallada.

La información procesada se almacena en el índice de búsqueda y también mediante las bases de datos de informes y vínculos. Por lo tanto, el único método capaz de garantizar que esta información procesada se replica en la granja de recuperación ante desastres en un estado sincronizado es un proceso de copia de seguridad y restauración total de la aplicación de servicio de búsqueda.

Mejoras en las copias de seguridad y restauración de la aplicación de servicio

El enfoque que satisface todos los requisitos de recuperación ante desastres para capturar los datos de configuración e índice es la copia de seguridad y la restauración de la aplicación de servicio. Se ha invertido considerablemente en estas operaciones a fin de reducir el RTO y el RPO en comparación con las versiones anteriores de SharePoint. Entre los beneficios clave en esta área se encuentran: la compatibilidad para cambiar el número de subprocesos utilizados en los procesos de copia de seguridad y restauración y las mejoras al admitir tanto operaciones de copia de seguridad y restauración completas como diferenciales.

Cuando se adopta el enfoque de copia de seguridad y restauración total de la aplicación de servicio de búsqueda como la estrategia de recuperación ante desastres, el RPO total está controlado por dos elementos. El tiempo desde la última copia de seguridad total de la aplicación de servicio es el RPO y el tiempo necesario para llevar a cabo una restauración de la aplicación de servicio es el RTO. Es probable que ambos tiempos aumenten a medida que se incremente el contenido en la aplicación de servicio de búsqueda, por lo que se necesita una cuidadosa administración de la expectativa de la restauración de servicio en caso de que se declare un desastre. Recomendamos llevar a cabo restauraciones de prueba frecuentes como parte de los ejercicios de administración de continuidad del servicio para asegurarse de que pueda cumplirse cualquier SLA según los RTO y RPO requeridos. En la tabla siguiente se resumen las opciones de copia de seguridad y restauración para la aplicación de servicio de búsqueda.

Técnicas admitidas para la recuperación

Hay solo una técnica de recuperación ante desastres compatible que proporcionará una recuperación de fidelidad total y que incluye todas las mejoras de procesamiento de análisis realizadas al índice de búsqueda y todos los elementos de configuración de búsqueda en la aplicación de servicio, la colección de sitios y los niveles web dentro de la granja de producción. Este enfoque requiere una copia de seguridad total de la aplicación de servicio de búsqueda seguida por una restauración total de la aplicación de servicio en la granja de recuperación ante desastres. Los índices y la configuración se restaurarán al mismo punto en el tiempo en que se realizó la copia de seguridad, por lo tanto si la copia de seguridad tenía varios días de antigüedad, se requerirá un nuevo rastreo para actualizar los índices. Los pasos específicos para este enfoque se describen más adelante en este documento.

También es posible realizar una copia de seguridad de la base de datos de administración de la aplicación del servicio de búsqueda y restaurarla en el sitio de recuperación ante desastres. Con Microsoft PowerShell, los administradores pueden crear una nueva aplicación servicio Search mediante la copia de seguridad. Sin embargo, esto solo recuperará la configuración real de la aplicación de servicio de búsqueda y la configuración de búsqueda personalizada dentro de los sitios web de SharePoint, no recuperará el índice de búsqueda. Se deberá realizar un rastreo completo para rellenar el conjunto de búsqueda. Además, no se puede recuperar la aumentación analítica de los índices de búsqueda porque las señales que se usaron para generarla solo residen en la granja de producción.

Hay otro enfoque que puede adoptarse si el propósito principal de tener que incluir la búsqueda en la estrategia de recuperación ante desastres es ayudar a garantizar la actualización del índice de búsqueda en el momento de conmutación por error. Mediante uno de estos dos métodos, el índice puede mantenerse actualizado pero con la introducción de una configuración compleja y de varias limitaciones. La complejidad surge porque los rastreadores de la granja de recuperación ante desastres deben configurarse para rastrear la granja de producción, o las bases de datos de contenido deben replicarse en un estado que se puedan leer en la granja de recuperación ante desastres para admitir el rastreo local. Este enfoque presenta limitaciones en cuanto a que la configuración de la aplicación de servicio de búsqueda en la producción no se replica de ninguna forma en la recuperación ante desastres, y también faltan las actualizaciones del índice de búsqueda del procesamiento de datos de análisis. Si estas limitaciones son aceptables, se trata de una manera muy flexible de garantizar una buena actualización del índice y disponibilidad de búsqueda en la granja de recuperación ante desastres.

Un enfoque final es combinar las dos técnicas descritas anteriormente en una sola estrategia que proporciona una buena actualización del índice de búsqueda en conmutación por error pero agrega la posibilidad de realizar una restauración total para llevar la información de análisis y la configuración de búsqueda a través de la granja de recuperación ante desastres.

En este caso, se emplearía una copia de seguridad completa y un rastreo local o remoto y estaría disponible un proceso para la restauración, si fuera necesario. Una razón típica para comenzar el proceso de restauración total es si la conmutación por error al sitio de recuperación ante desastres es más que una interrupción temporal al servicio normal y la conmutación por recuperación de la producción no es posible en un período de tiempo acordado. En ese caso, se invocaría el proceso de restauración a fin de garantizar que la experiencia de búsqueda con total fidelidad esté disponible en el sitio de recuperación ante desastres. Además, se iniciaría un nuevo rastreo para que el índice de búsqueda esté totalmente actualizado.

Hay implicaciones al restaurar una aplicación de servicio de búsqueda que usa la opción de sobrescritura. La aplicación de servicio estará sin conexión durante la restauración, lo que significa que no se procesarán actualizaciones ni consultas. Para un negocio en el que la búsqueda no es una función crítica, es probable que esto no represente un problema. Sin embargo, si la funcionalidad de consulta de búsqueda debe estar disponible durante la restauración, se puede considerar otra opción. La opción alternativa es siempre crear una nueva aplicación de servicio de búsqueda durante el proceso de restauración y, cuando la restauración está completa, ejecutar un nuevo rastreo para obtener la actualización del índice. Después de que finaliza el rastreo, se cambia la asociación de la aplicación de servicio con la nueva aplicación de servicio. La aplicación de servicio anterior puede eliminarse. El mayor desafío es un tema de capacidad, ya que básicamente debe duplicarse el índice y el espacio de la base de datos para hospedar dos aplicaciones de servicio en paralelo. La criticidad de los servicios de búsqueda determinará si hay algo que la empresa debe acomodar.

Teniendo en cuenta todos estos elementos, vale la pena investigar los requisitos de RPO y RTO esperados de la aplicación de servicio de búsqueda. Actualmente, SharePoint admite un RPO y un RTO de una semana para la aplicación de servicio de búsqueda. Esto significa que los elementos de configuración, la información procesada del análisis y la actualización de la búsqueda pueden estar cómo máximo una semana desactualizados cuando se realiza la restauración. Una vez más, según la tasa de cambio esperada en el entorno y la criticidad de la configuración de la búsqueda, puede ser prudente ejecutar diariamente o incluso varias veces en el día copias de seguridad a fin de garantizar que se pueda lograr un RPO y RTO óptimos para la empresa. No existen requisitos en cuanto al mantenimiento de varias copias de seguridad, como ocurre con las copias de seguridad de contenido porque el contenido de búsqueda es muy fluido y transitorio, por lo que como mucho se retendrían una o dos copias de seguridad completas.

Copia de seguridad y restauración de la aplicación de servicio

La siguiente información es un breve resumen de los puntos clave contenidos en los artículos De copia de seguridad y restauración de búsqueda:

• Copias de seguridad de aplicaciones de servicio de búsqueda en SharePoint Server

• Restaurar aplicaciones de servicio de búsqueda en SharePoint Server

La frecuencia con la que deben realizarse las copias de seguridad del servicio de búsqueda se ve influenciada por varios elementos, pero principalmente el controlador clave será el RPO que requiere la empresa. A medida que aumenta el tamaño del índice de búsqueda, el tiempo que se requiere para realizar una copia de seguridad y una restauración de la aplicación de servicio será cada vez mayor. Solo se puede realizar una copia de seguridad de la búsqueda por vez, y el tiempo que demora en completarse la copia de seguridad es el RPO mínimo que puede lograrse. El tiempo que lleva completar la restauración en la granja de recuperación ante desastres es, por lo tanto, el RTP mínimo que se puede lograr y, al igual que el tiempo de la copia de seguridad, se extenderá con el transcurso del tiempo. Si los tiempos de copia de seguridad y restauración comienzan a infringir los contratos de nivel de servicio (SLA) para los RPO y RTO de búsqueda, la empresa debe tomar algunas decisiones y seguir un enfoque más flexible con menos fidelidad, tal como se describe más adelante en este tema, o ajustar los SLA para cumplir con el objetivo que se quiere lograr.

Copia de seguridad de la aplicación de servicio de búsqueda

Para realizar una copia de seguridad de la aplicación de servicio de búsqueda, puede usar Microsoft PowerShell o la interfaz de usuario de administración central. El cmdlet de PowerShell requerido es el siguiente:

Backup-SPFarm -Directory <Backup Folder> - BackupMethod <Full | Differential> -Item <Full Path to Search Service Application>

Aquí le mostramos un ejemplo:

Backup-SPFarm -Directory \\server\searchbackup - BackupMethod Full -Item "Farm\Shared Services\Shared Services Applications\Contoso Search Service Application"

En este ejemplo se realizará una copia de seguridad completa de la aplicación servicio Search denominada Contoso Search Service Application y se almacenarán los archivos de copia de seguridad en la ubicación \server\searchbackup.

Puede ver el estado general de todos los trabajos de copias de seguridad en la parte superior de la página Estado del trabajo de copia de seguridad y restauración en la sección Disponibilidad. Puede ver el estado del trabajo de copia de seguridad actual en la parte inferior de la página en la sección Copia de seguridad. La página de estado se actualiza automáticamente cada 30 segundos. Para actualizar manualmente los detalles del estado, haga clic en Actualizar. La copia de seguridad y recuperación son trabajos de servicio del temporizador. Por lo tanto, la copia de seguridad puede tardar varios segundos en iniciarse. Si recibe mensajes de error, puede revisarlos en la columna Mensaje de error de la página Estado del trabajo de copia de seguridad y restauración. También puede encontrar más detalles en el archivo Spbackup.log en la ruta de acceso UNC que especificó para almacenar el archivo de copia de seguridad.

Restauración de la aplicación de servicio de búsqueda

Para restaurar una aplicación servicio Search de SharePoint Server, la copia de seguridad debe haberse completado correctamente y, si las copias de seguridad se realizan con frecuencia, se necesita el identificador de la copia de seguridad específica que se va a restaurar. Este identificador puede obtenerse fácilmente de varias maneras. La forma más simple es abrir la página Historial de copias de seguridad y restauración en la granja de producción donde se realizó la copia de seguridad y escribir la Ubicación del directorio de copia de seguridad. De esta forma, se proporciona una lista de todas las entradas en el archivo de manifiesto de copia de seguridad y restauración (psbrtoc.xml). En la captura de pantalla siguiente, se puede ver fácilmente un identificador de copia de seguridad de {149fc816-8927-4a32-9437-6e05c2869ab7}.

La opción alternativa a usar la página de historial de copias de seguridad y restauración es abrir directamente el manifiesto de copias de seguridad y restauraciones y buscar la entrada deseada. Debido a que el tamaño de este archivo aumentará con cada copia de seguridad y restauración, buscar el archivo quizás no sea el enfoque adecuado, especialmente si hay una gran frecuencia de operaciones de copia de seguridad y restauración.

En el ejemplo siguiente se muestran entradas típicas en spbrtoc.xml; allí puede observar que el identificador de copia de seguridad se puede identificar fácilmente.

<?xml version="1.0" encoding="utf-8"?>
<SPBackupRestoreHistory>
 <SPHistoryObject>
 <SPId>149fc816-8927-4a32-9437-6e05c2869ab7</SPId>
 <SPRequestedBy>REDMOND\pkmacct</SPRequestedBy>
 <SPBackupMethod>Full</SPBackupMethod>
 <SPRestoreMethod>None</SPRestoreMethod>
 <SPStartTime>01/11/2016 02:30:27</SPStartTime>
 <SPFinishTime>01/11/2016 02:38:48</SPFinishTime>
 <SPIsBackup>True</SPIsBackup>
 <SPConfigurationOnly>False</SPConfigurationOnly>
 <SPBackupDirectory>\\server\backups\spbr0000\</SPBackupDirectory>
 <SPDirectoryName>spbr0000</SPDirectoryName>
 <SPDirectoryNumber>0</SPDirectoryNumber>
 <SPTopComponent>Farm\Shared Services\Shared Services Applications\Search Service Application Prod</SPTopComponent>
 <SPTopComponentId>013aa694-673d-46d1-9313-fbba6df691e7</SPTopComponentId>
 <SPWarningCount>0</SPWarningCount>
 <SPErrorCount>0</SPErrorCount>
 </SPHistoryObject>
</SPBackupRestoreHistory>

Otro método disponible es usar el Get-SPBackupHistory cmdlet , que también puede proporcionar la misma información que el archivo spbrtoc.xml .

En los dos ejemplos siguientes se muestra cómo realizar la operación de restauración mediante el Restore-SPFarm cmdlet .

Restore-SPFarm -Directory <BackupFolder> -Item "<ServiceApplicationName>" -RestoreMethod Overwrite [-BackupId <GUID>]

Restore-SPFarm -Directory \\server\searchbackup - Item "Farm\Shared Services\Shared Services Applications\Contoso Search Service Application" -RestoreMethod New -BackupID "149fc816-8927-4a32-9437-6e05c2869ab7"

El RestoreMethod uso determina cómo fluirá el proceso después de ejecutar el Restore-SPFarm cmdlet.

Si se opta por la nueva opción, se le pide al administrador que ejecuta el cmdlet que proporcione una ubicación en la nueva granja para cada componente y base de datos en la copia de seguridad. Esto puede resultar especialmente útil si la topología de granja de servidores y la convención de nomenclatura de la granja de recuperación ante desastres no coincide exactamente con la producción, que es un escenario que se da con frecuencia. Si la aplicación de servicio de búsqueda se restaura a una granja que se creó con una topología de servidor y nombres que coinciden, se puede usar la opción de sobrescribir. Por lo general, esta opción solo se usa cuando se restaura a la misma granja que es el origen de la copia de seguridad.

Cuando se restaura una aplicación de servicio de búsqueda, esta se pausará automáticamente durante y después de la restauración. Para reanudar la aplicación de servicio una vez finalizada la restauración, use el siguiente comando de PowerShell.

$ssa = Get-SPEnterpriseSearchServiceApplication <SearchServiceApplicationName> $ssa.ForceResume($ssa.IsPaused())

Otro punto que debe tener en cuenta el administrador es el proceso que se usa para restaurar una aplicación de servicio de búsqueda que tiene varias réplicas por partición. El proceso de restauración solo se restaurará en una de las réplicas dentro de cada partición, y una tarea en segundo plano controlará la replicación de la información de la partición en todas las demás réplicas de cada partición. La indexación y las consultas de la búsqueda se realizan en línea y de manera funcional durante este proceso, pero las páginas de administración para la aplicación de servicio de búsqueda pueden mostrar las réplicas como degradadas hasta que la operación esté completa.

Enfoque combinado de recuperación ante desastres

Tal como se mencionó anteriormente, ya que la copia de seguridad y la restauración de la aplicación de servicio es el único enfoque que se admite para mantener una solución de recuperación ante desastres de total fidelidad, representa todo un desafío lograr un RPO/RTO bajo para la búsqueda. El tiempo de la copia de seguridad y el tiempo de restauración pueden extenderse con el transcurso del tiempo a medida que el conjunto indexado es cada vez más grande. Esto podría generar un RPO y RTO mucho más grande que lo que se desea.

Un enfoque que puede adoptarse para superar los desafíos de lograr un RPO/RTO bajo es emplear un enfoque dual para la solución. En la lista siguiente se muestra esta solución:

• Use el rastreo de las bases de datos de contenido de solo lectura o realice un doble rastreo del sitio de producción para mantener un nivel aceptable de actualización del índice de búsqueda en la granja de recuperación ante desastres.

• Realice copias de seguridad de la aplicación de servicio de búsqueda y restáurelas periódicamente en la granja de recuperación ante desastres o manténgalas a disposición en caso de que el sitio principal no se pueda recuperar.

Si la opción elegida es rastrear las bases de datos de solo lectura en la granja de recuperación ante desastres, debe contemplar el hecho de que los cambios en la granja de producción no se replicarán en la granja de recuperación. Tal como mencionamos, esto incluye las actualizaciones del análisis del servicio de búsqueda al índice y los cambios en los elementos de configuración como orígenes de resultados, reglas de consultas y modificaciones del esquema. Si adopta un enfoque combinado, es muy importante comprender todas las implicaciones y establecer una estrategia adecuada. Actualmente, no hay una forma compatible para soslayar la pérdida de las actualizaciones de análisis, pero se pueden seguir algunos pasos para aportar actualizaciones a los cambios de configuración. Podría probar con acciones similares a las expuestas en los siguientes ejemplos.

Asegúrese de que todos los cambios personalizados de orígenes de resultados, reglas de consultas y esquema de búsqueda considerados fundamentales para la empresa se realicen en el nivel de la aplicación de servicio de búsqueda en la Administración central y no dentro de colecciones de sitios o subsitios. Por ejemplo, piense en un portal de intranet corporativa que depende de reglas de consulta específicas para administrar el contenido en la página principal. Estas reglas deberían crearse en la granja de producción y replicarse manualmente en la granja de recuperación ante desastres a fin de ayudar a garantizar la disponibilidad de esta configuración. Asimismo, las asignaciones personalizadas de las propiedades rastreadas a las propiedades administradas deben implementarse en el nivel de aplicación de servicio en ambas granjas.

Es posible capturar las opciones de configuración de la búsqueda de nivel de sitio y nivel web y exportarlas a un archivo XML mediante PowerShell. Por ejemplo, el siguiente ejemplo de PowerShell exportará elementos de configuración desde el sitio "http://intranet.contoso.com" a un archivo XML denominado intranetcontosocom.xml. Este enfoque se publicó en la comunidad de SharePoint y se usa con el permiso correspondiente. Puede ver esta publicación del blog en Importar y exportar las opciones de configuración de búsqueda en SharePoint 2013.

Add-PSSnapin Microsoft.SharePoint.PowerShell-ea 0
[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint.Client") | Out-Null
[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint.Client.search") | Out-Null
$context = New-Object Microsoft.SharePoint.Client.ClientContext("http://intranet.contoso.com")
$searchConfigurationPortability = New-Object Microsoft.SharePoint.Client.Search.Portability.searchconfigurationportability($context)
$owner = New-Object Microsoft.SharePoint.Client.Search.Administration.searchobjectowner($context,"SPSite")
$value = $searchConfigurationPortability.ExportSearchConfiguration($owner)
$context.ExecuteQuery()
[xml]$schema = $value.Value
$schema.OuterXml | Out-File intranetcontosocom.xml -Encoding UTF8

En el siguiente ejemplo se muestra cómo importar la configuración que obtiene de otro entorno.

[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint.Client") | Out-Null
[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint.Client.search") | Out-Null
$context = New-Object Microsoft.SharePoint.Client.ClientContext("http://dr.contoso.com")
$searchConfigurationPortability = New-Object Microsoft.SharePoint.Client.Search.Portability.searchconfigurationportability($context)
$owner = New-Object Microsoft.SharePoint.Client.Search.Administration.searchobjectowner($context,"SPSite")
[xml]$schema = gc .\schema.xml
$searchConfigurationPortability.ImportSearchConfiguration($owner,$schema.OuterXml)
$context.ExecuteQuery()

Puede personalizar estos ejemplos para desarrollar un proceso de exportación o importación de configuración de búsqueda que admita los requisitos de una solución de recuperación ante desastres combinada.

Cuando se rastrean bases de datos con contenido de solo lectura en la granja de recuperación ante desastres, la tabla de mapa del sitio en la base de datos de configuración de SharePoint no se actualizará para registrar los sitios recientemente creados en la granja de producción. Esto significa que no se indexarán dichos sitios ni el contenido durante los rastreos completos o incrementales. Para superar esto, es importante ejecutar periódicamente el siguiente comando de PowerShell que actualizará el mapa del sitio en la granja de servidores de recuperación ante desastres para todas las bases de datos de contenido de la aplicación web especificada.

Get-SPContentDatabase -WebApplication https://intranet.contoso.com | % {$_.refreshsitesinconfigurationdatabase()}

Al rastrear las bases de datos de solo lectura y actualizar el mapa del sitio con frecuencia, se puede mantener un alto nivel de actualización del índice en la granja de recuperación ante desastres. La segunda fase del enfoque combinado es lo que debe hacer con las copias de seguridad de la aplicación servicio Search. Hay dos opciones reales, que se muestran en la lista siguiente pero tenga en cuenta que la opción seleccionada dependerá de las necesidades de la empresa.

• Si la empresa puede funcionar correctamente y cumplir con sus funciones principales sin contar con una búsqueda de fidelidad total (es decir, los elementos de configuración principales de la aplicación de servicio de administración de la búsqueda y la capacidad de mantener un índice de búsqueda altamente actualizado permiten que la empresa funcione en el sitio de recuperación ante desastres), es posible que nunca restaure la aplicación de servicio en recuperación ante desastres. Es posible que solo se requiera restaurar la aplicación de servicio de búsqueda si está claro que el sitio principal no estará disponible durante mucho tiempo. Esto significa que no es posible realizar una conmutación por error al sitio principal y, por ende, es necesario restaurar la aplicación de servicio de búsqueda totalmente para que funcionen todas las características de la empresa que dependen de la búsqueda en línea. Es posible seleccionar un período de tiempo específico para desencadenar la restauración.

• Si es que va a haber un requisito para mantener una búsqueda con la mayor fidelidad posible en el sitio de recuperación ante desastres en caso de conmutación por error, entonces podrían llevarse a cabo procesos periódicos de copias de seguridad y restauración. Los escenarios posibles son procedimientos de copia de seguridad y restauración diarios o semanales que se usan junto con el rastreo de bases de datos de solo lectura para mantener la actualización lo más cercana posible al 100 %. El problema es cuando el índice de búsqueda es tan grande que se demora muchas horas en completar la restauración, por lo que se generan algunos riesgos para los objetivos de RTO/RPO.

Este enfoque combinado es claramente más complejo que una copia de seguridad y restauración sencillas, pero las ventajas superan los desafíos si las necesidades empresariales cumplen los requisitos para implementar una solución de este tipo.

Recursos adicionales

Para información adicional, le recomendamos que use los siguientes recursos.

• Copias de seguridad de aplicaciones de servicio de búsqueda en SharePoint Server

• Restaurar aplicaciones de servicio de búsqueda en SharePoint Server

Además de las opciones que se proporcionan en estos artículos y en este artículo, hay otros métodos que puede usar para realizar copias de seguridad y restaurar la aplicación de servicio de búsqueda en SharePoint Server. Estos métodos son más específicos y comprenden restaurar de forma independiente los índices de búsquedas y las bases de datos de búsqueda a una nueva granja. Aún no hemos descrito estos pasos, pero si tiene pensado usar un enfoque generado por script, le recomendados que comience por revisar los siguientes recursos.

• Get-SPEnterpriseSearchServiceApplicationBackupStore

• Restore-SPEnterpriseSearchServiceApplication

• Restore-SPEnterpriseSearchServiceApplicationIndex

• Realice una copia de seguridad y restaure una aplicación de servicio de búsqueda en SharePoint 2013 mediante VSS.