Los administradores de bases de datos se dividen en aquellos que realizan copias de seguridad y aquellos que realizarán copias de seguridad.
Este artículo describe la copia de seguridad más común de IB 1C utilizando herramientas de MS servidor SQL 2008 R2, explica por qué se debe hacer de esta manera y no de otra, y despeja varios mitos. El artículo tiene muchos enlaces a la documentación de MS SQL, este artículo es más una descripción general de los mecanismos de copia de seguridad que una guía completa. Pero para aquellos que se enfrentan a esta tarea por primera vez, se dan instrucciones sencillas y paso a paso que se aplican a situaciones sencillas. El artículo no está destinado a los gurús de la administración, los gurús ya saben todo esto, pero se supone que el lector es capaz de instalar él mismo MS SQL Server y obligar a este milagro de tecnología hostil a crear una base de datos en sus entrañas, que a su vez es Capaz de forzar a almacenar datos 1C.
Considero que el comando TSQL BACKUP DATABASE (y su hermano BACKUP LOG) es esencialmente la única herramienta de respaldo para bases de datos 1C que usan MS SQL Server como DBMS. ¿Por qué? Veamos qué métodos tenemos generalmente:
| Cómo | Bien | Gravemente | Total |
| Subir a dt | Formato muy compacto. | Tarda mucho en formarse, requiere acceso exclusivo, no guarda algunos datos insignificantes (como la configuración del usuario en versiones anteriores), tarda mucho en implementarse. | Este no es tanto un método de copia de seguridad, sino una forma de transferir datos de un entorno a otro. Ideal para canales estrechos. |
| Copia de archivos mdf y ldf | Una forma muy clara para los administradores novatos. | Requiere la liberación de los archivos de la base de datos del bloqueo, y esto es posible si la base de datos está deshabilitada (desconectar el comando Menú de contexto), desconectado (separado) o simplemente detenido el servidor. Obviamente, los usuarios no podrán trabajar en este momento. | Tiene sentido aplicar este método si y solo si ya se ha producido un fallo, de modo que al intentar restaurar, al menos poder volver a la opción desde la que se inició la restauración. |
| Copia de seguridad con sistema operativo o hipervisor | Una forma conveniente para los entornos de desarrollo y prueba. | No siempre amigable con la integridad de los datos. manera intensiva en recursos. | Puede tener una aplicación limitada para el desarrollo. No tiene ningún significado práctico en el entorno alimentario. |
| Copia de seguridad usando MS SQL | No requiere tiempo de inactividad. Le permite restaurar un estado consistente en un momento arbitrario, si lo cuida con anticipación. Perfectamente automatizado. Ahorra tiempo y otros recursos. | No muy compacto. No todo el mundo sabe cómo utilizar este método en la medida necesaria. | Para entornos de producción: la herramienta principal. |
Las principales dificultades al usar la copia de seguridad con las herramientas integradas de MS SQL surgen debido a un malentendido elemental de los principios de trabajo. Esto se explica en parte por una gran pereza, en parte por la falta de una explicación simple y comprensible a nivel de "recetas preparadas" (hmm, digamos que no lo he visto), y la situación se ve incluso agravada por la mitológica consejos de "sub-gurú" en los foros. No sé qué hacer con la pereza, pero intentaré explicar los conceptos básicos de la copia de seguridad.
Hace mucho tiempo, en una galaxia lejana, existía un producto de ingeniería y pensamiento contable como 1C: Enterprise 7.7. Aparentemente, debido al hecho de que las primeras versiones de 1C:Enterprise se desarrollaron para usar el popular formato de archivo dbf, su versión SQL no almacenó suficiente información en la base de datos para considerar completa la copia de seguridad de MS SQL, e incluso con cada cambio en la estructura, condiciones de funcionamiento del modelo de recuperación completa, por lo que había que acudir a diferentes trucos para que el sistema de copia de seguridad realizara su función principal. Pero, desde que salió la versión 8, los DBA finalmente pudieron relajarse. Las herramientas de copia de seguridad regulares le permiten crear un sistema completo y completo de copias de seguridad. Solo el registro de registro y algunas pequeñas cosas como configurar la posición de los formularios (en versiones anteriores) no están incluidos en la copia de seguridad, pero esta pérdida de estos datos no afecta la funcionalidad del sistema, aunque ciertamente es correcto y útil para hacer copias de seguridad del registro de registro.
¿Por qué necesitamos una copia de seguridad? Hm. A primera vista, esta es una pregunta extraña. Bueno, probablemente, en primer lugar, para poder implementar una copia del sistema y, en segundo lugar, para restaurar el sistema en caso de falla. Estoy de acuerdo con la primera, pero la segunda cita es el primer mito de respaldo.
La copia de seguridad es la última línea de defensa para la integridad del sistema. Si el administrador de la base de datos tiene que restaurar el sistema del producto a partir de copias de seguridad, significa que se han cometido muchos errores en la organización del trabajo con una alta probabilidad. No puede tratar la copia de seguridad como la forma principal de garantizar la integridad de los datos, no, es más como un sistema de extinción de incendios. Se requiere un sistema de extinción de incendios. Debe estar configurado, probado y operativo. Pero si funcionó, entonces esto en sí mismo es una emergencia grave con muchas consecuencias negativas.
Para que la copia de seguridad se utilice solo con fines "pacíficos", utilice otros medios para garantizar el rendimiento:
Según los requisitos de disponibilidad del sistema y el presupuesto asignado para estos fines, es muy posible elegir soluciones que reduzcan el tiempo de inactividad y la recuperación ante desastres en 1 o 2 órdenes de magnitud. No hay que tener miedo a las tecnologías de accesibilidad: son lo suficientemente sencillas como para aprenderlas en pocos días con conocimientos básicos de MS SQL.
Pero, a pesar de todo, el respaldo sigue siendo necesario. Este es el mismo paracaídas de reserva que puede usar cuando fallan todos los demás medios de escape. Pero, como un verdadero paracaídas de reserva, para esto:
Los datos en MS SQL generalmente se almacenan en archivos de datos (en adelante, FD no es una abreviatura de uso común, habrá algunas abreviaturas más no muy comunes en este artículo) con extensiones mdf o ndf. Además de estos archivos, también existen registros de transacciones (LT), que se almacenan en archivos con la extensión ldf. No es raro que los administradores novatos sean irresponsables y frívolos con respecto a VT, tanto en términos de rendimiento como de confiabilidad del almacenamiento. Este es un error muy grave. De hecho, por el contrario, si hay un sistema de respaldo que funcione de manera confiable y se puede asignar mucho tiempo para la recuperación del sistema, entonces puede almacenar datos en un RAID-0 rápido, pero extremadamente poco confiable, pero luego se debe almacenar el VT. en un recurso separado confiable y productivo (aunque sería en RAID-1). ¿Porqué es eso? Miremos más de cerca. Inmediatamente haga una reserva de que la presentación es algo simplificada, pero suficiente para una comprensión inicial.
El FD almacena datos en páginas de 8 kilobytes (que se combinan en extensiones de 64 kilobytes, pero esto no es esencial). msql no garantiza que inmediatamente después de ejecutar el comando para cambiar los datos, estos cambios caerán en el FD. No, es solo que la página en la memoria está marcada como "que requiere guardar". Si el servidor tiene suficientes recursos, pronto estos datos estarán en el disco. Además, el servidor funciona de manera "optimista" y si estos cambios ocurren en una transacción, es posible que lleguen al disco antes de que se confirme la transacción. Es decir, en el caso general, trabajo activo El FD contiene fragmentos dispersos de datos sin terminar y transacciones incompletas para las que no se sabe si se cancelarán o confirmarán. Hay un comando especial " CHECKPOINT " que le dice al servidor que "en este momento" vacíe todos los datos no guardados en el disco, pero el alcance de este comando es bastante específico. Baste decir que 1C no lo usa (no lo he encontrado) y entiendo que durante la operación, el FD generalmente no está en un estado constante.
Para lidiar con este caos, solo necesitamos VT. Los siguientes eventos están escritos en él:
Toda esta información se escribe indicando el identificador de la transacción en la que se produjo y en volumen suficiente para entender cómo pasar del estado anterior a esta operación al estado posterior a esta operación y viceversa (la excepción es el modelo de recuperación masiva) .
Es importante que esta información se escriba en el disco inmediatamente. Hasta que no se registre la información en el VT, el comando no se considera ejecutado. En una situación normal, cuando el tamaño del VT es suficiente y cuando no está muy fragmentado, los registros se escriben secuencialmente en registros pequeños (no necesariamente múltiplos de 8 kb). Solo los datos realmente necesarios para la recuperación entran en el registro de transacciones. En particular No Se recibe información sobre qué texto de solicitud dio lugar a modificaciones, qué plan de ejecución tenía esta solicitud, qué usuario la lanzó y otra información que no es necesaria para la recuperación. La consulta puede dar alguna idea sobre la estructura de datos del registro de transacciones.
Seleccionar * from::fn_dblog(null,null)
Debido al hecho de que los discos duros funcionan mucho más eficientemente con escrituras secuenciales que con un flujo caótico de comandos de lectura y escritura, y debido al hecho de que los comandos SQL esperarán hasta el final de la escritura en el VT, surge la siguiente recomendación:
Si existe la más mínima posibilidad, entonces en el entorno de producción, los VT deben ubicarse en medios físicos separados (de todo lo demás), preferiblemente con un tiempo de acceso mínimo para escrituras secuenciales y con la máxima confiabilidad. Para sistemas simples RAID-1 está bien.
Si se cancela la transacción, el servidor devolverá todos los cambios ya realizados al estado anterior. Es por eso que
La cancelación de una transacción en MS SQL Server suele tener una duración comparable a la duración total de las operaciones de modificación de datos de la propia transacción. Trate de no cancelar transacciones o decida cancelar lo antes posible.
Si el servidor deja de funcionar inesperadamente por algún motivo, cuando se reinicie, analizará qué datos en el FD no corresponden a un estado consistente (transacciones no registradas pero confirmadas y transacciones registradas pero canceladas) y estos datos serán corregidos. Por lo tanto, si, por ejemplo, comenzó a reconstruir los índices de una tabla grande y reinició el servidor, cuando lo reinicie, tomará un tiempo considerable revertir esta transacción y no hay forma de interrumpir este proceso.
¿Qué sucede cuando el JT ha llegado al final del archivo? Es simple: si hay espacio libre al principio, comenzará a escribir en el espacio libre al principio del archivo hasta que lugar ocupado. Como una cinta magnética en bucle. Si no hay espacio al principio, el servidor generalmente intentará expandir el archivo de registro de transacciones, mientras que para el servidor la nueva pieza asignada es un nuevo archivo de registro de transacciones virtual, que puede ser mucho en el archivo de transacciones físicas, pero esto no es suficiente para la copia de seguridad. Si el servidor no puede expandir el archivo (se queda sin espacio en disco o está prohibido expandir el VT en la configuración), la transacción actual se cancelará con el error 9002.
Ups. ¿Y qué se debe hacer para que siempre haya un lugar en el ZhT? Aquí es donde llegamos al sistema de copia de seguridad y los modelos de recuperación. Para cancelar transacciones y restaurar el estado correcto del servidor en caso de un cierre repentino, es necesario almacenar registros en el LT, comenzando desde el inicio de la primera transacción abierta. Este mínimo se escribe y almacena en el JT Necesariamente. Independientemente del clima, la configuración del servidor y el deseo del administrador. El servidor no puede permitir que falte esta información. Por lo tanto, si abre una transacción en una sesión y realiza diferentes acciones en otras, el registro de transacciones puede finalizar de forma inesperada. La transacción más antigua se puede identificar con el comando DBCC OPENTRAN. Pero esto es sólo el mínimo necesario de información. Lo que suceda a continuación depende de modelos de recuperación. Hay tres en SQL Server:
Hay varios mitos asociados con los modelos de recuperación.
El modelo de registro masivo para bases de datos 1C es casi inútil de usar, por lo que no lo consideraremos más. Pero la elección entre Full y Simple se considerará con más detalle en la siguiente parte.
Existen tres tipos de respaldos según el tipo de formación:
No se confunda aquí: un modelo de recuperación completa y una copia de seguridad completa son cosas esencialmente diferentes. Para no confundirlos, a continuación utilizaré términos en inglés para el modelo de recuperación y términos en ruso para los tipos de copias de seguridad.
La copia completa y diferencial funcionan igual para Simple y Full. La copia de seguridad del registro de transacciones falta por completo en Simple.
Le permite restaurar el estado de la base de datos a un cierto punto en el tiempo (al momento en que se inició la copia de seguridad). Consiste en una copia paginada de la parte utilizada de los archivos de datos y la parte activa del registro de transacciones durante el tiempo en que se formó la copia de seguridad.
Almacena páginas de datos que han cambiado desde la última copia de seguridad completa. Al restaurar, primero debe restaurar una copia de seguridad completa (en modo NORECOVERY, se darán ejemplos a continuación), luego puede aplicar cualquiera de las copias diferenciales posteriores al "vacío" resultante, pero, por supuesto, solo las realizadas antes de la siguiente copia de seguridad completa. Esto puede reducir significativamente el volumen Espacio del disco para almacenar la copia de seguridad.
Puntos importantes:
Contiene una copia del VT de un período determinado. Por lo general, desde el momento del último RKZHT hasta la formación del RKZHT actual. RCRT le permite restaurar el estado en cualquier momento posterior, incluido en el intervalo de la copia de seguridad restaurada, desde una copia restaurada en modo NORECOVERY hasta cualquier momento incluido en el período de la copia restaurada del RT. Al crear una copia de seguridad con parámetros estándar, se libera espacio en el archivo de registro de transacciones (hasta el momento de la última transacción abierta).
Es obvio que RKZhT no tiene sentido en el modelo Simple (entonces VT contiene solo información del momento de la última transacción no cerrada).
Al usar RKZHT, surge un concepto importante: cadena continua de RKZhT. Esta cadena puede verse interrumpida por la pérdida de algunas de las copias de seguridad de esta cadena o por cambiar la base de datos a Simple y viceversa.
Advertencia: un conjunto de RCST es esencialmente inútil a menos que sea una cadena contigua, y la hora de inicio de la última copia de seguridad diferencial o completa correcta debe ser adentro período de esta cadena.
Conceptos erróneos y mitos comunes:
Sea una base de datos de 1000 GB. Todos los días, la base de datos crece 2 GB, mientras que cambia 10 GB de datos antiguos. Hice las siguientes copias de seguridad
Con este conjunto, podemos restaurar los datos a las 0:00 en cualquiera de los días del 1 de febrero al 14 de febrero. Para hacer esto, necesitamos tomar una copia completa de F1 para la semana del 1 al 7 de febrero o una copia completa de F2 para el 8 al 14 de febrero, restaurarla en modo NORECOVERY y luego aplicar una copia diferencial del día deseado.
Digamos que tenemos el mismo conjunto de copias de seguridad completas y diferenciales que en el ejemplo anterior. Además de esto, existen los siguientes RKZHT:
Nota:
En el caso más simple, necesitamos restaurar:
Primero, se restaurará F2, luego D2.2, luego RKZHT 6 hasta las 13:13:13 del 10 de febrero. Pero una ventaja significativa del modelo completo es que tenemos la opción de usar la última copia completa o diferencial, o NO la última. Por ejemplo, si se descubrió que la copia de D2.2 estaba dañada y necesitamos restaurar a un momento anterior a las 13:13:13 del 10 de febrero, entonces para el modelo Simple esto significaría que solo podemos restaurar los datos a el momento D2.1. Con Full - "DON" T PANIC", tenemos las siguientes opciones:
Como puede ver, el modelo completo nos da más opciones.
Ahora imagina que somos muy astutos. Y un par de días antes del fallo (13:13:13 del 10 de febrero) sabemos que habrá un fallo. Estamos restaurando la base de datos a partir de una copia de seguridad completa en el servidor vecino, dejando la posibilidad de implementar estados posteriores con copias diferenciales o RKZHT, es decir, en modo NORECOVERY. Y cada vez que inmediatamente después de la formación del RKZhT, lo aplicamos a esta base de reserva, dejándolo en el modo NORECOVERY. ¡Guau! ¡Por qué, ahora nos llevará solo 10-15 minutos restaurar la base de datos, en lugar de restaurar una base de datos enorme! Felicitaciones, hemos reinventado el mecanismo de envío de registros, una de las formas de reducir el tiempo de inactividad. Si transfiere datos de esta manera no una vez en un período, sino constantemente, se producirá la duplicación, y si la base de origen espera hasta que se actualice la base de duplicación, entonces se trata de una duplicación sincrónica, si no espera, entonces asincrónica.
Puede leer más sobre las herramientas de alta disponibilidad en la ayuda:
Puede omitir esta sección con seguridad si está aburrido de la teoría y tiene ganas de probar la configuración de la copia de seguridad.
1C:Enterprise, de hecho, no sabe cómo trabajar con grupos de archivos. Hay un solo grupo de archivos y eso es todo. De hecho, un programador o administrador de base de datos MS SQL puede poner algunas tablas, índices o incluso partes de tablas e índices en grupos de archivos separados (en la versión más simple, en archivos individuales). Esto es necesario ya sea para agilizar el acceso a algunos datos (colocándolos en soportes muy rápidos), o viceversa, sacrificando la velocidad para colocarlos en soportes más económicos (por ejemplo, datos poco utilizados pero voluminosos). Cuando trabaje con grupos de archivos, es posible hacer copias de seguridad de ellos por separado, y también puede restaurarlos por separado, pero debe tener en cuenta que todos los grupos de archivos deberán "atraparse" en un momento al rodar el RKZHT.
Si una persona controla la ubicación de los datos en diferentes grupos de archivos, entonces, cuando hay varios archivos dentro del grupo de archivos, MS SQL Server inserta datos en ellos de forma independiente (con un volumen igual de archivos, lo intentará de manera uniforme). Desde el punto de vista de la aplicación, se utiliza para paralelizar operaciones de E/S. Y en cuanto a las copias de seguridad, hay otro punto. Para bases de datos muy grandes en la era "anterior a SQL 2008", era un problema típico asignar una ventana continua para una copia de seguridad completa, y el disco de destino para esta copia de seguridad simplemente no encajaba. por la mayoría de una manera sencilla en este caso se trataba de hacer una copia de seguridad de cada archivo (o grupo de archivos) en su propia ventana. Ahora, con la difusión activa de la compresión de copias de seguridad, este problema se ha reducido, pero aún se puede tener en cuenta esta técnica.
MS SQL Server 2008 tiene una característica super-mega-ultra. A partir de ahora, las copias de seguridad se pueden comprimir sobre la marcha. Esto reduce el tamaño de la copia de seguridad de la base de datos 1C entre 5 y 10 veces. Y teniendo en cuenta que normalmente el rendimiento subsistema de disco es un cuello de botella del DBMS, esto no solo reduce el costo de almacenamiento, sino también una poderosa aceleración de respaldo (aunque la carga en los procesadores aumenta, pero generalmente la potencia del procesador es suficiente en el servidor DBMS).
Si en la versión 2008 esta función era solo para la edición Enterprise (que es muy costosa), entonces en 2008 R2 esta función se le dio a la versión estándar, lo cual es muy agradable.
La configuración de compresión no se cubre en los ejemplos a continuación, pero recomiendo encarecidamente usar la compresión de respaldo a menos que haya una razón específica para desactivarla.
De hecho, una copia de seguridad no es solo un archivo, es un contenedor bastante complejo que puede almacenar muchas copias de seguridad. Este enfoque tiene una historia muy antigua (lo he observado personalmente desde la versión 6.5), pero por el momento no hay razones serias para que los administradores de bases de datos "normales", especialmente las bases de datos 1C, no utilicen "una copia de seguridad - un archivo". acercamiento Para el desarrollo general, es útil estudiar la capacidad de colocar varias copias de seguridad en un solo archivo, pero lo más probable es que no tenga que usarla (o, si es necesario, entonces solucione los bloqueos de un posible administrador que usó esta oportunidad sin habilidad).
SQL Server tiene otra gran característica. Es posible formar una copia de seguridad en paralelo a varios receptores. Como un ejemplo simple, puede volcar una copia a un disco local y volcar simultáneamente a recurso de red. La copia local es conveniente, ya que la restauración es mucho más rápida, mientras que la copia remota puede sobrevivir mucho mejor a la destrucción física del servidor de la base de datos principal.
Basta de teoría. Es hora de demostrar con la práctica que toda esta cocina funciona.
Esta sección está construida en forma de recetas preparadas con explicaciones. Esta sección es muy aburrida y larga debido a las imágenes, por lo que puede omitirla.
Inmediatamente surge la pregunta, ¿qué más se necesita? ¿Parece que todo acaba de configurarse y todo funciona como un reloj? ¿Por qué trabajar duro con todo tipo de guiones? Los planes de servicio no permiten:
Los siguientes son comandos de copia de seguridad típicos
Copia de seguridad completa con sobrescritura del archivo existente (si lo hay) y verificación de las sumas de verificación de la página antes de escribir. Al crear una copia de seguridad, se cuenta cada porcentaje de progreso
RESPALDO DE BASE DE DATOS EN DISCO = N"C:\Backup\mydb.bak" CON INIT, FORMATO, ESTADÍSTICAS = 1, CHECKSUM
Del mismo modo - copia diferencial
RESPALDO DE BASE DE DATOS EN DISCO = N"C:\Backup\mydb.diff" CON DIFERENCIAL, INICIO, FORMATO, ESTADÍSTICAS = 1, SUMA DE COMPROBACIÓN
Copia de seguridad del registro de transacciones
REGISTRO DE RESPALDO EN DISCO = N"C:\Backup\mydb.trn" CON INIT, FORMATO
A menudo es conveniente hacer no una copia de seguridad a la vez, sino dos. Por ejemplo, uno puede estar localmente en el servidor (para que esté a la mano), y el segundo se convierte inmediatamente en un almacenamiento físicamente remoto y protegido contra almacenamiento adverso:
RESPALDO DE BASE DE DATOS EN DISCO = N"C:\Backup\mydb.bak", ESPEJO PARA DISK = N"\\safe-server\backup\mydb.bak" CON INIT, FORMATO
Un punto importante que a menudo se pasa por alto es que el usuario con el que se inicia el proceso del servidor MSSQL debe tener acceso al recurso "\\safe-server\backup\", de lo contrario, la copia fallará. Si MSSQL Server se está ejecutando en nombre del sistema, se debe otorgar acceso al usuario de dominio "nombre_servidor$", pero aún es mejor configurar correctamente MS SQL para que se ejecute en nombre de un usuario especialmente creado.
Si no especifica MIRROR TO , entonces no serán 2 copias espejo, sino una copia, dividida en 2 archivos, de acuerdo con el principio de fraccionamiento. Y cada uno de ellos individualmente será inútil.
Los servidores de bases de datos son una de las claves en cualquier organización. Son ellos quienes almacenan la información y proporcionan resultados a pedido, y es extremadamente importante guardar la base de datos en cualquier situación. La distribución básica suele incluir las utilidades necesarias, pero un administrador que no haya encontrado previamente una base de datos tendrá que lidiar con las peculiaridades del trabajo durante algún tiempo para garantizar la automatización.
Para empezar, averigüemos qué son las copias de seguridad en general. El servidor de la base de datos no es una aplicación de escritorio común y, para garantizar la implementación de todas las propiedades ACID (atómicas, consistentes, aisladas, duraderas), se utilizan varias tecnologías y, por lo tanto, la creación y restauración de una base de datos desde un archivo tiene su características propias. Hay tres enfoques diferentes para hacer una copia de seguridad de los datos, cada uno con sus pros y sus contras.
Con una copia de seguridad lógica o SQL (pg_dump, mysqldump, SQLCMD), se crea una instantánea instantánea del contenido de la base de datos, teniendo en cuenta la integridad transaccional y se guarda como un archivo con comandos SQL (puede seleccionar la base de datos completa o tablas), con el que se puede recrear la base de datos en otro servidor. Se necesita tiempo (especialmente para bases de datos grandes) para guardar y restaurar, por lo que muy a menudo esta operación no se puede realizar y se realiza durante una carga mínima (por ejemplo, por la noche). Al restaurar, el administrador deberá ejecutar algunos comandos para preparar todo lo necesario (crear una base de datos vacía, cuentas Etcétera).
Copia de seguridad física (nivel sistema de archivos) - copiar archivos que el DBMS usa para almacenar datos en la base de datos. Pero la copia simple ignora los bloqueos y las transacciones, que probablemente se almacenen y rompan incorrectamente. Si intenta adjuntar este archivo, estará en un estado inconsistente y dará como resultado errores. Para obtener una copia de seguridad actualizada, la base de datos debe detenerse (puede reducir el tiempo de inactividad utilizando rsync dos veces: primero en una en ejecución y luego en una detenida). La desventaja de este método es obvia: no puede restaurar ciertos datos, solo la base de datos completa. Cuando inicie una base de datos restaurada desde un archivo del sistema de archivos, deberá verificar la integridad. Aquí se utilizan varias tecnologías de asistencia. Por ejemplo, en PostgreSQL, los registros WAL (Write Ahead Logs) y funcion especial(Point in Time Recovery - PITR), que le permite volver a un estado específico de la base de datos. Con su ayuda, el tercer escenario se implementa fácilmente, cuando una copia de seguridad a nivel de sistema de archivos se combina con una copia de seguridad de archivos WAL. Primero, restauramos los archivos de respaldo del sistema de archivos y luego, usando WAL, la base de datos se actualiza. Este es un enfoque un poco más complicado para la administración, pero no hay problemas con la integridad de la base de datos y la restauración de las bases de datos a un tiempo determinado.
Una copia de seguridad lógica se utiliza en los casos en que es necesario hacer una copia completa de la base de datos una sola vez o en el uso diario no se necesita mucho tiempo o espacio para crear una copia. Cuando la descarga de bases de datos lleva mucho tiempo, debe prestar atención al archivo físico.
Licencia: GNU GPL
SGBD compatibles: postgresql
PostgreSQL admite capacidades de copia de seguridad física y lógica al agregar otra capa de WAL (consulte la barra lateral) que se puede llamar copia de seguridad continua. Pero administrar varios servidores usando herramientas estándar no es muy conveniente incluso para un administrador experimentado, y en caso de falla, la cuenta se reduce a segundos.
Barman (administrador de respaldo y recuperación) es un desarrollo interno de 2ndQuadrant, una empresa que brinda servicios basados en PostgreSQL. Diseñado para copia de seguridad física de PostgreSQL (lógico no compatible), archivado WAL y rápida recuperación después de los choques. Admite copias de seguridad y restauración remotas de varios servidores, recuperación en un momento dado (PITR), gestión WAL. SSH se utiliza para copiar y emitir comandos a un host remoto, la sincronización y la copia de seguridad mediante rsync le permiten reducir el tráfico. Barman también se integra con utilidades estándar bzip2, gzip, tar y similares. En principio, puede usar cualquier programa de compresión y archivo, la integración no llevará mucho tiempo. Implementó varias funciones de servicio y diagnóstico que le permiten monitorear el estado de los servicios y ajustar el ancho de banda. Se admiten scripts previos y posteriores.
Barman está escrito en Python, y las políticas de copia de seguridad se administran mediante el archivo INI amigable barman.conf, que se puede ubicar en /etc o en el directorio de inicio del usuario. La entrega incluye una plantilla lista para usar con comentarios detallados en el interior. Funciona solo en sistemas * nix. Para la instalación en RHEL, CentOS y Scientific Linux, debe conectarse a EPEL, un repositorio que contiene paquetes adicionales. Los usuarios de Debian/Ubuntu tienen a su disposición el repositorio oficial:
$ sudo apt-get install barman
No siempre en el repositorio ultima versión, para instalarlo tendrás que consultar los textos fuente. Hay pocas dependencias y el proceso es fácil de entender.
Licencia: BSD
SGBD compatibles: mysql
Junto con MySQL, se proporcionan las utilidades mysqldump y mysqlhotcopy, que le permiten crear fácilmente un volcado de base de datos, están bien documentadas y puede encontrar una gran cantidad de ejemplos y interfaces listos para usar en Internet. Estos últimos permiten al principiante ponerse rápidamente a trabajar. Sypex Dumper es un script PHP que le permite crear y restaurar fácilmente una copia de la base de datos datos mysql. Diseñado para trabajar con grandes bases de datos, es muy rápido, claro y fácil de usar. Sabe cómo trabajar con objetos MySQL: vistas, procedimientos, funciones, disparadores y eventos.
Otra ventaja, a diferencia de otras herramientas que convierten a UTF-8 al exportar, es que Dumper exporta en codificación nativa. El archivo resultante ocupa menos espacio y el proceso en sí es más rápido. Un volcado puede contener objetos con diferentes codificaciones. Además, es fácil de importar/exportar en varias etapas, deteniendo el proceso durante la carga. Al reiniciar, el procedimiento comenzará desde donde lo dejó. Hay cuatro opciones para la recuperación:
Admite la compresión de copia (gzip o bzip2), la eliminación automática de copias de seguridad antiguas, la visualización del contenido del archivo de volcado y la restauración solo de la estructura de las tablas. También hay funciones de servicio para administrar la base de datos (crear, eliminar, verificar, restaurar la base de datos, optimizar, limpiar tablas, trabajar con índices, etc.), así como un administrador de archivos que le permite copiar archivos al servidor.
La gestión se realiza mediante un navegador web, la interfaz AJAX está localizada de forma predeterminada y da la impresión de trabajar con una aplicación de escritorio. También es posible ejecutar trabajos desde la consola y según lo programado (a través de cron).
Para que Dumper funcione, necesitará un servidor L|WAMP clásico, la instalación es común para todas las aplicaciones escritas en PHP (copiar archivos y establecer permisos), y no será difícil incluso para un principiante. El proyecto proporciona documentación detallada y tutoriales en video que demuestran cómo trabajar con Sypex Dumper.
Hay dos ediciones: Sypex Dumper (gratis) y Pro ($10). El segundo tiene más funciones, todas las diferencias se enumeran en el sitio.
Licencia:
SGBD compatibles: Servidor MS SQL
MS SQL Server es una de las soluciones populares y, por lo tanto, es bastante común. El trabajo de copia de seguridad se crea con SQL Server Management Studio, Transact-SQL mismo y los cmdlets del módulo SQL PowerShell (Backup-SqlDatabase). En el sitio web de MS, puede encontrar una gran cantidad de documentación que le permite comprender el proceso. La documentación, aunque completa, es muy específica, y la información en Internet a menudo se contradice. Un principiante realmente necesitará practicar primero, "llenar su mano", por lo tanto, a pesar de todo lo que se ha dicho, los desarrolladores externos tienen espacio para cambiar. Además versión gratuita SQL Server Express no tiene herramientas de copia de seguridad integradas. Para más primeras versiones MS SQL (antes de 2008) puedes encontrar utilidades gratuitas, como la copia de seguridad de SQL Server, pero la mayoría de estos proyectos ya se han comercializado, aunque a menudo ofrecen toda la funcionalidad por una cantidad simbólica.
Por ejemplo, el desarrollo de SQL Backup And FTP y One-Click SQL Restore sigue el principio de configurar y olvidar. Con una interfaz muy sencilla e intuitiva, te permiten crear copias de MS SQL Server (incluyendo Express) y bases de datos Azure, guardar encriptadas y archivos comprimidos a FTP y servicios en la nube(Dropbox, Caja, Google Drive, MS SkyDrive o Amazon S3), el resultado se puede ver inmediatamente. Es posible iniciar el proceso tanto manualmente como de acuerdo con el cronograma, enviar un mensaje sobre el resultado de la tarea por correo electrónico, ejecutar scripts de usuario.
Se admiten todas las opciones de copia de seguridad: completa, diferencial, registro de transacciones, copia de una carpeta con archivos y mucho más. Las copias de seguridad antiguas se eliminan automáticamente. Para conectarse al host virtual, se usa SQL Management Studio, aunque esto puede tener matices y no funcionará en todas esas configuraciones. Se ofrecen cinco versiones para descargar: desde Gratis al elegante Prof Lifetime (solo $ 149 en el momento de escribir este artículo). La funcionalidad gratuita es suficiente para pequeñas redes, en el que están instalados uno o dos servidores SQL, todas las funciones básicas están activas. La cantidad de bases de datos de respaldo, la capacidad de enviar archivos a Google Drive y SkyDrive y el cifrado de archivos son limitados. La interfaz, aunque no está localizada, es muy simple y comprensible incluso para un principiante. Solo necesita conectarse al servidor SQL, luego de lo cual se mostrará una lista de bases de datos, debe marcar las que necesita, configurar el acceso a los recursos remotos y especificar el tiempo para que se complete la tarea. Y todo esto en una ventana.
Pero hay un "pero". El programa en sí no está diseñado para restaurar archivos. Para hacer esto, se ofrece una utilidad One-Click SQL Restore gratuita e independiente, que también comprende el formato creado por el comando BACKUP DATABASE. El administrador solo necesita especificar el archivo y el servidor en el que restaurar los datos y presionar un botón. Pero en escenarios más complejos, deberá usar RESTORE.
La creación de una copia de seguridad y la restauración de un DBMS tienen sus propias diferencias que deben tenerse en cuenta, especialmente cuando se transfiere un archivo a otro servidor. Por ejemplo, analicemos algunos de los matices de MS SQL Server. Para archivar usando Transact-SQL, use el comando BACKUP DATABASE (también hay un comando delta DIFFERENTIAL) y el registro de transacciones BACKUP LOG.
Si la copia de seguridad se implementa en un servidor diferente, debe asegurarse de que estén presentes las mismas unidades lógicas. Como alternativa, puede configurar manualmente las rutas correctas para los archivos de la base de datos mediante la opción CON MOVER del comando RESTORE DATABASE.
Una situación simple es la copia de seguridad y la transferencia de bases de datos a otras versiones de SQL Server. Esta operación es compatible, pero en el caso de SQL Server, funcionará si la versión del servidor en el que se implementa la copia es igual o más reciente que en el que se creó. Y hay una limitación: no más de dos versiones más nuevas. Después de la restauración, la base de datos estará en modo de compatibilidad con la versión desde la que se realizó la transición, es decir, las nuevas funciones no estarán disponibles. Esto es fácil de solucionar cambiando COMPATIBILITY_LEVEL. ¿Se puede hacer esto con Ayuda de interfaz gráfica de usuario o SQL.
ALTER DATABASE MyDB SET COMPATIBILITY_LEVEL = 110;
Puede determinar en qué versión se creó la copia mirando el encabezado del archivo de almacenamiento. Para no experimentar, al cambiar a nueva versión SQL Server debe ejecutar la utilidad gratuita Microsoft Upgrade Advisor.
Licencia: comercial, hay una versión gratuita
SGBD compatibles: Oracle 9-11, XE, MySQL, MariaDB, PostgreSQL y MS SQL Server
Cuando hay que gestionar varios tipos de DBMS, los combinados son indispensables. La elección es grande. Por ejemplo, Iperius es un programa de copia de seguridad de archivos ligero, muy fácil de usar y potente que tiene la capacidad de realizar copias de seguridad de bases de datos en caliente sin interrupciones ni bloqueos. Proporciona copias de seguridad completas o incrementales. Puede crear imágenes de disco completas para la reinstalación automática de todo el sistema. Admite copias de seguridad en NAS, dispositivos USB, transmisor, FTP/FTPS, Google Drive, Dropbox y SkyDrive. Admite compresión zip sin límite de tamaño de archivo y cifrado AES256, ejecutando scripts y programas externos. Incluye un programador de tareas muy funcional, es posible ejecutar varias tareas en paralelo o secuencialmente, el resultado se envía al correo electrónico. Se admiten numerosos filtros, variables para personalizar rutas y configuraciones.
La capacidad de carga FTP facilita la actualización de información en varios sitios web. Abrir archivos se respaldan utilizando la tecnología VSS (Volume Shadow Copy), que le permite realizar una copia de seguridad activa no solo de los archivos DBMS, sino también de otras aplicaciones. Para Oracle también se utiliza la herramienta de copia de seguridad y recuperación RMAN (Recovery Manager). Para no sobrecargar el canal, es posible ajustar el ancho de banda. La gestión de copias de seguridad y restauración se realiza mediante la consola web y local. Todas las funciones están a la vista, por lo que para configurar una tarea solo necesita comprender el proceso, ni siquiera tiene que consultar la documentación. Simplemente siga las instrucciones del asistente. También puede observar el administrador de cuentas, que es muy conveniente con una gran cantidad de sistemas.
Las funciones básicas se ofrecen de forma gratuita, pero la posibilidad de redundancia de la base de datos se incluye solo en las versiones Advanced DB y Full. Admite la instalación de XP a Servidor de windows 2012.
Licencia: un comercial
SGBD compatibles: Oracle, MySQL, IBM DB2 (7–9.5) y MS SQL Server
Uno de los sistemas de administración de bases de datos relacionales más poderosos es IBM DB2, que tiene funciones de escalabilidad únicas y es compatible con muchas plataformas. Se suministra en varias ediciones, que se construyen sobre la misma base y difieren funcionalmente. La arquitectura de la base de datos DB2 le permite administrar casi todos los tipos de datos: documentos, XML, archivos multimedia, etc. El DB2 Express-C gratuito es especialmente popular. La copia de seguridad es muy sencilla:
muestra de base de datos de copia de seguridad de db2
O una instantánea con la función Servicios de copia avanzados (ACS):
Instantánea de uso de ejemplo de db de copia de seguridad de db2
Pero debemos recordar que en el caso de las instantáneas, no podemos restaurar (db2 recovery db) tablas individuales. Hay oportunidades para realizar copias de seguridad automáticas y mucho más. Los productos están bien documentados, aunque los manuales son raros en Internet en ruso. Además, no todas las soluciones especiales pueden encontrar soporte para DB2.
Por ejemplo, Copia de seguridad práctica le permite realizar copias de seguridad de varios tipos de servidores de bases de datos y guardar archivos en casi cualquier medio ( disco duro, CD/DVD, nube y almacenamiento en red, FTP/S, WebDAV y otros). Es posible realizar copias de seguridad de bases de datos a través de ODBC (solo tablas). Es una de las pocas soluciones que admite DB2 y también lleva el logotipo "Ready for IBM DB2 Data Server Software". Todo el procedimiento se realiza mediante un asistente convencional, en el que solo necesita seleccionar el elemento deseado y crear una tarea. El proceso de configuración en sí es tan simple que incluso un principiante puede resolverlo. Puede crear varios trabajos que se ejecutarán según un cronograma. El resultado se registra y se envía por correo electrónico. No es necesario detener el servicio mientras se ejecuta el trabajo. El archivo se comprime y cifra automáticamente, lo que garantiza su seguridad.
El trabajo con DB2 es compatible con dos versiones de Handy Backup: Office Expert (local) y Server Network (red). Funciona en computadoras con Win8/7/Vista/XP o 2012/2008/2003. El proceso de implementación en sí no es difícil para ningún administrador.
Seguimos hablando de respaldo y hoy aprenderemos crear un archivo Bases de microsoft Servidor SQL 2008. Consideraremos todo como de costumbre con ejemplos usando tanto la interfaz gráfica como usando la consulta SQL, y también configuraremos automático crear una copia de seguridad usando un archivo por lotes.
No volveremos a la cuestión de la importancia de la copia de seguridad de la base de datos, ya que ya hemos planteado este tema más de una vez, por ejemplo, en los materiales:
Y en el último artículo, dije que consideraríamos la posibilidad de crear un archivo en el DBMS de MS SQL Server 2008, así que ahora haremos precisamente eso.
Y como ya había mucha teoría, pasemos inmediatamente a la práctica, es decir, a crear una base de respaldo.
¡Nota! Como se puede ver en el título del artículo, haremos el archivo en el DBMS de Microsoft SQL 2008 usando Management Studio. El servidor está ubicado localmente. Sistema operativo Windows 7.
Decidamos que haremos un archivo de una base de datos de prueba llamada "prueba". Desde el principio hasta interfaz gráfica de usuario, y en el proceso de esto, escribiremos un script para que en el futuro podamos simplemente ejecutarlo y no distraernos ingresando todo tipo de parámetros.
Abra Management Studio, expanda « Base de datos» , seleccione la base deseada, haga clic en botón derecho del ratón pase el mouse sobre él, seleccione Tareas->Copia de seguridad
Verás la ventana " Copia de seguridad de la base de datos”, donde puede configurar los parámetros de archivo. acabo de dar un nombre Conjunto de copia de seguridad", y también cambié el nombre del archivo y la ruta, ya que por defecto se creará en la carpeta Archivos de programa, por ejemplo, tenía la ruta predeterminada
C:\Archivos de programa\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\
Por ejemplo, lo cambié a C:\temp\ y nombré el archivo test_arh.bak
También si vas a la pestaña « Opciones», luego puede establecer la configuración para sobrescribir todos los conjuntos de datos, ahora explicaré qué es. Si dejas todo como está, es decir, agregar a un conjunto de datos existente, entonces tendrá un archivo de copia de seguridad, pero con varias instancias de conjuntos de datos, es decir al restaurar, simplemente seleccione el conjunto que necesita. Y si pones " Sobrescribir todos los conjuntos de copias de seguridad existentes”, entonces el conjunto siempre será el mismo, luego, en este caso, deberá crear archivos (digamos diarios) con diferentes nombres. Lo configuré para sobrescribir, porque digamos, en el futuro, planeo crear archivos para cada día con la fecha en el nombre de estos archivos, para poder copiar rápidamente la copia de seguridad que necesito para una fecha determinada en cualquier lugar si es necesario. .
Y por cierto, en este punto, después de ingresar todos los parámetros, puede crear un script para grabarlo y usarlo más tarde. Para hacer esto, simplemente haga clic en la parte superior Guión».
Y como resultado de esta acción, abrirá una ventana de consulta, en la que habrá un código para este script. Volveremos un poco más adelante, pero por ahora, haga clic en "Aceptar" y una vez que se complete la operación, verá una ventana en la que se indicará el resultado de la copia de seguridad, si todo está bien, aparecerá el siguiente mensaje. aparecer
Si ha hecho todo lo anterior aquellos. hizo clic en "Guión"), entonces ha abierto una ventana de consulta, que en realidad contiene la solicitud de creación de archivo en sí, pero lo reharemos un poco, ya que dije que planeamos ejecutarlo todos los días, para que el nombre sea apropiado, escribiremos esto instrucción SQL.
DECLARE @path AS VARCHAR(200) SET @path = N"C:\temp\test_arh_" + CONVERT(varchar(10), getdate(), 104) + ".bak" RESPALDO DE BASE DE DATOS EN DISCO = @path SIN FORMATO, INIT, NOMBRE = N"Prueba de base de datos", SALTAR, SIN VIENTO, SIN CARGA, ESTADÍSTICAS = 10 IR
Y ahora, si lo ejecutamos, crearemos una copia de seguridad de la base de datos con el nombre test_arh_ la fecha actual.bak
Para estos fines, MS SQL 2008 tiene oportunidad especial con derecho " Planes de servicio”, donde puede configurar un programa para crear una copia de seguridad de la base de datos, pero sugiero usar un archivo bat para estos fines para configurarlo en el programador y ejecutarlo todos los días y hacer una copia de seguridad de la base de datos.
Para ello copia instrucción SQL, que revisamos anteriormente, y péguelo en el bloc de notas ( Recomiendo el Bloc de notas++), luego guardar con extensión .sql aquellos. este script se ejecutará en MS Sql 2008. Luego tendremos que escribir un archivo por lotes para que se conecte al servidor SQL y ejecute nuestro script. También escriba en el bloc de notas:
SET cur_date=%date:~6.4%%date:~3.2%%date:~0.2% osql -S localhost -i C:\temp\test.sql -o C:\temp\%cur_date %_log_sql.log -E
donde, creé una variable cur_date para almacenar la fecha actual en ella, luego me conecto a servidor local, a través de la utilidad osql, que usa ODBC y ejecuta nuestro script ( Lo llamé test.sql), y también escribir un registro, donde y solo necesitábamos nuestra variable, eso es todo, guardar con la extensión .murciélago, creamos una tarea en el programador y podemos decir que nos olvidamos del proceso de archivo de la base de datos, bueno, solo verificamos periódicamente si el archivo se ha creado o no.
Para lo básico, esto es suficiente, ahora que sabe cómo puede hacer una copia de seguridad de las bases de datos en un servidor SQL 2008, en el próximo artículo veremos cómo puede restaurar una base de datos en MS SQL Server 2008. Mientras tanto, eso es todo ! ¡Buena suerte!
Y también: copia de seguridad SQL, copia de seguridad 1C.
El servidor 1C contiene datos en la base de datos, que se encuentra en el servidor SQL. Hoy estamos considerando MS SQL 2005/2008.
Para garantizar que los datos no se pierdan en caso de que se queme un disco del servidor u otras situaciones de fuerza mayor, es necesario realizar copias de seguridad desde el principio.
Por supuesto, nadie quiere hacer bolígrafos todos los días Copia de seguridad de la base de datos SQL 1C. Hay herramientas automáticas para esto. Conozcámoslos.
Configuración de BackupSQL
Configurar Backup SQL para una base de datos 1C no es diferente de configurar un respaldo para cualquier otra base de datos.
Para configurar, ejecute MS SQL Management Studio. Este programa está en el grupo de programas MS SQL.
Adición de una tarea de copia de seguridad de la base de datos SQL 1C
Las tareas para la copia de seguridad automática de las bases de datos SQL se encuentran en la rama Gestión / Planes de mantenimiento.
Para agregar una nueva tarea de copia de seguridad, haga clic con el botón derecho en el grupo Planes de mantenimiento y seleccione Nuevo plan de mantenimiento.
Introduzca el nombre de la tarea. El nombre solo te importa a ti. Por si acaso, es mejor usar caracteres ingleses.
Configuración de un trabajo de copia de seguridad de la base de datos SQL 1C
Se abrirá el Editor de trabajos. Tenga en cuenta que los trabajos pueden realizar varias operaciones con la base de datos, y no solo copias de seguridad.
La lista de opciones para las operaciones se muestra en la parte inferior izquierda. Seleccione Tarea de copia de seguridad de la base de datos haciendo doble clic o simplemente arrastrando hacia la derecha.
Fíjate en la flecha. Puede arrastrar y soltar varias operaciones diferentes o idénticas y vincularlas con flechas. Luego se ejecutarán varias tareas a la vez en la secuencia especificada por usted.
En la ventana de configuración, seleccione las bases de datos SQL 1C requeridas (puede tener varias o una a la vez).
Seleccione la ubicación para guardar la copia de seguridad de la base de datos SQL 1C. Debe seleccionar un disco duro físicamente diferente. Organizativamente, puede marcar la casilla "Crear subcarpetas".
Ahora vamos a configurar el programa de copia de seguridad. El programa de copia de seguridad predeterminado se agregó solo. Pero puede agregar varios horarios (por ejemplo, uno diario, uno semanal, etc.). Haga clic en el botón de configuración del programa de copia de seguridad.
La captura de pantalla muestra un ejemplo de una base de datos SQL de copia de seguridad diaria 1C a las 3 am.
Para que el programa de copia de seguridad de la lista sea agradable y comprensible, puede cambiarlo.
Guardar un trabajo de copia de seguridad de la base de datos SQL 1C
Haga clic en grabar. La tarea aparecerá en el lado izquierdo de la lista.
¡Es importante! Compruebe que la tarea de copia de seguridad de la base de datos SQL se haya creado correctamente. Para hacer esto, haga clic derecho en la tarea y seleccione Ejecutar.
Como resultado, debería aparecer un archivo de copia de seguridad en la ruta especificada. Si algo está mal, elimine la tarea (Del) y comience desde el principio.
Consideremos una situación indeseable. A saber: por alguna razón, la base de datos falló. ¿Que tenemos? Una copia completa, una copia diferencial para ayer, pero también hay datos para hoy, ¿realmente era necesario hacer una copia diferencial cada hora? - ¡No! Comer registro de transacciones.
El registro de transacciones es un registro que registra todas las transacciones y todos los cambios en la base de datos realizados por cada transacción. Aquellos. cualquier acción con la base de datos se registra paso a paso en el registro. Cada registro está marcado por el DBMS para la finalización de la transacción, completada o no. Con su ayuda, puede restaurar el estado de la base de datos no solo después de una falla, sino también en caso de acciones imprevistas con los datos. Retroceso hasta un tiempo determinado. Al igual que con la base de datos, es necesario realizar una copia de seguridad del registro de transacciones, completo, diferencial e incremental. Para restaurar parte del registro de transacciones después de una falla entre copias de seguridad, debe hacer una copia de seguridad de la parte final del registro, que, de hecho, es el punto de finalización de la copia de seguridad. Ejecutado después de un accidente, como un punto de cuenta atrás.
Entonces, para restaurar la base de datos después de un bloqueo, necesitamos una copia completa actualizada de la base de datos, una copia diferencial de la base de datos y una copia del registro de transacciones.
Para la base de datos en sí, hay 3 modelos de recuperación: simple, completo y registro masivo. Considerar:
Consideremos la cadena de copia de seguridad más relevante: copia de seguridad completa: una vez por semana, copia de seguridad diferencial: una vez al día, copia de seguridad del registro de transacciones: una vez por hora.
Hay varias opciones para crear copias de seguridad:
Considere la primera opción como la más útil. Para ello se utilizan Windows Server 2008 R2 Enterprise y MS SQL Server 2008 Eng.
Así que digamos que tenemos una base de datos TECH:
Pasemos a la herramienta de creación de empleo:
Tres botones con el botón derecho del mouse y llamar a Master Job:
Seleccionamos la casilla de verificación "Ejecución separada de cada tarea", estamos realizando solo una acción
El maestro no tiene turbante, pero lo principal no es el tamaño del turbante)) Seleccionamos el tipo de deseo, en nuestro caso, reserva completa:
El maestro Joba resultó ser un poco judío, por lo que vuelve a preguntar:
"Vale la pena elegir opciones adicionales, ¡oh, joven paddawan!":
aquí seleccionamos la base de datos, el período de almacenamiento de la copia de seguridad, la dirección (cinta o disco), la ruta de guardado y, lo más importante, ¡el programador de tareas!
"No te olvides de la base de datos a la hora de elegir la tuya. Concentra tu poder y elige la base de datos":
"Demasiado rápido tiene prisa por crear una tarea, haga clic en el botón de abajo con el nombre Programar - Definir".
Sobsno, programador de tareas, donde seleccionamos el tipo (repetición, una vez, etc.), día, hora, tipo de inicio:
Eso es todo, creado. El maestro Joba es genial y verde. Miramos el estado en Planes de Mantenimiento:
Para los paranoicos, no tengan miedo de admitirlo ante el espejo, vale la pena mirar el alma del Agente SQL Server - Monitor de actividad de trabajo, Job Master mostrará todo en detalle:
Ahora, si se cumplen las condiciones dadas, debería crear copia de seguridad completa DB. Por el mismo principio, se crean una copia de seguridad diferencial y una copia de seguridad del registro de transacciones (estos subelementos se encuentran debajo de "Copia de seguridad completa" en la lista de selección de tareas).
Tuerce las orejas con MSSQL como quieras, no desenrosques
El siguiente artículo cubre la creación con Transact-SQL y un par de ejemplos.
