Troubleshooting de respaldos de Exchange con VSSTester

Esta entrada es bien específica y se basa en el artículo del blog del equipo de producto de Exchange sobre troubleshooting de respaldos de Exchange con VSSTester.

La idea es complementar un poco la información suministrada en una entrada anterior sobre backup de bases en Exchange 2010.

A que escenarios aplica?

  1. El software de backup no puede generar el snapshot de bases a respaldar
  2. Los logs no se ven truncados luego de un backup completo
  3. Se sospecha de problemas a nivel de VSS (Volume Shadow Copy Service)

En adición a esto se puede utilizar VSSTester para truncar logs de forma segura y automática.

Qué hace VSSTester?

  1. Mediante diskshadow simula un respaldo completo para validar la funcionalidad a nivel de VSS (Volume Shadow Copy Service), Si bien trunca logs y actualiza el encabezado de la base de datos para indicar que hizo un respaldo exitoso no hay datos transferidos en el proceso, es decir que no se hace realmente un respaldo pero nos sirve para testear. El truncado de logs si es real por lo que hay que tenerlo en cuenta.
  2. Relevar datos de diagnóstico para posterior análisis y troubleshooting.

En este caso nos vamos a enfocar en la opción 1.

Requerimientos

  1. Utilizar Exchange 2010 y ejecutar el script sobre el servidor específico que reporta los problemas
  2. Espacio disponible en disco para logs generados por el script
  3. Tener configurada la política de ejecución de scripts para que permita scripts no firmados
  4. Si se usa para testear una base en DAG, las réplicas deben encontrase en estado saludable (healthy)

Cómo ejecutar VSSTester?

A continuación los pasos a seguir:

  • 1. Descargar el script desde: https://github.com/Microsoft/VSSTESTER:

vsstester.ps1

2. Abrir el EMS (Exchange Management Shell) de Exchange y correr el script. Seleccionar la opción 1 para testear la funcionalidad de backup

vsstester.ps1

vsstester.ps1

3. Especificar la ubicación donde guardar la salida de archivos:

vsstester.ps1

4. Seleccionar la base específica sobre la cual testear la funcionalidad de respaldo:

vsstester.ps1

5. Especificar una unidad que no este en uso (temporal): Ej: “W:”

image

6. Verificar que en la ruta especificada en el punto 3 se encuentren los logs generados y opcionalmente seleccionar la opción 1 para remover el snapshot:

vsstester.ps1

image

7. En caso de que empiece a tirar errores presionar ctrl + c para cancelar la ejecución

8. Confirmar que figure la base de datos como respaldada y que se hayan truncado los logs:

Get-MailboxDatabase base –Status | Select LastFullBackup

Get-MailboxDatabase -status

9. Revisar el event viewer por eventos con origen VSS, MSExchangeIS y ESE indicando la sucesión de eventos de respaldo. De estar todo bien veremos eventos de tipo información:

VSS

Por último se recomienda realizar un respaldo full de las bases:

Algunos links de interés:

About Daniel Núñez Banega

Consultor IT especializado en Microsoft Exchange, Active Directory y Office 365.
Principales Certificaciones: Microsoft Certified Trainer | Microsoft Certified Solutions Expert | Microsoft Certified Systems Engineer | Microsoft Certified Systems Administrator | Microsoft Certified IT Professional | Microsoft Certified Technology Specialist

Reader Interactions

Comments

    • Daniel Núñez Banega says

      Jose, no estoy seguro si me queda clara la consulta por lo que voy a tratar de responder del mejor modo posible, cualquier cosa amplia la información.
      Si la base de datos se encuentra montada es posible utilizar Windows Server Backup para respaldar Exchange incluso si faltan logs. Si a lo que estas haciendo referencia es a hacer un respaldo de la base desmontada lo que se necesita es que se encuentre en estado de “clean shutdown”. Esto lo podes saber utilizando eseutil como se indica en el artículo.

      La recomendación es respaldar en caliente porque aparte de que no implica desmontar la base (cortar el servicio) se corren chequeos de integridad que no son posibles cuando solo estamos copiando el EDB “en frío”.

  1. Notem1983 says

    Buenas!!

    Nos esta ocurriendo un problema. Se ejecuta un backup incremental para liberar logs, se han liberado los logs, pero en las propiedades de la bbdd pone que el ultimo backup incremental es de otra fecha completamente diferente. Como es posible? El backup en los logs de TSM (herramienta de Backup ) de OK pero si miramos en las propiedades de la BBDD no se ha realizado..

    Muchas gracias
    Un Saludo

    • Daniel Núñez Banega says

      Hola Notem1983, ya probaste usando el VSSTester? de esa manera vas a saber si el problema viene por el lado del servidor o del TSM.

      saludos!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *