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?
-
El software de backup no puede generar el snapshot de bases a respaldar
-
Los logs no se ven truncados luego de un backup completo
-
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?
-
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.
-
Relevar datos de diagnóstico para posterior análisis y troubleshooting.
En este caso nos vamos a enfocar en la opción 1.
Requerimientos
-
Utilizar Exchange 2010 y ejecutar el script sobre el servidor específico que reporta los problemas
-
Espacio disponible en disco para logs generados por el script
-
Tener configurada la política de ejecución de scripts para que permita scripts no firmados
-
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:
2. Abrir el EMS (Exchange Management Shell) de Exchange y correr el script. Seleccionar la opción 1 para testear la funcionalidad de backup
3. Especificar la ubicación donde guardar la salida de archivos:
4. Seleccionar la base específica sobre la cual testear la funcionalidad de respaldo:
5. Especificar una unidad que no este en uso (temporal): Ej: “W:”
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:
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
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:
Por último se recomienda realizar un respaldo full de las bases:
Algunos links de interés:
- http://blogs.technet.com/b/exchange/archive/2013/04/29/troubleshoot-your-exchange-2010-database-backup-functionality-with-vsstester-script.aspx
- http://gallery.technet.microsoft.com/scriptcenter/VSSTesterps1-script-4ed07243
- http://blogs.technet.com/b/exchange/archive/2012/06/04/everything-you-need-to-know-about-exchange-backups-part-1.aspx
JOSE SAN MARTIN says
Mas que comentario es una consulta.. ¿puedo realizar un respaldo full, sin tener todos los log?, algo así como un respaldo en Frío??
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».
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!