¿Puede su aplicación autoalojada reconstruir su búsqueda? Lista de verificación de preparación operativa

La búsqueda es una dependencia operativa, no solo una funcionalidad de la interfaz

La búsqueda puede parecer una funcionalidad estándar de una aplicación: un cuadro en el encabezado, un filtro en una página de registros o una forma de encontrar texto dentro de archivos cargados. Desde el punto de vista operativo, puede ser un sistema independiente con sus propios datos, configuración, trabajos de procesamiento y modos de fallo.

Esta distinción es importante durante una restauración, migración o incidente. Restaurar la base de datos principal puede restaurar usuarios, registros y referencias a documentos, pero dejar la búsqueda vacía, desactualizada o incompleta. Un servicio de búsqueda independiente puede requerir la restauración de una instantánea, una reconstrucción a partir de los registros fuente o ambas cosas. La búsqueda en archivos también puede depender de que el almacenamiento de adjuntos sea accesible y de herramientas de extracción de texto.

Considere que la búsqueda está recuperada solo cuando los usuarios pueden encontrar los registros y el contenido de documentos apropiados, mientras que los usuarios sin permiso no pueden descubrir información protegida mediante resultados, fragmentos, recuentos o resaltados. Que un servicio responda a consultas no es, por sí solo, evidencia de una experiencia de búsqueda recuperada.

• Defina la búsqueda como una dependencia en el plan de recuperación de la aplicación, junto con la base de datos, el almacenamiento de archivos, la identidad y la configuración de red.
• Establezca un objetivo de recuperación para una búsqueda utilizable, no simplemente para el inicio del proceso de búsqueda.
• Asigne un responsable de las decisiones de recuperación de búsqueda, de la ejecución de la reconstrucción y de las pruebas de aceptación.
• Documente si la búsqueda es necesaria para el trabajo habitual inmediatamente después de la recuperación o si puede restaurarse en una fase posterior.

Mapee toda la ruta de búsqueda antes de decidir qué respaldar

Comience con un mapa de flujo de datos en lugar de basarse en una suposición sobre la arquitectura de un producto. Para cada elemento que se pueda buscar, rastree cómo llega a convertirse en un resultado. El registro canónico puede residir en una base de datos relacional; un binario cargado puede residir en un volumen de archivos o almacenamiento de objetos; el texto extraído puede almacenarse por separado; y un índice puede mantenerse en la base de datos o en un clúster de búsqueda dedicado.

Identifique también la ruta de consulta. La aplicación puede consultar su propia base de datos, enviar una solicitud a un servicio de búsqueda independiente, aplicar reglas de permisos en la aplicación o depender de atributos de control de acceso indexados. Estos detalles determinan si una reconstrucción es viable y dónde un fallo de permisos podría exponer datos.

Un mapa útil distingue la fuente de verdad duradera de los artefactos derivados. Debe cubrir tanto los registros estructurados como los adjuntos, porque restaurar los metadatos de un archivo no equivale a restaurar el archivo ni el texto extraído previamente de él.

• Registros canónicos: ¿Qué tablas, colecciones o API de la base de datos contienen el título, cuerpo, estado, propietario y datos de acceso que constituyen la fuente de verdad?
• Adjuntos: ¿Dónde se almacenan los archivos originales y se incluyen en el procedimiento de copia de seguridad y restauración de la aplicación?
• Contenido extraído: ¿El texto se genera al cargarlo, se guarda en el almacenamiento principal, se guarda en el sistema de búsqueda o se genera únicamente durante la indexación?
• Índice: ¿Es un índice de texto completo de la base de datos, un índice de motor de búsqueda independiente o una combinación?
• Procesamiento: ¿Qué trabajadores, colas, webhooks, trabajos programados o comandos manuales crean y actualizan las entradas del índice?
• Servicio de consulta: ¿Qué componente ejecuta las búsquedas y qué configuración, credenciales y ruta de red requiere?
• Autorización: ¿Dónde se aplican las restricciones a nivel de registro, documento y campo?

Clasifique el índice: canónico, derivado o parcialmente derivado

La pregunta central de recuperación no es si una aplicación tiene un índice. Es si el índice puede recrearse a partir de datos fuente retenidos y accesibles, a un coste aceptable y dentro de un plazo aceptable.

Por lo general, un índice derivado puede reconstruirse cuando se conservan los registros canónicos, los archivos y las reglas de transformación necesarias. Una instantánea de búsqueda puede seguir siendo valiosa porque puede acortar la restauración, conservar la configuración operativa o evitar una reconstrucción grande. Pero no es la única copia de los datos empresariales.

Un índice canónico o parcialmente derivado requiere más análisis. Un índice canónico es una fuente de verdad para parte del contenido o los metadatos necesarios para la búsqueda; no significa que se trate de datos con permisos concedidos. Puede contener texto enriquecido, embeddings, datos históricos, permisos, anotaciones u otro material que no puede regenerarse a partir de los datos restaurados de la aplicación. Si esa información es necesaria para una búsqueda correcta, el índice y su configuración asociada pasan a ser críticos para las copias de seguridad. No suponga que una instantánea de un motor de búsqueda contiene todas las dependencias: los archivos externos, las bases de datos de la aplicación y la información externa de identidad o autorización pueden permanecer fuera de ella.

Para clústeres de búsqueda dedicados, la configuración importa tanto como los documentos. [Elastic documenta](https://www.elastic.co/docs/deploy-manage/tools/snapshot-and-restore) que las instantáneas pueden incluir datos, configuración y datos internos de funcionalidades, según el caso de uso. Por el contrario, la [API Reindex de Elastic](https://www.elastic.co/docs/api/doc/elasticsearch/v8/operation/operation-reindex) requiere documentos fuente retenidos con `_source` habilitado y no copia la configuración ni las plantillas del índice fuente al destino. Por tanto, un manual de reconstrucción debe identificar los mapeos previstos, las opciones de shards y réplicas, las plantillas y la configuración de ingestión antes de empezar.

• Derivado: todo el contenido buscable y los atributos de acceso pueden regenerarse a partir de registros principales y archivos retenidos.
• Canónico: parte del contenido o los metadatos buscables necesarios existen solo en el índice o en su instantánea; el índice actúa como fuente de verdad para esa información.
• Parcialmente derivado: los registros principales se pueden reconstruir, pero es posible que el enriquecimiento, el contenido extraído, las señales de clasificación o los datos de acceso no sean reproducibles.
• Desconocido: ningún responsable puede mostrar la fuente, la transformación y el procedimiento de reconstrucción. Trátelo como una carencia previa a la adopción o a producción.

Inspeccione los desencadenantes de indexación, las colas y el manejo de fallos

Una reconstrucción de índice suele fallar no porque el motor de búsqueda no esté disponible, sino porque el proceso que lo alimenta nunca se ejecuta o descarta el trabajo silenciosamente. Identifique cada evento que debería crear, actualizar o eliminar un elemento buscable: creación de registros, ediciones, cargas de adjuntos, cambios de permisos, movimientos entre proyectos o espacios, eliminación y acciones de retención.

A continuación, identifique cómo se entregan esos eventos. Una aplicación puede indexar de forma síncrona durante una solicitud de usuario, poner trabajo en una cola asíncrona, ejecutar un trabajo programado o requerir un comando de administrador. Cada modelo tiene implicaciones de recuperación distintas. El trabajo en cola necesita una política clara tras una restauración: reproducirlo, descartarlo y realizar una reconstrucción completa, o restaurar el estado de la cola si ese estado es necesario y fiable.

El comportamiento ante fallos merece una prueba directa. [OpenSearch documenta](https://docs.opensearch.org/latest/ingest-pipelines/pipeline-failures/) que un procesador de ingestión que falla detiene la canalización de forma predeterminada y el documento no se indexa, mientras que el manejo opcional de fallos puede cambiar ese comportamiento. Su documentación también describe el registro de fallos y las métricas de ingestión con recuentos de errores. Sea cual sea la tecnología elegida, los operadores necesitan una respuesta observable a lo siguiente: ¿cuántos elementos se enviaron, se completaron correctamente, fallaron, se reintentaron y siguen pendientes?

• Enumere todos los desencadenantes de indexación, incluidos los cambios de permisos y eliminaciones.
• Registre el trabajador o programador responsable de cada desencadenante y cómo se inicia después de la restauración.
• Determine si las colas son duraderas, tienen copia de seguridad y se pueden reproducir con seguridad tras una restauración.
• Localice los registros de errores, métricas o vistas de estado que identifican trabajo de indexación fallido y pendiente.
• Defina el comportamiento de reintento y la vía de escalado para elementos que fallen permanentemente.
• Pruebe si un elemento eliminado o con acceso restringido se elimina o actualiza con rapidez en la búsqueda.

Pruebe la búsqueda filtrada por permisos como un control de autorización de datos

La autorización de búsqueda debe evaluarse en el nivel de resultados. Un usuario puede iniciar sesión correctamente y tener un rol general apropiado, pero aun así recibir un título, fragmento, resaltado, recuento de resultados o texto de adjunto de un registro específico al que no tiene permitido acceder.

[OWASP ASVS](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x17-V8-Authorization.md) exige permisos explícitos para elementos de datos específicos y la aplicación de autorización en una capa de servicio de confianza, incluidas las reglas de acceso específico a datos y a nivel de campo. Aplique ese principio a toda la experiencia de búsqueda, no solo a abrir un resultado después de que se haya mostrado.

Esto es especialmente importante después de una reconstrucción. Si los datos de permisos están indexados, pueden estar desactualizados o faltar. Si el filtrado ocurre en la aplicación, verifique que se aplique en cada ruta de consulta. Compruebe la búsqueda global, la búsqueda avanzada, el autocompletado, las búsquedas guardadas, las exportaciones, las API, las notificaciones en segundo plano y cualquier funcionalidad de IA o recuperación que consuma resultados de búsqueda.

• Cree cuentas de prueba que representen a un usuario normal, un responsable, un administrador y un usuario externo o restringido, cuando sea pertinente.
• Siembre o identifique registros con reglas de acceso deliberadamente distintas, incluido un adjunto restringido.
• Busque términos únicos de títulos protegidos, texto del cuerpo y contenido de archivos.
• Verifique que los usuarios no autorizados no vean ningún resultado, fragmento, resaltado, recuento o sugerencia que revele contenido protegido.
• Cambie el acceso a un elemento conocido y, a continuación, mida y verifique cómo llega el cambio a la búsqueda.
• Repita las pruebas después de una restauración y después de una reconstrucción completa del índice.

Incluya los adjuntos y la extracción de texto en el diseño de recuperación

La búsqueda de archivos es un problema de recuperación distinto de la búsqueda de registros. Una aplicación puede indexar solo nombres de archivos y metadatos, o puede extraer texto del cuerpo de documentos compatibles. En este último caso, una reconstrucción correcta depende de que los binarios originales estén disponibles, sean legibles y se suministren de nuevo al proceso de extracción cuando sea necesario.

El [complemento ingest-attachment de OpenSearch](https://docs.opensearch.org/latest/install-and-configure/additional-plugins/ingest-attachment-plugin/) es un ejemplo de este patrón: usa Apache Tika para extraer contenido y metadatos de archivos, que después pueden almacenarse en un campo de adjunto. La [documentación de formatos de Apache Tika](https://tika.apache.org/3.2.2/formats.html) deja claro que la compatibilidad es específica de cada formato y distingue la extracción de metadatos de la extracción de contenido textual. Por tanto, su conjunto de pruebas debe representar los archivos de los que las personas realmente dependen, en lugar de solo un documento de texto conveniente.

La política de extracción afecta a la completitud. El procesador de adjuntos de OpenSearch tiene un límite de caracteres extraídos que se puede configurar; un límite diferente puede cambiar qué contenido se puede buscar. Registre esos límites y las implicaciones de recursos de cualquier cambio. Documente también el tratamiento de archivos cifrados, escaneos sin texto utilizable, cargas dañadas, formatos poco comunes y archivos rechazados por la política. Una reconstrucción no puede recuperar texto de archivos que no se retuvieron, que no se pueden extraer o que la política excluye deliberadamente. Los fallos anteriores de extracción o indexación deben investigarse y reprocesarse cuando se conserven los archivos fuente, la configuración y las herramientas necesarias.

• Restaure y verifique el acceso al almacén de adjuntos original antes de declarar recuperable la búsqueda de archivos.
• Mantenga un corpus de pruebas representativo: documentos de oficina habituales, PDF, texto sin formato, hojas de cálculo, presentaciones, archivos escaneados y formatos especializados importantes utilizados por el equipo.
• Registre los formatos compatibles y los deliberadamente no compatibles, además del comportamiento esperado para cada uno.
• Registre los límites de extracción, los ajustes de idioma cuando correspondan y cualquier restricción de tamaño o seguridad.
• Pruebe una frase conocida cerca del final de un documento representativo largo para detectar truncamiento.
• Mida los recuentos de extracción e indexación fallidas por separado de la indexación correcta de metadatos.

Ejecute una prueba de recuperación de búsqueda que mida la recuperación utilizable

Una declaración escrita de copia de seguridad no es evidencia de que la búsqueda se pueda recuperar. [NIST SP 800-184](https://csrc.nist.gov/pubs/sp/800/184/final) hace hincapié en la planificación de recuperación, el desarrollo de manuales operativos, las pruebas y la mejora. Incorpore la búsqueda a ese ciclo mediante un ejercicio repetible.

Use un entorno de prueba aislado y autorizado. Restaure los datos principales de la aplicación y los adjuntos desde un punto de recuperación seleccionado, restaure o recree el servicio de búsqueda y su configuración, y luego siga la ruta documentada de reconstrucción o restauración de instantánea. [OpenSearch señala](https://docs.opensearch.org/latest/tuning-your-cluster/availability-and-recovery/snapshots/snapshot-restore/) que las instantáneas de clúster tardan tiempo y no son vistas perfectamente simultáneas de un clúster activo, así que defina qué límite de consistencia es aceptable y cómo gestionará los cambios que se produzcan durante la actividad de copia de seguridad.

La prueba debe terminar con evidencia, no con un estado de proceso en verde. Compare los resultados esperados y reales para una muestra controlada de registros y adjuntos. Confirme tanto los resultados positivos para usuarios autorizados como la ausencia de resultados protegidos para usuarios no autorizados. Registre el tiempo transcurrido para restaurar los datos principales, preparar la infraestructura de búsqueda, completar la indexación, despejar cualquier acumulación pendiente y superar la validación. Ese total es la ventana práctica de recuperación de la búsqueda.

• Elija un punto de recuperación y documente su hora y el límite esperado de datos.
• Restaure los registros canónicos, los datos de usuarios y autorización requeridos por la aplicación, y el almacenamiento de adjuntos.
• Restaure el servicio de búsqueda desde una instantánea o reconstruyalo desde fuentes retenidas, de acuerdo con el diseño documentado.
• Vuelva a aplicar las plantillas de índice, mapeos, canalizaciones de ingestión, ajustes y configuración de acceso necesarios antes o durante la reconstrucción, según corresponda.
• Realice un seguimiento de los totales de elementos, la profundidad de la cola, los fallos de procesadores y el estado de finalización durante todo el ejercicio.
• Valide búsquedas de términos exactos para registros conocidos, frases esperadas en adjuntos y elementos modificados o eliminados.
• Ejecute pruebas de permisos en todas las rutas de consulta relevantes.
• Registre los tiempos transcurridos, excepciones, intervenciones manuales y carencias no resueltas; actualice el manual operativo antes de la siguiente prueba.

Incluya los servicios y la configuración de búsqueda en los registros de copia de seguridad, migración y cambios

Que un índice necesite una copia de seguridad es una decisión de diseño, no una regla universal. Un índice totalmente derivado con una reconstrucción probada puede recrearse en lugar de respaldarse como vía principal de recuperación. Un índice grande, un proceso de extracción lento o un índice parcialmente derivado pueden justificar instantáneas para reducir el tiempo de inactividad o conservar información que no se puede recrear.

Si se usan instantáneas, incluya los elementos que las hacen utilizables. [Elastic señala](https://www.elastic.co/docs/deploy-manage/tools/snapshot-and-restore) que las instantáneas pueden conservar configuración y datos internos de funcionalidades, mientras que la pérdida de índices de sistema o del estado del clúster puede implicar la pérdida de configuración y estado de funcionalidades. Verifique exactamente qué incluye el alcance de instantánea seleccionado en su implementación, en lugar de aplicar una suposición genérica. Para OpenSearch, tenga en cuenta que el momento de una instantánea no es una vista puntual perfectamente simultánea.

El mismo inventario sirve para las migraciones y la gestión de cambios. Un cambio en los mapeos, analizadores, canalizaciones de ingestión, límites de extracción, comportamiento de las colas, permisos o políticas de retención puede alterar la calidad de búsqueda y el comportamiento de recuperación. Capture la configuración deseada de una forma controlada y reproducible, y actualice el manual de recuperación siempre que cambie el diseño de búsqueda.

Airbip ofrece implementación gestionada para aplicaciones del catálogo como cargas de trabajo Docker en servidores en la nube de Airbip, además de gestión del ciclo de vida del servicio y copias de seguridad diarias, semanales y mensuales configurables. Estas capacidades pueden respaldar el lado de infraestructura de una implementación de aplicaciones. El equipo de la aplicación aún debe determinar qué almacena su aplicación elegida, cómo se construye su búsqueda y quién valida la recuperación de datos, adjuntos, permisos y comportamiento de búsqueda.

• Inventaríe las copias de seguridad de bases de datos, copias de seguridad de adjuntos, instantáneas de búsqueda, exportaciones de configuración y secretos o credenciales necesarios para el procedimiento de recuperación.
• Documente la retención, las expectativas de punto de recuperación y la responsabilidad de restauración para cada artefacto.
• Registre las suposiciones de compatibilidad de los componentes de aplicación, base de datos, extracción y búsqueda antes de modificarlos.
• Decida si la restauración de instantánea, la reconstrucción completa o una combinación por etapas es la vía preferida.
• Exija una revisión del impacto en búsqueda para cambios en el esquema, el manejo de archivos, la autorización y los flujos de trabajo de indexación.
• Conserve un registro fechado del último ejercicio de recuperación exitoso y de las carencias detectadas.