Resistencia de datos de SharePoint y OneDrive en Microsoft 365

Dentro de Microsoft 365, OneDrive se basa en la plataforma de archivos de SharePoint. En este artículo, solo se usa SharePoint para hacer referencia a ambos productos. Este artículo también se aplica a cualquier otro producto que almacene datos en SharePoint, como datos adjuntos en la nube, archivos compartidos en Teams, grabaciones y transcripciones de reuniones de Teams, componentes de bucle y pizarras.

Hay dos recursos principales que constituyen el almacenamiento de contenido principal de SharePoint:

• Almacenamiento de blobs: el contenido de usuario que se carga en SharePoint se almacena en Azure Storage. SharePoint ha creado un plan de resistencia personalizado sobre Azure Storage para garantizar la duplicación casi en tiempo real del contenido del usuario y un sistema realmente activo/activo.
• Metadatos: los metadatos de cada archivo se almacenan en Azure SQL Database. Azure SQL ofrece una historia de continuidad empresarial completa que SharePoint usa y los detalles se tratan más adelante en este artículo.

El conjunto completo de controles para garantizar la resistencia de los datos se explica en secciones adicionales.

Resistencia de Blob Storage

SharePoint tiene una solución personalizada para el almacenamiento de datos de clientes en Azure Storage. Cada archivo se escribe simultáneamente en una región de centro de datos principal y secundaria. Si se produce un error en las escrituras en cualquiera de las regiones de Azure, se produce un error al guardar el archivo. Una vez escrito el contenido en Azure Storage, las sumas de comprobación se almacenan por separado con metadatos y se usan para asegurarse de que la escritura confirmada es idéntica al archivo original durante todas las lecturas futuras. Esta misma técnica se usa en todos los flujos de trabajo para evitar la propagación de cualquier daño que se produzca. En cada región, el almacenamiento con redundancia local (LRS) de Azure proporciona un alto nivel de confiabilidad.

SharePoint usa Append-Only almacenamiento, lo que significa que Microsoft solo puede agregar nuevos blobs y nunca puede cambiar los antiguos hasta que se eliminen permanentemente. Este proceso garantiza que los archivos no se puedan cambiar o dañar después de un guardado inicial, lo que protege contra los atacantes que intentan dañar versiones anteriores. Dado que la protección de la integridad de la versión está integrada en la arquitectura de SharePoint, se pueden recuperar versiones anteriores del contenido del archivo, en función de la configuración de administrador individual.

Los entornos de SharePoint de cualquiera de los centros de datos pueden acceder a contenedores de almacenamiento en ambas regiones de Azure. Por motivos de rendimiento, siempre se prefiere el contenedor de almacenamiento en el mismo centro de datos local; sin embargo, las solicitudes de lectura que no ven los resultados dentro de un umbral deseado tienen el mismo contenido solicitado desde el centro de datos remoto para asegurarse de que los datos están siempre disponibles.

Resistencia de metadatos

Los metadatos de SharePoint también son fundamentales para acceder al contenido del usuario, ya que almacenan la ubicación y las claves de acceso al contenido almacenado en Azure Storage. Estas bases de datos se almacenan en Azure SQL, que tiene un amplio plan de continuidad empresarial.

SharePoint usa el modelo de replicación proporcionado por Azure SQL y ha creado una tecnología de automatización propietaria para determinar que se requiere una conmutación por error e iniciar la operación si es necesario. Por lo tanto, entra en la categoría "Conmutación por error manual de base de datos" desde una perspectiva de Azure SQL. Las métricas más recientes para la capacidad de recuperación de azure SQL Database están disponibles aquí.

SharePoint usa el sistema de copia de seguridad de Azure SQL para habilitar restauraciones a un momento dado (PITR) durante un máximo de 14 días.

Conmutación por error automatizada

SharePoint usa una conmutación por error automatizada personalizada para minimizar el impacto en la experiencia del cliente cuando se produce un evento específico de la ubicación. La automatización controlada por la supervisión que detecta un error de uno o varios componentes más allá de determinados umbrales da lugar a un redireccionamiento automatizado de la actividad de todos los usuarios fuera del entorno problemático y posterior a una secundaria activa. Una conmutación por error hace que los metadatos y el almacenamiento de proceso se sirvan completamente fuera del nuevo centro de datos. Como Blob Storage siempre se ejecuta completamente activo o activo, no se requiere ningún cambio para una conmutación por error. El nivel de proceso prefiere el contenedor de blobs más cercano, pero usa ubicaciones de almacenamiento de blobs locales y remotas en cualquier momento para garantizar la disponibilidad.

SharePoint usa el servicio Azure Front Door para proporcionar enrutamiento interno a la red de Microsoft. Esta configuración permite el redireccionamiento de conmutación por error independientemente de DNS y reduce el efecto del almacenamiento en caché de la máquina local. La mayoría de las operaciones de conmutación por error son transparentes para los usuarios finales. Si hay una conmutación por error, los clientes no necesitan realizar ningún cambio para mantener el acceso al servicio.

Control de versiones y restauración de archivos

Para las bibliotecas de documentos recién creadas, SharePoint tiene como valor predeterminado 500 versiones en cada archivo y se puede configurar para conservar más versiones si lo desea. La interfaz de usuario no permite establecer un valor inferior a 100 versiones, pero es posible establecer el sistema para almacenar menos versiones mediante API públicas. Por motivos de confiabilidad, no se recomienda cualquier valor inferior a 100 y puede dar lugar a que la actividad del usuario provoque una pérdida de datos involuntaria.

Para obtener más información sobre el control de versiones, vea Control de versiones en SharePoint.

Restauración de archivos es la capacidad de ir "atrás en el tiempo" en cualquier biblioteca de documentos de SharePoint a cualquier segundo de tiempo en los últimos 30 días. Este proceso se puede usar para recuperarse de ransomware, eliminaciones masivas, daños o cualquier otro evento. Esta característica usa versiones de archivo para reducir las versiones predeterminadas y reducir la eficacia de esta restauración.

La característica Restauración de archivos está documentada para OneDrive y SharePoint.

Eliminación, copia de seguridad y restauración a un momento dado

El contenido de usuario eliminado de SharePoint pasa por el siguiente flujo de eliminación.

Los elementos eliminados se conservan en las papeleras de reciclaje durante un período de tiempo determinado. Para SharePoint, el tiempo de retención es de 93 días. Comienza cuando se elimina el elemento de su ubicación original. Al eliminar el elemento de la papelera de reciclaje del sitio, entra en la papelera de reciclaje de la colección de sitios. Permanece allí durante el resto de los 93 días y, a continuación, se elimina permanentemente. Puede encontrar más información sobre cómo usar la papelera de reciclaje en estos vínculos:

• Restauración de elementos en la papelera de reciclaje
• Restaurar elementos eliminados de la papelera de reciclaje de la colección de sitios.

Este proceso es el flujo de eliminación predeterminado y no tiene en cuenta las directivas o etiquetas de retención. Para obtener más información, vea Más información sobre la retención para SharePoint y OneDrive.

Una vez completada la canalización de reciclaje de 93 días, la eliminación se realiza de forma independiente para metadatos y para Blob Storage. Los metadatos se quitan inmediatamente de la base de datos, lo que hace que el contenido sea ilegible a menos que los metadatos se restauren a partir de la copia de seguridad. SharePoint mantiene 14 días de copias de seguridad de metadatos. Estas copias de seguridad se realizan localmente casi en tiempo real y, a continuación, se insertan en el almacenamiento en contenedores redundantes de Azure Storage en, según la documentación en el momento de esta publicación, una programación de 5 a 10 minutos.

Además, los clientes también tienen la opción de usar Microsoft 365 Backup para la recuperación de datos. Microsoft 365 Backup ofrece un tiempo de protección más largo y proporciona una recuperación rápida y única de escenarios comunes de continuidad empresarial y recuperación ante desastres (BCDR), como ransomware o sobrescritura o eliminación de contenido de empleados accidentales o malintencionados. Las protecciones de escenarios BCDR adicionales también se integran directamente en el servicio, lo que ofrece un nivel mejorado de protección de datos.

Cuando se elimina el contenido de Blob Storage, SharePoint usa la característica de eliminación temporal de Azure Blob Storage para protegerse contra la eliminación accidental o malintencionada. Con esta característica, hay un total de 14 días en los que restaurar el contenido antes de que se elimine permanentemente. Además, dado que los blobs son inmutables, Microsoft siempre puede restaurar el estado de un archivo durante un período de 14 días.

Nota:

Aunque las aplicaciones de Microsoft enviarán contenido a la papelera de reciclaje para el proceso estándar, SharePoint proporciona API que permiten omitir la papelera de reciclaje y forzar una eliminación inmediata. Revise las aplicaciones para asegurarse de que esto solo se realiza cuando sea necesario por motivos de cumplimiento.

Comprobaciones de integridad

SharePoint usa varios métodos para garantizar la integridad de blobs y metadatos en todas las fases del ciclo de vida de los datos:

• Hash de archivo almacenado en metadatos: el hash de todo el archivo se almacena con metadatos de archivo para garantizar que la integridad de los datos de nivel de documento se mantiene durante todas las operaciones.
• Hash de blob almacenado en metadatos: cada blob-elemento almacena un hash del contenido cifrado para protegerse contra daños en el almacenamiento subyacente de Azure.
• Trabajo de integridad de datos: cada 14 días, cada sitio se examina en busca de integridad mediante la enumeración de elementos de la base de datos y la coincidencia con los blobs enumerados en Azure Storage. El trabajo informa de las referencias de blobs que faltan de storage-blobs y puede recuperar esos blobs a través de la característica de eliminación temporal de Azure Storage si es necesario.