¿Por qué una copia de seguridad incremental es casi tan grande como una copia de seguridad completa?
Un respaldo incremental puede volverse casi tan grande como un respaldo completo cuando el origen realmente reescribe muchos bloques, el motor de respaldo pierde su línea base de cambios previa, el alcance protegido cambia o el número que está leyendo es crecimiento del repositorio en lugar de la carga incremental actual. Diagnostique esas posibilidades por separado antes de eliminar puntos de restauración, reiniciar el trabajo o iniciar un nuevo respaldo completo.
Primero identifique qué número parece demasiado grande
“El incremental es de tamaño completo” puede describir cuatro mediciones diferentes. No son intercambiables y cada una apunta a una causa distinta.
| Medición | Lo que significa | Lo que sugiere un valor grande |
|---|---|---|
| Bytes de origen escaneados | Datos leídos para detectar cambios | El motor puede necesitar inspeccionar archivos completos incluso si solo carga fragmentos cambiados |
| Bytes transferidos | Nuevos datos enviados al destino | Muchos bloques cambiaron, se perdió la línea base o la deduplicación no coincidió |
| Tamaño del archivo incremental | Datos de nuevo punto de restauración escritos por esta ejecución | El trabajo capturó un delta genuinamente grande o se comportó como una nueva línea base |
| Crecimiento total del repositorio | Almacenamiento neto agregado después de fusiones, retención, metadatos y operaciones sintéticas | El diseño de la cadena de respaldo o el programa de limpieza pueden ser la causa real |
Registre los cuatro números para una ejecución. Un trabajo que escanea 8 TB pero transfiere 12 GB se comporta muy diferente a uno que transfiere y escribe 7 TB.
Confirme si la carga de trabajo realmente cambió tanto
El software de respaldo a nivel de volumen protege bloques de almacenamiento cambiados, no el tamaño visible para el usuario de los documentos editados. Una pequeña edición puede alterar un bloque más grande, y los servicios activos modifican continuamente registros, índices, bases de datos, cachés y archivos del sistema operativo. Una discusión reciente de administradores explica por qué un byte cambiado puede hacer que el bloque de respaldo que lo contiene forme parte del siguiente incremento.
Verifique si la ejecución grande siguió a alguno de estos eventos:
- Mantenimiento de bases de datos, compactación, reindexación o crecimiento del registro de transacciones
- Actualizaciones de máquinas virtuales, actividad de intercambio, escaneos antivirus o desfragmentación de invitados
- Transcodificación de medios, reindexación de biblioteca de fotos, regeneración de miniaturas o reescritura de metadatos
- Archivos grandes de archivo, contenedores cifrados, buzones o imágenes de disco que se reescriben en el lugar
- Balance del sistema de archivos, expansión del grupo, reubicación de bloques o consolidación de instantáneas
Compare la ventana de respaldo con los registros de la aplicación y los gráficos de escritura en almacenamiento. Si las escrituras de origen aumentaron al mismo tiempo, el respaldo puede estar reportando un delta real en lugar de una falla de respaldo.
Verifique si el seguimiento de cambios perdió su línea base
Los sistemas de seguimiento por bloques comparan el estado actual con un ID de cambio previo conocido. Una reversión de instantánea, restablecimiento de seguimiento, mapa de cambios inválido, migración de host, sesión previa fallida o recreación del trabajo de copia de seguridad pueden romper esa relación. La siguiente ejecución puede entonces leer o proteger toda la fuente para establecer una línea base segura. Un recorrido práctico de recuperación de CBT señala que restablecer el seguimiento de cambios puede requerir un nuevo completo activo antes de que se reanuden los incrementales normales.
Busque términos en los registros como CBT restablecido, ID de cambio inválido, registro envuelto, línea base faltante, nueva cadena, o se requiere escaneo completo. No restablezca el seguimiento repetidamente sin conservar los registros; los restablecimientos repetidos pueden ocultar el desencadenante original y producir ejecuciones repetidas de tamaño completo.
Verifique que el alcance de la copia de seguridad y la identidad de la fuente no hayan cambiado
Un trabajo aún puede estar etiquetado como incremental mientras protege una fuente diferente a la anterior. Un nuevo montaje bajo una ruta incluida, un cambio de tamaño del sistema de archivos, un identificador de dispositivo cambiado, un nombre de host diferente, una nueva ruta de compartición o una regla de inclusión ampliada pueden hacer que el motor construya nuevas estructuras internas. La resolución de problemas comunitaria muestra que volúmenes adicionales y puntos de montaje pueden incorporarse a un trabajo que parece no haber cambiado.
Exporte las definiciones de trabajo anteriores y actuales y compárelas:
- Raíces protegidas, montajes, comparticiones, conjuntos de datos y discos virtuales
- Identificadores de host, volumen y sistema de archivos
- Patrones de inclusión y exclusión
- Proveedor de instantáneas y modo de consistencia
- Configuraciones de cifrado, compresión y deduplicación
Si la fuente se expandió intencionalmente, se puede esperar un incremento de tamaño completo. Si cada ejecución posterior sigue siendo grande, continúe con el diagnóstico.
Determinar si la granularidad de la copia de seguridad se ajusta a los archivos
Los motores de fragmentación a nivel de archivo, bloque y contenido definido reaccionan de manera diferente a las ediciones, cambios de nombre y reescrituras. Un sistema de deduplicación por bloques puede registrar solo los metadatos cuando se mueve una carpeta; un motor más simple a nivel de archivo puede tratar la ruta movida como un archivo eliminado más un archivo nuevo. En un ejemplo basado en bloques, renombrar un directorio cambia los metadatos de la ruta sin volver a subir todos los bloques de datos sin cambios.
Los archivos grandes y mutables necesitan atención especial. Una base de datos, imagen de VM, bóveda encriptada o archivo monolítico puede leerse completamente para descubrir pequeños cambios internos, y la cantidad almacenada depende en última instancia de los límites de fragmentos y la deduplicación. Una discusión sobre bases de datos grandes describe cómo un archivo de base de datos de varios gigabytes puede leerse completo incluso cuando solo se transfieren fragmentos cambiados.
Si la aplicación proporciona una exportación consistente, respaldo de registro de transacciones o método de respaldo consciente de la aplicación, compare ese flujo de trabajo con respaldar el archivo monolítico en vivo.
Separe un incremento grande de la actividad de completo sintético y retención.
Un completo sintético se ensambla dentro del repositorio a partir de un completo anterior más incrementales posteriores. Puede crear un objeto de recuperación de tamaño completo sin leer toda la fuente nuevamente. Una visión general de los tipos de respaldo explica que los respaldos completos sintéticos se construyen a partir de la cadena existente de completos e incrementales.
El crecimiento del repositorio también puede mantenerse alto cuando los puntos de restauración antiguos permanecen bloqueados, no se ha ejecutado la poda, las instantáneas eliminadas aún hacen referencia a fragmentos o una fusión necesita temporalmente espacio de trabajo. Verifique la línea de tiempo del trabajo en lugar de juzgar un listado de directorio:
| Patrón observado. | Interpretación probable. | Próxima verificación. |
|---|---|---|
| La transferencia de red es pequeña, la escritura en el repositorio es grande. | Completo sintético, fusión o reempaquetado. | Registro de tareas del repositorio. |
| El archivo incremental es pequeño, el uso total sigue aumentando. | Retención, inmutabilidad, instantáneas o poda retrasada. | Punto retenido más antiguo y programa de recuperación. |
| Los bytes transferidos y escritos se acercan al tamaño completo. | Cambio real, línea base perdida o alcance cambiado. | Actividad de la fuente y registros de seguimiento. |
| Solo la primera ejecución después de un cambio es grande. | Nueva línea base o transición de diseño de fuente. | Las siguientes dos ejecuciones incrementales. |
Ejecute una prueba de una variable antes de reconstruir la cadena de respaldo.
- Guarde la configuración actual del trabajo, los registros detallados, la lista de puntos de restauración y la capacidad del repositorio.
- Elija una ventana de prueba tranquila y pause las aplicaciones conocidas de alta escritura si es seguro hacerlo.
- Cree un archivo de prueba pequeño, modifíquelo una vez y ejecute el mismo trabajo incremental sin cambiar ninguna configuración.
- Registre los bytes escaneados, transferidos, escritos, deduplicados y retenidos.
- Ejecute un segundo incremental sin cambios en la fuente.
Si ambas ejecuciones controladas permanecen de tamaño completo, concéntrese en el seguimiento, la identidad de la fuente o la configuración de la cadena de trabajos. Si se vuelven pequeñas, restaure las cargas de trabajo normales una a la vez hasta que la tasa de cambio regrese. Esto separa el comportamiento del motor de respaldo del cambio de la aplicación.
Ajuste la solución a la causa
| Causa confirmada | Acción correctiva | Resultado esperado |
|---|---|---|
| Alta tasa real de escritura | Reduzca el alcance de archivos temporales, use exportaciones conscientes de la aplicación o programe después del mantenimiento | El tamaño del incremento sigue cambios significativos en los datos |
| Seguimiento de línea base perdido | Repare el seguimiento una vez, cree la línea base requerida y luego verifique los incrementos posteriores | Una ejecución grande seguida de deltas más pequeños |
| Alcance ampliado | Confirme que los nuevos datos son intencionados o sepárelos en un trabajo distinto | Crecimiento predecible ligado al origen añadido |
| Archivos grandes y mutables | Use volcados consistentes con la aplicación o un método de respaldo consciente de fragmentos | Menos reprocesamiento innecesario y restauraciones más seguras |
| Retención u operaciones sintéticas | Ajuste la planificación de capacidad, el tiempo de poda o la política de puntos de restauración | El crecimiento del repositorio coincide con el historial previsto |
Al dimensionar el destino, recuerde que el historial de versiones y la retención pueden hacer que un repositorio sea más grande que el origen activo. La misma distinción se cubre en la guía de ZimaSpace para planificar la capacidad del NAS para versiones e historial de respaldo.
Deténgase y escale cuando cada ejecución cree una nueva línea base
Escale antes de eliminar la cadena cuando los registros muestren repetida invalidación de la línea base, los identificadores de origen cambien inesperadamente, desaparezcan puntos de restauración, los metadatos del repositorio reporten corrupción o una prueba sin cambios aún escriba casi todo el origen. Mantenga los puntos de restauración actuales hasta que al menos una restauración representativa haya sido probada. Recrear el trabajo puede ocultar la evidencia y eliminar el único historial recuperable.
Preguntas Frecuentes
¿Puede mover o renombrar una carpeta grande causar un incremental del tamaño completo?
Depende del motor de respaldo. Las herramientas que deduplican contenido o bloques pueden reutilizar los datos existentes y almacenar principalmente metadatos de ruta, mientras que las herramientas a nivel de archivo pueden tratar los archivos movidos como objetos nuevos. Pruebe el producto exacto con una carpeta representativa antes de reorganizar un conjunto de datos grande.
¿Significa un completo sintético que el NAS subió todo el origen de nuevo?
No necesariamente. Un completo sintético se suele ensamblar a partir de datos ya existentes en el repositorio. Compare los contadores de lectura de origen y transferencia de red con los contadores de escritura en el repositorio para ver dónde ocurrió el trabajo.
¿Por qué una pequeña edición en la base de datos puede crear un incremento grande?
La aplicación puede reescribir muchos bloques de almacenamiento, compactar la base de datos, rotar registros o cambiar los límites de los fragmentos incluso cuando el cambio visible en el registro es pequeño. Use una copia de seguridad o exportación consistente con la aplicación y compare su delta con el archivo de base de datos en vivo.
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
