Recuperación de Archivos en una Base de datos con archivos log.

Los ficheros de registro (log) de MySQL

MySQL tiene varios archivos de registro diferentes:

Por defecto, todos los registros son creados en el directorio de datos de mysql.
Puede forzar a MySQL a que cierre y reabra los archivos de registro (o en algunos
casos, cambiar a un nuevo registro) mediante el volcado de registros.
El volcado de registros ocurre cuando ejecuta la sentencia FLUSH LOGS o el
comando [mysqladmin flush-logs] or [mysqladmin refresh].
El registro de errroes (Error Log).
Contiene información que indica cuando se ha iniciado y parado MySQL y también
si ha ocurrido algún error crítico mientras el servidor se estaba ejecutando.
Si mysqld termina inesperadamente y mysqld_safe necesita reiniciarlo, mysqld_safe
escribe un mensaje restarted mysqld en el registro de errores.
Si mysqld se da cuenta de que hay una tabla que necesita ser automáticamente
comprobada o reparada, escribe un mensaje al registro de errores.
En algunos sistemas operativos, el registro de errores contiene un volcado de la pila
si mysqld muere. El volcado puede ser utilizado para determinar cuándo mysqld
murió.
En MySQL 5.0, puede especificar dónde quiere que mysqld almacene el registro de
errores con la opción --log-error[=file_name].
Si no se proporciona ningún valor para file_name, mysqld utiliza el nombre
host_name.err y escribe el archivo en el directorio de datos. Si ejecuta FLUSH
LOGS, el registro de errores es renombrado con el sufijo -old y mysqld crea un
nuevo archivo de registro.
Si no especifica --log-error, o (en Windows) no utiliza la opción --console, los errores
se escriben en stderr, la salida estándar de erroes.
Usualmente esto es su terminal.
En Windows, la salida de errores es siempre escrita al archivo .err si no se especifica
la opción --console.
El registro general de consultas
Si quiere saber qué pasa en mysqld, debe iniciarlo con la opción --log[=file_name]
o -l [file_name].
Si no se da un valor para file_name, el nombre por defecto es host_name.log. Esto
registra todas las conexiones y sentencias a un archivo. Este registro puede ser muy
útil cuando sospeche que hay un error en un cliente y quiera saber exactamente
qué envió el cliente a mysqld.
mysqld escribe las sentencias al registro de consultas en el orden en que las recibe.
Este orden puede ser diferente del de ejecución. Esto es aquí diferente que en el
registro de actualizaciones o el registro binario, que son escritos tras la ejecución
de la sentencia, pero antes de que se libere cualquier bloqueo. (El registro de
consultas también contiene todas las sentencias, mientras que el registro binario no
contiene sentencias que solo seleccionen datos.)
Los reinicios del servidor y volcado de registros no provocan que se genere un
nuevo archivo de registro de consultas general (aunque el volcado lo cierra y lo
reabre). En Unix, puede renombrar el archivo y crear uno nuevo utilizando los
siguientes comandos:

En Windows, no puede renombrar el archivo de registro mientras el servidor lo tiene

abierto. Debe parar el servidor y renombrar el registro. Después, reinicie el servidor
para crear el nuevo registro.
El registro binario (Binary Log)
El registro binario contiene toda la información que está disponible en el registro de
actualizaciones, en un formato más eficiente y de una manera que es segura para
las transacciones.
El registro binario contiene todas las sentencias que han actualizado datos o podrían
haberlo hecho (por ejemplo, un DELETE que no encontró filas concordantes). Las
sentencias se almacenan en la forma de eventos que describen las modificaciones.
Atención: El registro binario ha reemplazado al antiguo registro de actualizaciones,
que ya no está disponible a partir de MySQL 5.0.
El propósito principal del registro binario es el de actualizar la base de datos durante
una operación de recuperación tan completamente como sea posible, porque el
registro binario contiene todas las actualizaciones hechas tras la copia de seguridad.
El registro binario también se utiliza en los servidores maestros de replicación como
recordatorio de las sentencias que deben ser enviadas a los servidores esclavos.
Ejecutar el servidor con el registro binario activado hace que el rendimiento baje un
1%. Aun así, los beneficios del registro binario para las operaciones de restauración
y el hecho de permitirnos poder establecer replicación generalmente son superiores
a este decremento de rendimiento.
Cuando se ha iniciado con la opción --log-bin[=file_name]. mysqld escribe un
archivo de registro que contiene todos los comandos SQL que actualizan datos.
Si no se da ningún valor para file_name, el valor por defecto es el nombre de la
máuqina host seguido por -bin. Si se da el nombre del archivo, pero ninguna ruta, el
archivo se escribe en el directorio de datos. Se recomienda especificar un nombre
de archivo.
Ver los archivos de datos y de registro en un conjunto de copia de seguridad
(SQL Server)
En SQL Server 2008 y versiones posteriores, la obtención de información sobre un
conjunto de copia de seguridad o un dispositivo de copia de seguridad requiere el
permiso CREATE DATABASE.
Restaurar una copia de seguridad de registros de transacciones (SQL Server)
Las copias de seguridad deben restaurarse en el mismo orden en el que se crearon.
La copia de seguridad completa de la base de datos y la última copia de seguridad
diferencial, si hay alguna, anteriores a la copia de seguridad del registro de
transacciones. La base de datos debe haber utilizado el modelo de recuperación
completa o el modelo de recuperación optimizado para cargas masivas de registros
antes de crearse la copia de seguridad completa o diferencial más reciente.
Permissions
Los permisos RESTORE se conceden a los roles en los que la información acerca
de la pertenencia está siempre disponible para el servidor. Debido a que la
pertenencia a un rol fijo de base de datos solo se puede comprobar cuando la base
de datos es accesible y no está dañada, lo que no siempre ocurre cuando se ejecuta
RESTORE, los miembros del rol fijo de base de datos db_owner no tienen permisos
RESTORE.
Para restaurar una copia de seguridad del registro de transacciones
Usar SQL Server Management Studio
1.-Tras conectarse a la instancia apropiada de Microsoft Motor de base de datos de
SQL Server, en el Explorador de objetos, haga clic en el nombre del servidor para
expandir el árbol correspondiente.
2.-Expanda Bases de datosy, en función de la base de datos, seleccione la base de
datos de un usuario o expanda Bases de datos del sistema y seleccione una base
de datos del sistema.
3.-Haga clic con el botón derecho en la base de datos, seleccione Tareas,
Restaurary, después, haga clic en Registro de transacciones, con lo que se abre el
cuadro de diálogo Restaurar registro de transacciones.
4.-En el cuadro de lista Base de datos de la página General, seleccione el nombre
de una base de datos. Solo aparecerán las bases de datos en estado de
restauración.
5.-Para especificar el origen y la ubicación de los conjuntos de copias de seguridad
que se deben restaurar, haga clic en una de las opciones siguientes:
Desde copias de seguridad de bases de datos anteriores
Seleccione la base de datos que desea restaurar en la lista desplegable. La lista
solo contiene las bases de datos de las que se han realizado copias de seguridad
de acuerdo con el historial de copias de seguridad de msdb.
Desde archivo o cinta
Haga clic en el botón de exploración (...) para abrir el cuadro de diálogo Seleccionar
dispositivos de copia de seguridad. En el cuadro Tipo de medio de copia de
seguridad, seleccione uno de los tipos de dispositivo. Para seleccionar uno o varios
dispositivos del cuadro Medio de copia de seguridad, haga clic en Agregar.
6.-Después de agregar los dispositivos que desee al cuadro de lista Medio de copia
de seguridad, haga clic en Aceptar para volver a la página General.
En la cuadrícula Seleccionar las copias de seguridad del registro de transacciones
que se van a restaurar, seleccione las copias de seguridad que desea restaurar. En
esta cuadrícula se muestran las copias de seguridad del registro de transacciones
disponibles para la base de datos seleccionada. Una copia de seguridad del registro
de transacciones solo está disponible si el Primer LSN es superior al Último LSN de
la base de datos. Las copias de seguridad de registros aparecen en el orden de los
números de secuencia de registro (LSN) que contienen y se deben restaurar en este
orden.
En la tabla siguiente se muestran los encabezados de columna de la cuadrícula y
se describen sus valores.
Para restaurar una copia de seguridad del registro de transacciones
Ejecute la instrucción RESTORE LOG para aplicar la copia de seguridad del registro
de transacciones especificando:
El nombre de la base de datos a la que se aplicará el registro de transacciones.
El dispositivo de copia de seguridad desde el que se restaurará la copia de
seguridad del registro de transacciones.
La cláusula NORECOVERY.
La sintaxis básica de esta instrucción es la siguiente:
RESTORE LOG nombre_de_base_de_datos FROM
<dispositivo_de_copia_de_seguridad> WITH NORECOVERY.
Donde nombre_de_base_de_datos es el nombre de la base de datos y
<dispositivo_de_copia_de_seguridad> es el nombre del dispositivo que contiene la
copia de seguridad de registros que se va a restaurar.
Repita el paso 1 para cada copia de seguridad del registro de transacciones que
tenga que aplicar.
Después de restaurar la copia de seguridad más reciente en la secuencia de
restauración, use una de las instrucciones siguientes para recuperar la base de
datos:
 Recuperar la base de datos como parte de la última instrucción RESTORE
LOG:
RESTORE LOG <database_name> FROM <backup_device> WITH RECOVERY;
GO

 Esperar a recuperar la base de datos utilizando otra instrucción RESTORE

DATABASE:
RESTORE LOG <database_name> FROM <backup_device> WITH NORECOVERY;
RESTORE DATABASE <database_name> WITH RECOVERY;
GO
Hacer una copia de seguridad de tu base de datos
Abrimos el programa worbeanch y hecemos click en “New Server Instance” (parte
derecha de la pantalla de bienvenida), donde introduciremos nuestra IP del servidor,
usuario y contraseña a través del asistente.

Una vez conectado nos aparecerá una nueva pantalla donde veremos el
rendimiento del servidor y las consultas que se estén haciendo en tiempo real, y en
la parte izquierda, un menú donde pone: “Data Export”. Seleccionamos la base de
datos y las tablas que deseemos y abajo marcamos la opción “Export to Self
Contained File” donde eligiremos donde se guardaran el fichero y pulsamos sobre
“Start Export”.
Este sería el metodo tradicional mediante linea de comandos, si te encuentras en el
mismo servidor o bien has accedido mediante la consola mysql o ssh previamente:
mysqldump -u USUARIO -p CONTRASENA -all-databases > respaldo.sql

https://www.profesionalhosting.com/soporte-en-linea/basura-/los-ficheros-de-
registro-log-de-mysql.html
https://docs.microsoft.com/es-es/sql/relational-databases/backup-restore/view-the-
data-and-log-files-in-a-backup-set-sql-server?view=sql-server-2017
https://www.alvarolara.com/2013/02/25/backup-de-base-de-datos-desde-mysql-
workbench/