Puntos clave
- NinjaOne Backup reconoce VSS, lo que significa que las aplicaciones y bases de datos compatibles con Volume Shadow Copy Service pueden incluirse en una copia de seguridad en un estado coherente con la aplicación como parte de una copia de seguridad de imagen estándar, sin ninguna configuración especial.
- Microsoft SQL Server reconoce VSS, así que una copia de seguridad de imagen normal genera una copia viable y restaurable de la base de datos sin pasos adicionales.
- No todas las aplicaciones reconocen VSS. Para esos casos, un archivo de copia de seguridad generado por script (como un archivo BAK de SQL) te da una copia limpia y nativa de la aplicación que puedes proteger junto con tu copia de seguridad de imagen.
- Las bases de datos SQL que funcionan en modo de recuperación simple pueden purgar automáticamente sus registros de transacciones en cada punto de comprobación.
- Las copias de seguridad de imagen se pueden montar para recuperar archivos concretos, como un único archivo de base de datos, sin restaurar la imagen completa.
Hacer una copia de seguridad de un servidor Windows es sencillo hasta que llegas a lo que realmente se está ejecutando en él. Una base de datos no se queda quieta como un archivo estático: está en plena transacción, en plena escritura y cambiando constantemente. Una copia de seguridad tomada en el instante equivocado puede dejarte con una copia que parece completa pero que no se restaura correctamente. NinjaOne Backup® resuelve esto mediante el reconocimiento de aplicaciones, apoyándose en el servicio Volume Shadow Copy Service (VSS) de Microsoft para buena parte del trabajo.
Así funciona la copia de seguridad con reconocimiento de aplicaciones
VSS es un servicio de Windows que se coordina con las aplicaciones para crear una copia en la sombra (una instantánea de un volumen en un momento concreto) sin detener la aplicación ni interrumpir a los usuarios. Las aplicaciones compatibles con VSS utilizan un componente llamado escritor VSS, que indica al proceso de instantánea cómo congelar los datos de la aplicación en un estado coherente antes de tomar la copia.
NinjaOne Backup se comunica directamente con estos escritores VSS como parte de una copia de seguridad de imagen estándar. Para cualquier aplicación que reconozca VSS, eso significa que la copia de seguridad captura la aplicación en un estado coherente con la aplicación de forma automática, sin una tarea de copia de seguridad aparte ni scripts especiales: solo una copia de seguridad de imagen normal que, además, protege lo que se ejecuta sobre el SO.
Dicho esto, el reconocimiento de VSS en la herramienta de copia de seguridad no sustituye a las recomendaciones del proveedor de la aplicación. Conviene revisar qué indica el proveedor para hacer copias de seguridad de su aplicación concreta, ya que algunas tienen requisitos adicionales más allá de lo que cubre VSS por sí solo.
SQL Server: el ejemplo de aplicación que reconoce VSS
Microsoft SQL Server reconoce VSS de forma predeterminada, con su propio escritor VSS integrado. Una copia de seguridad de imagen estándar de un servidor que ejecuta SQL Server genera una copia utilizable y restaurable de la base de datos sin configuración adicional.
Hay un par de cosas que conviene saber sobre cómo funciona esto en la práctica:
- Truncamiento del registro en modo de recuperación simple: SQL Server trunca automáticamente su propio registro de transacciones en cada punto de comprobación cuando la base de datos funciona en modo de recuperación simple.
- Truncamiento del registro en modo de recuperación completa: En modo de recuperación completa, el registro solo se trunca cuando se ejecuta una copia de seguridad del registro de transacciones. Una copia de seguridad completa de la base de datos no lo hará, y tampoco tu copia de seguridad de imagen, así que el registro seguirá creciendo hasta que algo lo respalde de verdad. Si tus bases de datos funcionan en modo de recuperación completa, necesitas un plan de mantenimiento de SQL que incluya copias de seguridad del registro, no solo completas; esto forma parte de la rutina de copias de seguridad nativas de SQL que se explica más abajo.
- Recuperación granular de archivos: Con las copias de seguridad de imagen de NinjaOne almacenadas en destinos híbridos o solo en el cloud, puedes montar la imagen y extraer un archivo concreto, como un archivo de base de datos específico, sin restaurar la imagen completa. Esto importa cuando solo necesitas recuperar un archivo y no quieres poner en marcha una restauración completa para conseguirlo.
Qué hacer con las aplicaciones que no reconocen VSS
No todas las bases de datos se llevan bien con VSS. Aquí tienes dos ejemplos habituales.
MySQL no reconoce VSS. Por eso, el enfoque estándar que utiliza NinjaOne consiste en ejecutar primero un script que genere una copia de seguridad de la base de datos y, después, incluir el archivo resultante en una tarea de copia de seguridad de imagen o de archivos y carpetas.
QuickBooks Desktop tampoco reconoce VSS. Una copia de seguridad de imagen estándar sigue generando una copia coherente con el fallo, pero no garantiza una copia coherente con la aplicación. Recomendamos aprovechar la propia herramienta de copia de seguridad interna de QuickBooks, programada para ejecutarse por su cuenta, y así obtener una copia nativa de la aplicación más fiable. Cuando lo haces, NinjaOne Backup simplemente protege el archivo que genera esa herramienta, además de la copia de seguridad de imagen que ya cubre la máquina.
El patrón es el mismo en ambos casos. Cuando una aplicación no es compatible con VSS, deja que la aplicación (o un script) genere primero un archivo de copia de seguridad limpio y nativo, y protege después ese archivo con tu tarea de copia de seguridad habitual.
El archivo BAK sigue teniendo sentido
Incluso con SQL Server, que reconoce VSS por completo, hay motivos para generar además un archivo de copia de seguridad dedicado. Un script previo puede ejecutar el comando de copia de seguridad nativo de SQL Server para producir un archivo BAK, que NinjaOne Backup protege después como cualquier otro archivo.
Esto te da una segunda opción de recuperación, más flexible, junto a la copia de seguridad de imagen. Estas son algunas razones por las que merece la pena configurarlo.
- Restauraciones más rápidas y precisas: Restaurar directamente desde un archivo BAK con las herramientas propias de SQL Server puede ser más rápido que restaurar una imagen entera solo para recuperar la base de datos.
- Objetivos de punto de recuperación más exigentes: Las tareas de copia de seguridad y los planes de mantenimiento específicos de SQL pueden ejecutarse con más frecuencia que tu programación de copias de seguridad de imagen. Si necesitas una ventana de recuperación más corta de la que permite una copia de seguridad de imagen diaria en el cloud, puedes ejecutar copias de seguridad de SQL más a menudo y proteger solo esos archivos con una tarea de copia de seguridad de archivos y carpetas.
- Una copia de seguridad independiente del SO: Un archivo BAK es portátil y las herramientas de SQL Server lo entienden de forma nativa, lo que resulta útil en escenarios como migrar una base de datos a otro servidor, no solo para la recuperación ante desastres.
Si eliges esta vía, conviene almacenar las copias de seguridad y los planes de mantenimiento específicos de SQL en un volumen que no esté incluido en tu tarea de copia de seguridad de imagen y, después, usar una tarea aparte de copia de seguridad de archivos y carpetas para proteger solo esos archivos. Así mantienes las dos estrategias de copia de seguridad bien separadas en lugar de solaparlas.
Por qué el reconocimiento de aplicaciones es clave para la recuperación
Una copia de seguridad que finaliza correctamente no es lo mismo que una copia de seguridad que se restaura correctamente, y esa distancia es precisamente la que cierra el reconocimiento de aplicaciones. La compatibilidad con VSS significa que tus copias de seguridad de imagen capturan SQL Server en un estado realmente utilizable cuando lo necesitas, sin trabajo extra por tu parte. Para las aplicaciones que VSS no cubre, el principio sigue siendo el mismo: deja que la aplicación genere una copia limpia de sus propios datos y haz una copia de seguridad de esa copia.
Hacerlo bien marca la diferencia entre un mal día intentando recuperar una base de datos que parecía estar protegida pero no lo estaba y una restauración rutinaria sin complicaciones.
