Antes de realizar una copia de seguridad del clúster o set de réplicas, decide cómo respaldar los datos y qué datos respaldar. Esta página describe los elementos que se deben considerar antes de iniciar una copia de seguridad.
Tip
Para aprender cómo funciona la copia de seguridad, revisa copia de seguridad.
Opciones de configuración de copia de seguridad
Los requisitos de copia de seguridad y recuperación de un sistema dado varían para satisfacer los estándares de costos, rendimiento y protección de datos que establece el propietario del sistema.
Ops Manager Enterprise Copia de seguridad and Recovery admite cinco arquitecturas de copia de seguridad, cada una con sus propias fortalezas y compensaciones. Considera la arquitectura que satisfaga los requisitos de protección de datos para tu implementación antes de configurar e implementar tu arquitectura de copia de seguridad.
Ejemplo
Considere un sistema cuyos requisitos incluyan bajos costos operativos. Los propietarios del sistema pueden tener límites estrictos sobre lo que pueden gastar en almacenamiento para su configuración de copia de seguridad y recuperación. Como resultado, pueden aceptar un tiempo de recuperación más largo.
Por el contrario, consideremos un sistema que tiene entre sus requisitos un bajo Objetivo de tiempo de recuperación. Los propietarios del sistema toleran mayores costos de almacenamiento si esto resulta en una configuración de copia de seguridad y recuperación que cumpla con los requisitos de recuperación.
Ops Manager Enterprise Backup y recuperación soporta las siguientes arquitecturas de copia de seguridad:
Un sistema de archivos en un SAN con funcionalidades avanzadas para copias de seguridad de sistemas de archivos, como alta disponibilidad, compresión o deduplicación
Un sistema de archivos en uno o más dispositivos NAS
Almacenamiento en bloques de MongoDB en una configuración altamente disponible
MongoDB almacenamiento en bloques en una configuración autónomo
Proporcionamos recomendaciones sobre la arquitectura de copia de seguridad como orientación para desarrollar tus propios enfoques de protección de datos. Nuestras recomendaciones no cubren ni representan cada escenario o implementación.
Funcionalidades del método de copia de seguridad
Funcionalidad del sistema de copia de seguridad | Sistema de archivos en SAN | Sistema de archivos en NAS | AWS S3 almacenamiento en bloques | MongoDB HA Blockstore | Almacenamiento en bloques de MongoDB |
|---|---|---|---|---|---|
Tipos de snapshot | Completa * | Completa * | Muchos parciales | Muchos parciales | Muchos parciales |
Copia de seguridad Deduplicación de datos | Si la SAN permite. | No | Sí | Sí | Sí |
Compresión de datos de copia de seguridad | Sí | No | Sí | Sí | Sí |
Replicación de datos de copia de seguridad | Si la SAN permite. | No | No | Sí | No |
Costo de almacenamiento de copia de seguridad | Más alto | Intermedio | Inferior | Más alto | Inferior |
Tiempo del personal para gestionar las copias de seguridad | Intermedio | Intermedio | Inferior | Más alto | Intermedio |
RTO de copia de seguridad | Inferior | Intermedio | Inferior | Inferior | Intermedio |
* Para realizar una copia de seguridad incremental en un File System Store, el MongoDB Agent divide cada archivo de motor de almacenamiento ubicado en la ruta especificada para la copia de seguridad en bloque(s) de datos y transfiere únicamente el/los bloque(s) modificado(s) a Ops Manager. Ops Manager crea una nueva snapshot de los bloques recibidos y copia el/los bloque(s) restantes que no se hayan modificado de la copia de seguridad completa anterior. Cada instantánea incremental de copia de seguridad almacenada en un sistema de archivos ahorra E/S de red. Cada una de estas snapshot de copia de seguridad contiene una copia completa de todos los archivos necesarios de una implementación respaldada de MongoDB y no deduplica los registros.
Nota
¿Cuándo se utiliza un método de copia de seguridad en particular?
Para ejecutar copias de seguridad frecuentemente en grandes cantidades de datos y restauración desde copias de seguridad, considere hacer copias de seguridad en un sistema de archivos en un SAN, un almacenamiento de snapshot compatible con AWS S3, o un almacenamiento en bloques de MongoDB configurado como un set de réplicas o un clúster.
Para restaurar datos sin depender de la base de datos MongoDB, considera respaldar en un almacén de almacenamiento de snapshots compatible con AWS S3, uno o más NAS dispositivos o un sistema de archivos en un SAN con funciones avanzadas para copias de seguridad de sistemas de archivos, como alta disponibilidad, compresión o deduplicación.
Para minimizar el almacenamiento interno y los costos de mantenimiento, considere hacer copias de seguridad en un almacenamiento de snapshot compatible con AWS S3 o en un almacenamiento en bloques autónomo de MongoDB.
Un almacenamiento en bloques autónomo de MongoDB ofrece una resiliencia limitada. Si el disco se llena, este almacenamiento en bloques puede desconectarse. Puedes recuperar instantáneas de copia de seguridad únicamente después de agregar almacenamiento adicional.
Recomendación de tamaño de copia de seguridad
Al dimensionar la copia de seguridad de tus datos, mantén el tamaño del set de réplicas en 2 TB o menos de datos sin comprimir. Si su base de datos aumenta más allá de 2 TB de datos sin comprimir:
Fragmenta la base de datos
Mantén cada partición en 2 TB o menos de datos sin comprimir
Estas recomendaciones de tamaño son las mejores prácticas. No son una limitación de la base de datos MongoDB ni de Ops Manager.
La copia de seguridad y la restauración pueden utilizar grandes cantidades de CPU, memoria, almacenamiento y ancho de banda de red.
Ejemplo
Tu rendimiento de red declarado, como 10 Gbps o 100 Gbps, es un máximo teórico. Ese valor no tiene en cuenta el uso compartido ni la limitación del tráfico de red.
Considera el siguiente escenario:
Deseas hacer un respaldo de una base de datos de 2 TB.
Sus hosts admiten una conexión TCP de 10 Gbps desde Ops Manager a su almacenamiento de copia de seguridad.
La conexión de red tiene una pérdida de paquetes muy baja y un tiempo de retraso de ida y vuelta bajo.
Una copia de seguridad completa de tus datos puede tardar más de 30 horas en completarse. [1]
Esto no tiene en cuenta las velocidades de lectura y escritura del disco, que pueden ser, como máximo, 3 Gbps de lectura y 1 Gbps de escritura para una única unidad de almacenamiento NVMe o una unidad de almacenamiento NVMe reflejada.
El tiempo necesario para completar cada copia de seguridad incremental depende de la carga de escritura.
Si crea particiones en esta base de datos en 4 particiones, cada partición ejecutará su copia de seguridad por separado. Esto resulta en una copia de seguridad que tarda menos de 8 horas en completarse.
| [1] | Estas cifras de rendimiento se calcularon utilizando los métodos estándar de la industria para medir el rendimiento de red y suponen que no hay compresión de red adicional. |
frecuencia de snapshot y política de retención
Por defecto, Ops Manager toma una instantánea base de tus datos cada 24 horas.
Si se desea, los administradores pueden cambiar la frecuencia de las instantáneas base a 6, 8, 12 o 24 horas. Ops Manager crea instantáneas automáticamente según un cronograma; no se pueden tomar instantáneas on-demand.
Ops Manager retiene los snapshots durante los períodos de tiempo listados en la siguiente tabla.
Si terminas la copia de seguridad de una implementación, Ops Manager borra inmediatamente las snapshots que se encuentran dentro de las fechas de la política de retención actual.
Si se detiene la copia de seguridad de una implementación, Ops Manager deja de tomar nuevas snapshots, pero conserva las snapshots existentes hasta la fecha de caducidad listada.
snapshot | Política de retención por defecto | Política de retención máxima |
|---|---|---|
Instantánea base | 2 días | 5 días (30 días si la frecuencia es de 24 horas) |
Daily snapshot | 0 días | 1 año |
snapshot semanal | 2 semanas | 1 año |
Snapshot mensual | 1 mes | 7 años |
Nota
Las instantáneas mensuales son instantáneas completas por defecto, no instantáneas incrementales.
Puedes cambiar el cronograma de una implementación respaldada a través de su Edit Snapshot Schedule opción de menú, disponible en la página Backup. Los administradores pueden cambiar la frecuencia y retención de snapshots a través de recurso snapshotSchedule en la API.
Cambiar la hora de referencia cambia la hora de la próxima instantánea programada. No se puede hacer que la siguiente snapshot programada ocurra antes de la hora de la siguiente snapshot. La hora de la siguiente instantánea actual corresponde a la hora de referencia actual más el intervalo entre instantáneas.
Para determinar la hora del próximo snapshot, compare la hora actual del próximo snapshot con la nueva hora de referencia:
Si el nuevo tiempo de referencia es anterior al tiempo actual de la siguiente instantánea, la siguiente instantánea aún ocurre después del tiempo actual de la siguiente instantánea. La snapshot ocurre a la nueva hora de referencia más el número de intervalos necesarios para superar la siguiente hora de snapshot actual. Si este tiempo ya ha transcurrido cuando se realiza el cambio, el Ops Manager toma la siguiente snapshot en la próxima ocurrencia de la nueva referencia de tiempo. Consulta las dos primeras filas de la siguiente tabla como ejemplos.
Si la nueva hora de referencia es posterior a la próxima hora de snapshot actual, Ops Manager toma el próximo snapshot en la siguiente ocurrencia de la nueva hora de referencia. Consulta la tercera y la cuarta fila de la siguiente tabla para ver ejemplos.
Tiempo de cambio | Hora de referencia actual | Intervalo entre snapshot | Hora de la siguiente snapshot actual | Nuevo tiempo de referencia | Hora de la próxima snapshot |
|---|---|---|---|---|---|
08:00 UTC | 12:00 UTC | 6 horas | 12:00 UTC | 10:00 UTC | 16:00 UTC hoy |
23:00 UTC | 12:00 UTC | 6 horas | 00:00 UTC | 10:00 UTC | 04:00 UTC mañana |
08:00 UTC | 12:00 UTC | 6 horas | 12:00 UTC | 19:00 UTC | 19:00 UTC hoy |
20:00 UTC | 12:00 UTC | 6 horas | 00:00 UTC | 19:00 UTC | 01:00 UTC mañana |
Si se cambia el cronograma para guardar menos instantáneas, Ops Manager no borra las instantáneas existentes para cumplir con el nuevo cronograma. Para borrar los snapshots innecesarios, consulta Borrar un snapshot.
Límites
Ops Manager no realiza copias de seguridad de implementaciones en las que el número total de colecciones en la implementación alcanza o supera
100,000.Ops Manager no replica las opciones de colección de índices.
Encriptación
Ops Manager puede cifrar cualquier tarea de copia de seguridad almacenada en una base de datos principal que ejecute MongoDB Enterprise entre compatibilidad de características entre versiones 3.4 y 4.0 con el motor de almacenamiento WiredTiger.
compatibilidad de características entre versiones 4.2 y luego use cursores de copia de seguridad en lugar de bases de datos principales. Para obtener más información, consulte Servicio Daemon de copia de seguridad.
Consideraciones sobre copias de seguridad
Coherencia y snapshots
Para clústeres que ejecutan MongoDB versión 4.2 o posterior:
Ops Manager mantiene la coherencia causal al tomar snapshots, excepto por las estadísticas de tamaño reportadas por collStats y
db.[collection].count(). Las estadísticas de tamaño reportadas por collStats ydb.[collection].count()pueden ser inexactas.Ops Manager coordina la hora entre todas las particiones de los clústeres particionados. Esto garantiza que los snapshots incluyan todos los documentos recopilados en cada partición y nodo en el momento programado para el snapshot.
Para clústeres que ejecutan MongoDB versión 4.0 y anteriores:
Ops Manager mantiene snapshots coherentes ante fallos.
Ops Manager realiza snapshots de cada una de las particiones para clústeres y de los sets de réplicas del servidor de configuración aproximadamente al mismo tiempo.
Bases de datos que ejecutan compatibilidad de características entre versiones 4.2 y posteriores
Importante
Los clústeres fragmentados y los sets de réplicas son los únicos tipos de implementación de los que puedes hacer copias de seguridad si tus bases de datos ejecutan compatibilidad de características entre versiones 4.2 y anteriores de MongoDB. Para hacer una copia de seguridad de un proceso mongod autónomo que ejecute compatibilidad de características entre versiones 4.2 o anteriores de MongoDB, debes convertirlo en un set de réplicas de un solo nodo.
Funcionalidades de copia de seguridad admitidas actualmente
funcionalidad | Bases de datos corriendo compatibilidad de características entre versiones 4.2 y versiones posteriores | Bases de datos que ejecutan compatibilidad de características entre versiones 4.0 y versiones anteriores |
|---|---|---|
Realiza copias de seguridad de datos usando snapshots WiredTiger | ||
Realiza la copia de seguridad de los datos utilizando el daemon de copias de seguridad. | ||
Hace copias de seguridad de sets de réplicas | ||
Realiza copias de seguridad de Clústeres Particionados | ||
Puede filtrar usando los espacios de nombres [2] | ||
Puede especificar la base de datos de origen de la sincronización | ||
Puede restaurar datos a un punto específico en el tiempo [3] | ||
Puede realizar copias de seguridad incrementales [4]. | ||
Soporta snapshots que utilizan el cifrado KMIP [5] | ||
Admite snapshots que usan cifrado de clave local [6] | ||
Admite guardar en el almacenamiento de instantáneas del almacenamiento en bloques | ||
Admite guardar en Almacenamiento de instantáneas compatible con S3 | ||
Admite guardar en el almacenamiento del sistema de archivos [7] | ||
Admite bases de datos que ejecutan MongoDB Enterprise | ||
Admite bases de datos que ejecutan MongoDB Community | ||
Requiere un agente de MongoDB con copia de seguridad habilitada en cada |
| [2] | El filtrado de namespace solo se admite para las versiones 6.0.8 y posteriores de Ops Manager. Las implementaciones de MongoDB deben tener valores featureCompatibilityVersion de 4.0 y anteriores, o 6.0.1 y posteriores. |
| [3] | Para realizar una restauración PIT se requiere Ops Manager 4.2.13 o posterior. |
| [4] | Ops Manager requiere una copia de seguridad completa para tu primera copia de seguridad, después de que se haya borrado una snapshot y si se ha cambiado el tamaño de bloque del almacenamiento en bloques. Las copias de seguridad incrementales reducen la transferencia de red y los costos de almacenamiento. Esta funcionalidad funciona con:
|
| [5] | Consultar una snapshot cifrada requiere MongoDB Enterprise 4.2.9 o posterior o 4.4.0 o posterior. |
| [6] | compatibilidad de características entre versiones 4.2 y las copias de seguridad posteriores no son compatibles con el cifrado de clave local. |
| [7] | Las copias de seguridad en una base de datos compatibilidad de características entre versiones 4.2 o posterior, a un almacén de sistema de archivos, ignoran File System Store Gzip Compression Level. |
Requisitos y límites
Para ejecutar copias de seguridad y restauraciones si ejecutas MongoDB 4.2 o posterior con compatibilidad de características entre versiones 4.2 o posterior, debes:
Debe ejecutar MongoDB Enterprise.
Debes tener en cuenta el cambio en el tamaño del bloque de almacenamiento en bloques. Si no configuraste tu tamaño de bloque y utilizaste la configuración por defecto, ese tamaño de bloque cambia de 64 KB a 1 MB. Esto puede afectar el uso del almacenamiento.
Debe asegurarse de que los nombres de host en su configuración de set de réplicas coincidan con los nombres de host que utiliza el MongoDB Agent, o que sus mapeos de hosts contengan los nombres de host correctos. Puedes usar rs.conf() para verificar la configuración de tu set de réplicas.
Puede utilizar las listas de filtros de namespaces para definir los namespaces incluidos en una copia de seguridad solo si utiliza sistemas MongoDB 6.0 o más recientes. Las instantáneas tomadas en las versiones de MongoDB 4.2 a la 5.0 siempre incluyen todos los nombres de espacio.
No es necesario sincronizar una base de datos fuente. Al tomar una snapshot, el Ops Manager selecciona el miembro del set de réplicas con menor impacto sobre el rendimiento y la mayor duplicación de datos de snapshot a nivel de almacenamiento.
Se debe implementar un MongoDB Agent con cada nodo
mongoden el clúster.
Nota
Si Ops Manager no gestiona tu clúster:
Concede los
backupyclusterAdminroles al usuario de MongoDB que ejecuta las copias de seguridad.Asegúrese de que el usuario del sistema operativo que ejecuta el MongoDB Agent tenga permiso de lectura para todos los archivos de datos (incluidos los archivos de diario) de la implementación.
Sistema de archivos compartidos
Si configuras Ops Manager para que use varios servidores de aplicaciones Ops Manager detrás de un HTTP o HTTPS balanceador de carga y usas instantáneas del sistema de archivos, compatibilidad de características entre versiones 4.2 o posteriores, las tareas de instantáneas de copia de seguridad se ejecutan en paralelo en uno o más servidores. Asegúrese de tener un sistema de archivos compartido montado en cada servidor de Ops Manager. El servidor de aplicación de Ops Manager podría abrir y guardar diferentes compensaciones de los mismos archivos. Asegúrate de que el sistema de archivos compartido lo permita. De lo contrario, se encontrarán errores de acceso.
Bases de datos que ejecutan compatibilidad de características entre versiones 4.0 o anterior
Importante
Los clústeres fragmentados y los sets de réplicas son los únicos tipos de implementación de los que puedes hacer copias de seguridad si tus bases de datos ejecutan compatibilidad de características entre versiones 4.2 y anteriores de MongoDB. Para hacer una copia de seguridad de un proceso mongod autónomo que ejecute compatibilidad de características entre versiones 4.2 o anteriores de MongoDB, debes convertirlo en un set de réplicas de un solo nodo.
Las siguientes consideraciones se aplican cuando tus bases de datos ejecutan cualquier versión de MongoDB 4.0 o anterior, o cuando ejecutan MongoDB 4.2 con
"featureCompatibilityVersion" : 4.0
Colección de basura de snapshots expiradas
Ops Manager gestiona las instantáneas caducadas utilizando trabajos de limpieza. Estas tareas de limpieza actúan de manera diferente dependiendo de en qué almacenamiento de snapshot se encuentren los snapshots:
almacenamiento de snapshot | Cómo funcionan los trabajos de limpieza |
|---|---|
Almacenamiento en bloques de MongoDB | Utiliza espacio adicional en disco hasta la cantidad de bloques activos para cada tarea. |
Almacenamientos de snapshot | Elimina snapshots caducadas |
almacén de snapshots de S3 | Puede usar espacio adicional en disco si Ops Manager crea una snapshot mientras se ejecuta la tarea de limpieza. Ops Manager puede ejecutar tareas de limpieza concurrentes en los almacenes de snapshots de S3. |
Nota
Los trabajos de snapshot y los de limpieza no pueden ejecutarse simultáneamente. Si inicia una tarea de limpieza mientras se está ejecutando una tarea de snapshot, la tarea de limpieza fallará; Ops Manager registrará un registro de error y reintentará automáticamente la tarea de limpieza después de que la tarea de snapshot finalice. Si inicias una tarea de snapshot mientras se ejecuta una tarea de limpieza, la tarea de snapshot fallará, y Ops Manager registrará un error y la reintentará una vez finalizada la tarea de limpieza.
Para obtener más información sobre trabajos de cuidador de animales, consulta trabajos de cuidador de animales.
Filtro de namespace
El filtro de namespaces te permite especificar qué base de datos y colecciones respaldar. Puedes aplicar un filtro de namespace a cualquier base de datos, excepto admin y local, y cualquier colección que no comience con system.
Tip
Si aplica filtros de namespace a una snapshot, no puede query esa snapshot.
Puede crear un Deny List con las colecciones a excluir o un Allow List con las colecciones a incluir. Puede hacer sus selecciones al comenzar una copia de seguridad y luego editarlas según sea necesario.
Utiliza la lista de denegación para impedir la copia de seguridad de las colecciones que contienen datos de registro, cachés u otros datos temporales. Excluir esta clase de bases de datos y colecciones te permitirá reducir el tiempo y los costos de las copias de seguridad. Utilizar una lista de denegación suele ser preferible a utilizar una lista de permitidos, ya que una lista de permitidos requiere que optes intencionadamente por cada namespace que desees respaldar.
Nota
El filtrado de namespace sólo es compatible con versiones de Ops Manager 6.0.8 y posteriores. Tus implementaciones de MongoDB deben tener featureCompatibilityVersion valores de 4.0 y anteriores o 6.0.1 y posteriores.
Motor de almacenamiento
Para respaldar los clústeres de MongoDB, usa el motor de almacenamiento WiredTiger motor de almacenamiento.
Si tus bases de datos de respaldo actuales utilizan MMAPv1, actualiza a WiredTiger:
Con WiredTiger, Ops Manager limita las copias de seguridad a despliegues con menos de 100.000 archivos. Los archivos incluyen colecciones e índices.
MongoDB 4.2 elimina el almacenamiento MMAPv1. Para obtener más información sobre los motores de almacenamiento, consulte Almacenamiento en el manual de MongoDB.
Resincronización de implementaciones de producción
Para implementaciones de producción, resincroniza todos los sets de réplicas respaldados periódicamente, por ejemplo, una vez al año. Cuando vuelvas a sincronizar, los datos se leerán desde un secundario en cada set de réplicas. Durante la resincronización, no se generan nuevas instantáneas.
También puede querer resincronizar su copia de seguridad si:
Reducir el tamaño de los datos, de tal manera que el tamaño de la copia de los datos en disco de Ops Manager también se reduzca.
Crea un índice TTL, que elimina periódicamente documentos.
Descartar una colección (únicamente MMAPv1).
Ejecuta un clúster particionado y transfiere fragmentos de una partición específica.
Cambie los motores de almacenamiento, si desea que Ops Manager proporcione instantáneas en el nuevo formato del motor de almacenamiento.
Compilar un índice en un set de réplicas de manera progresiva.
Puntos de control
Importante
Puedes utilizar puntos de control para clústeres que ejecuten MongoDB con la compatibilidad de características entre versiones del 4.0 o anterior. Los puntos de control se eliminaron de las instancias de MongoDB con una compatibilidad de características entre versiones de 4.2 o superior.
Para clústeres fragmentados, los puntos de control brindan puntos de restauración adicionales entre instantáneas. Con los puntos de control activados, Ops Manager crea puntos de restauración a intervalos configurables de cada 15, 30 o 60 minutos entre snapshot. Para activar los puntos de control, consulte active los puntos de control.
Para crear un punto de control, Ops Manager detiene el balanceador e inserta un token en el oplog de cada partición y servidor de configuración en el clúster. Estos tokens de punto de control son livianos y no afectan el rendimiento ni el uso del disco.
La copia de seguridad no requiere puntos de control y están desactivados por defecto.
Restaurar desde un punto de control requiere que el Ops Manager aplique el oplog de cada partición y el servidor de configuración a la última snapshot capturada antes del punto de control. La restauración desde un punto de control lleva más tiempo que restaurar desde un snapshot.
Instantáneas cuando el agente no puede detener el equilibrador
Para clústeres particionados que ejecutan FCV 4.0 o anterior, Ops Manager desactiva el balanceador antes de tomar una snapshot del clúster. En ciertas situaciones, como una migración prolongada o la falta de mongos en ejecución, Ops Manager intenta desactivar el balanceador pero no puede. En tales casos, Ops Manager continúa tomando snapshots del clúster pero marca los snapshots que pueden tener datos incompletos o incoherentes. Las instantáneas de clúster tomadas durante una operación activa de balanceo corren el riesgo de pérdida de datos o de datos huérfanos.
Instantáneas cuando el agente no puede contactar a una mongod
Para clústeres particionados, si la copia de seguridad no puede alcanzar un proceso de mongod, ya sea una partición o el servidor de configuración, entonces el agente no puede insertar un oplog de sincronización. En estos casos, Ops Manager no crea la snapshot y muestra un mensaje de advertencia.
Consideraciones regionales sobre copias de seguridad
Para habilitar Copia de seguridad regional, debes asociar al menos uno de los siguientes elementos con la región de implementación que un set de réplicas o partición selecciona como objetivo:
Gestione el almacenamiento de snapshots de almacenamiento en bloques
Gestionar el almacenamiento de snapshot del sistema de archivos
Además, debe asociar uno de cada uno de los siguientes elementos con una región de implementación:
almacén de sincronización (a menos que ajustes
mms.backup.noSyncStateentrue)
Si añades una partición a un clúster después de habilitar la copia de seguridad regional para ese clúster, debes asignar una región de implementación a la nueva partición para continuar las tareas de copia de seguridad de las particiones existentes. Hasta que asignes una región de implementación al nuevo shard, toda la tarea de copia de seguridad del clúster tendrá un estado Misconfigured y no generará nuevos snapshots. Un clúster shardeado con un estado Misconfigured sigue generando entradas de Oplog.