c_embudo_online sobre 2025
mayo 22, 2025

Azure Backup Server (MABS) y System Center Data Protection Manager (DPM) comparte el mismo motor aunque el uso en centros de datos locales, entornos híbridos o tamaño de empresa decantará una u otra opción.

Este escenario ha sido revisado en varios clientes, al realizar copias de seguridad de servidores de bases de datos en SQL Server aparecen errores durante la copia online, las copias de seguridad locales con sus correspondiente políticas de retención no se ven afectadas.

Los trabajos de creación de punto de recuperación en línea para Base de datos de SQL Server <NombreServidor> han devuelto error X veces. (Identificador 3188). No se puede realizar esta operación ahora porque ya se ha alcanzado el número máximo posible de trabajos paralelos de copia de seguridad en ejecución. (Identificador 100104)

Si se lanza o reanuda un trabajo de copia online en Azure de manera manual este se ejecuta correctamente, pero superado cierto umbral de tareas en paralelo estás finalizan con error y no se realizan.

Lo que es de esperar, al alcanzar el número máximo de tareas concurrentes de copia de seguridad online es que las siguientes se pusieran en espera hasta finalizar las previas ¿la lógica diría esto? En la versión 14.0.30.0 esto no sucede:

listado_errores sobre DPM_error_3188

Probando con diferentes grupos de protección configurados, solo sucedía con uno de ellos, el que hacía respaldo de las bases de datos en modo «Auto» es decir de todas las bases de datos del servidor:

sql_select_auto sobre DPM_error_3188

Un detalle, el servidor contiene más de 200 bases de datos diferentes y en este modo se seleccionan todas para la copia de seguridad, dado que se pueden crear y borrar de manera externa se seguiría haciendo una copia de seguridad completa.

Se eliminan sospechosos habituales:

  • Falta de recursos
  • Problemas de red
  • Perdidas de conexión con la máquina virtual
  • Perdidas de conexión con los recursos externos de Azure
  • Otros procesos en el mismo servidor
  • Actualización del agente MABS
  • Actualización del DPM
  • Actualizaciones de Windows Server
  • Revisar en Portal de Azure de registros de los trabajos
    Revisar valores de C:\Program Files\Microsoft Azure Backup Server V4\DPM\DPM\bin\DsResourceLimits.xml
  • Revisar registros de errores C:\Program Files\Microsoft Azure Backup Server V4\DPM\DPM\Temp\DPMRAXX.errlog

Cuando se configuró inicialmente no hubo problema pero desde Marzo-Abril de 2025 empezaron los problemas… toca revisar las actualizaciones aplicadas en estas fechas… nada… mismos errores.

Solo quedaba ponerse en contacto con Microsoft a ver si ellos lograban averiguar o ver algo que se nos pasara por alto. Ejecutamos varios scripts SQL sobre la base de datos interna de DPM enviados por soporte técnico:

BEGIN TRAN
-- Marcar la réplica como inválida si se realizó alguna operación en esa réplica
UPDATE tbl_PRM_LogicalREplica
 SET Validity = 1 -- Invalid
 WHERE OwnerTaskIdLock IS NOT NULL AND
 Validity <> 5 AND -- ProtectionStopped
 Validity <> 6 -- Inactive
 
-- Libera todos los bloqueos retenidos
 
UPDATE tbl_PRM_LogicalREplica
 SET OwnerTaskIdLock = null,
 Status=8
 
 if (select COUNT(name) from tbl_AM_Agent where Name like 'DPM RA v2%') > 0
 begin
 exec sp_executesql N'UPDATE tbl_RM_ShadowCopy
              SET ArchivetaskId = NULL,
              RecoveryJobId = NULL'
 end
 
UPDATE tbl_ARM_Datasource
 SET Status = 0,
 OwnerLockId = NULL
 
DELETE tbl_RM_DatasourceServerlock
DELETE tbl_RM_ShadowCopyLocks
 
-- Establece todas las tareas y trabajos en ejecución como fallidos
 
UPDATE tbl_TE_TaskTrail
 SET ExecutionState = 3,
 LastStateName = 'Failure',
 StoppedDateTime = GetUtcDate()
 WHERE ExecutionState NOT IN (2,3)
 
UPDATE tbl_JM_JobTrail
 SET JobState= 'Failed',
 EndDateTime = GetUtcDate()
 WHERE jobstate= 'Execute' OR jobstate= 'Retire' OR jobstate = 'Cancel' or JobState = 'GenerateWorkplan' or JobState = 'warning' or JobState = 'Start'
 
-- Recursos no reservados retenidos
 
UPDATE tbl_MM_Global_Media
 SET ReservationLevel = 0,
 ReservationOwnerMMId = null
 
UPDATE tbl_MM_Global_Drive
 SET ReservationLevel = 0,
 ReservationOwnerMMId = null
 
UPDATE tbl_MM_Global_IEPortResource
 SET ReservationLevel = 0,
 ReservationOwnerMMId = null

COMMIT TRAN

Todos los trabajos fallidos desaparecen y se vuelve a un escenario normal con otros cambios en el registro de Windows, curioso también que no sea posible cambiar este tipo de parámetros desde la propia interfaz gráfica pero bueno.

Aquí es donde los valores por defecto para los trabajos en paralelo tienen una valor entre 8 y 20, la documentación oficial en este momento indica la posibilidad de incrementar el valor aunque «limitado en el hardware y la red» para realizar copias online de manera más rápida mediante MABS V4.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Backup\DbgSettings\OnlineBackup]
"MaxParallelJobs"=dword:00000010
"MaxOnlineBackupJobs"=dword:00000003
"MaxBackupOperations"=dword:0000000a

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Data Protection Manager\Agent\2.0]
"MaxAllowedParallelJobs"=dword:00000020

[HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft Data Protection Manager\Configuration\DPMTaskController\MaxRunningTasksThreshold]
"6e7c76f4-a832-4418-a772-8e58fd7466cb"=dword:0000000C

[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Azure Backup\DbgSettings\OnlineBackup]
"MaxParallelBackupJobs"=dword:00000014

Los valores en decimal deben ser coherentes entre configuraciones, todas ellas en el DPM, no el agente del servidor de SQL. Todas estas pruebas para finalmente encontrar como respuesta oficial por parte del soporte técnico:

«DPM admite un máximo de 20 trabajos de copia de seguridad en línea simultáneos. Este límite está diseñado para garantizar un rendimiento y una fiabilidad óptimos del sistema en todas las cargas de trabajo.»

Alternativas actuales:

  1. Crear tantos grupos de trabajo como sea necesario para no superar las 20 bases de datos, máximo de tareas en paralelo, más de 10 grupos de protección sin la posibilidad de añadir o eliminar automáticamente aquellas que puedan variar en el servidor (más de 200 en este caso)
  2. Volver a los scripts de generación de BAK, comprimir y hacer copias de seguridad de los ficheros generados
  3. Llorar en los feedback sobre una característica que debería ser considerada realmente como bug.
  4. Utilizar otro software de copia de seguridad: Veeam Backup & Replication, Commvault Backup & Recovery, Acronis Cyber Protect, Veritas Backup Exec, NAKIVO Backup & Replication, Iperius Backup

¿Cuál usarías en tu caso? Contacta con nosotros y lo revisamos.