Respaldos

 ¿Por qué es importante para el administrador saber hacer respaldos?

Un SGBD proporciona las herramientas necesarias para la conservación de copias de seguridad de cada fichero como prevención ante posibles caídas del sistema.

Planificar y comprobar los procedimientos de backup del sistema es la única garantía que existe contra fallas del sistema, del SO, del software o cualquier otro tipo de circunstancias.

¿Es responsabilidad del administrador hacer un respaldo periódico de los sistemas de archivos de la máquina que administra?

Los administradores de sistemas que tienen un buen entendimiento de sus sistemas, usuarios y aplicaciones deberían ser capaces de agrupar rápidamente en sus sistemas en diferentes categorías. 

La mayoría de los administradores de sistemas en este punto, ven hacia una de dos soluciones:

·         Comprar una solución desarrollada comercialmente

·         Desarrollar una solución casera de sistema de respaldo desde el principio (posiblemente integrando una o más tecnologías de código abierto)

Esta similaridad se debe al hecho de que un respaldo completo no verifica para ver si un archivo ha cambiado desde el último respaldo; ciegamente escribe todo a la media de respaldo, haya sido modificada o no.

Esta es la razón por la que los respaldos completos no se hacen todo el tiempo - cada archivo es escrito a la media de respaldo. Esto significa el uso de gran cantidad de media de respaldo aun cuando nada se haya cambiado. Respaldar 100 GB de datos cada noche cuando solamente cambió 10 MB de datos, no es una buena solución; por eso es que se crean los respaldos incrementales.

¿Cómo se hace un respaldo y ¿Cómo se restaura un respaldo ?

Procedimiento Respaldo Offline o frio

1.- Bajar la base de datos (SHUTDOWN [NORMAL,| IMMEDIATE | TRANSACTIONAL])

2.- Anote el layout físico de filesystems, podría ser necesario en caso de falla de disco

3.- Hacer copias de todos los datafiles de tablespaces con comandos del sistema operativo

4.- Hacer copias de todos los archivos de online redologs con comandos del sistema operativo

5.- Hacer copias de todos los archivos de control con comandos del sistema operativo

6.- Hacer copia del archivo de parámetros spfile o init%SID%.ora

Procedimiento Respaldo Caliente

1.- Ejecute comando archive log list. Note que el valor para Oldest online log sequence es el redolog más antiguo requerido para usar en el online backup

·                   SQL> archive log list;

·                Database log mode  Archive Mode

·                  Automatic archival  Enabled

·                  Archive destination  /u02/oradata/orion/archive

·                  Oldest online log sequence 672

·                  Next log sequence to archive 674

·                 Current log sequence 674

·                   SQL>

2.- Ejecute ALTER TABLESPACE nombre_tablespace BEGIN BACKUP desde sqlplus. Esto prepara el respaldo online de los datafiles del tablespace.

              SQL> alter tablespace users begin backup;

3.- Copie los datafiles por cada tablespace usando comandos de sistema operativos o productos de terceros. Asegúrese que las copias residan en un� disco diferente al que se encuentran los datafiles de producción.

4.- Ejecute ALTER TABLESPACE nombre_tablespace END BACKUP desde sqlplus. Este paso completa el respaldo online del tablespace.

                SQL> alter tablespace users end backup;

5.- Repita pasos 2 al 4 hasta que todos los tablespaces se encuentren respaldados. (Se exceptúan los tablespaces TEMPORALES)

6.- Ejecute comando archive log list nuevamente. Esta vez, note que el valor para Current log sequence. Este es el último redolog que forma parte esencial del online backup

·                   SQL> archive log list;

·                   Database log mode Archive Mode

·                   Automatic archival Enabled

·                   Archive destination /u02/oradata/orion/archive

·                   Oldest online log sequence 672

·                   Next log sequence to archive 681

·                   Current log sequence 681

·                   SQL>

7.- Ejecute ALTER SYSTEM SWITCH LOGFILE para obligar a Oracle a archivar el Current redolog file. Este archivo debe ser almacenado en el área de destino de los archive log, en el caso del ejemplo  /u02/oradata/orion/archive. Si desea, copie los archive log que se generaron durante el proceso de respaldo (en el ejemplo secuencias 672 a 681) a la cinta junto con el resto del respaldo.

                SQL> ALTER SYSTEM SWITCH LOGFILE;

8.- Crear una copia del archivo de control.

                SQL> ALTER DATABASE BACKUP CONTROLFILE TO '/backupDir/control.bck';

Recuperación

Para ejecutar tareas de respaldo y recuperación RMAN debe conectarse a una base de datos target (con privilegios SYSDBA). RMAN también se puede conectar a una base de datos de CATALOGO DE RECUPERACION si se desea utilizar uno. Se especifica las bases de datos target y de catálogo de recuperación usando las opciones de línea de comando o usando el comando CONNECT dentro de RMAN.

Este comando conecta al RMAN a una base de datos target database y un catálogo de  recuperación:

% rman TARGET / CATALOG usuario_catalog/pwd@cat_tns_alias 

Este comando conecta al RMAN a una base de datos target sin usar un catálogo de recuperación:

% rman TARGET SYS/pwd@target_str 

Este comando inicia RMAN sin conectarse a una base de datos:

% rman

¿Cómo se muestra respaldo?

1. Hacer una copia completa de su base de datos:

2.     shell> mysqldump --tab=/path/to/some/dir --opt db_name

O:

shell> mysqlhotcopy db_name /path/to/some/dir

También puede simplemente copiar todos los archivos de tablas (*.frm, *.MYD, y *.MYI) siempre que el servidor no esté actualizando nada. El script mysqlhotcopy utiliza este método. (Pero tenga en cuenta que estos métodos no funcionan si su base de datos contiene tablas InnoDB. InnoDB no almacena los contenidos de las tablas en directorios de base de datos, y mysqlhotcopy funciona solo para tablas MyISAM e ISAM.)

3. Pare mysqld si se está ejecutando, y después reinicielo con la opción --log-bin[=file_name]. Consulte Sección 5.10.3, “El registro binario (Binary Log)”. Los archivos binarios de registro le dan la información que necesita para replicar los cambios que se han producido en la base de datos tras el punto en que usted ejecutó mysqldump.

Como restaurar una base de datos?

La copia de seguridad la puedes restaurar de varios modos. Te comentaré un par de ellos.

Primero, si tienes PhpMyAdmin instalado en el ordenador donde deseas restaurar la base de datos, tal vez te venga bien para recuperar la información. Simplemente utiliza la herramienta de ejecutar sentencias SQL. Incluso esta herramienta de PhpMyAdmin tiene un lugar donde subir un archivo con sentencias SQL para ejecutarlas en el servidor. Lo malo es que el archivo con el backup no puede ocupar más de 2 megas.

Otra manera de restaurar una copia de seguridad sería por medio del propio sistema de línea de comandos de MySQL. Con este sistema te puedes conectar a una base de datos en tu ordenador o a cualquier servidor MySQL que tengas permisos de acceso. La sentencia para restaurar una base de datos en el ordenador local sería:

mysql --password=tuclave --user=tuusuario mibase < ficherosentencias.sql

Si quisiéramos recuperar el backup en otro servidor, también lo podríamos hacer con la línea de comandos de MySQL, pero mediante una sentencia que incluya el host al que nos queremos conectar:

mysql --password=tuclave --user=tuusuario -h 192.168.1.134 basedatos < respaldo.sql

Tener en cuenta que el host al que deseamos conectar, en este caso el servidor con la IP 192.168.1.134, tiene que tener permitido el acceso con ese usuario y clave y para el ordenador desde donde estamos conectando. Así mismo, también este login tiene que disponer de privilegios para ejecutar las sentencias SQL del respaldo sobre la base de datos base datos.

Todo el tema de permisos y privilegios sobre bases de datos MySQL se administra fácilmente con MySQL Administrator.

actividad espejos en equipo

enlace relizacion de espejo

mirroring

Que es Espejeo?

Database Mirroring es una solución alternativa de Alta Diponibilidad, nueva en SQL Server 2005, que puede verse como la evolución natural de Log Shipping (tecnología disponible en ediciones anteriores de SQL Server, basada en la entrega de Logs de Transacciones sobre una copia de la base de datos en un servidor secundario en espera, es decir, hacer RESTORE LOG WITH NORECOVERY a "tutti" ;-). Así, existen varias diferencias entre Database Mirroring y Log Shipping, por ejemplo, Log Shipping permite funcionar.
 Database Mirroring es una tecnología de Alta Disponibilidad basada en un modo de funcionamiento Activo / Pasivo. Es decir, mientras una Instancia realiza un papel de Servidor Principal (Activo) para una base de datos en particular, la otra instancia realiza el papel de Servidor Espejo o Secundario (Pasivo) para dicha base de datos.


 Beneficios del espejeo de Datos en un DBMS?

A diferencia de Log Shipping, Database Mirroring ofrece recuperación automática ante fallos (automatic failover) sin necesidad de disponer de ninguna solución hardware especial ni propietaria, con lo cual, se muestra como una alternativa de bajo coste a las soluciones basadas en Microsoft Cluster (o Server Clustering). Además, para casos de balanceo (failover), es posible desarrollar las aplicaciones cliente para que se re-conecten automáticamente a la base de datos activa (es decir, a la que actúe como base de datos principal), como se indica más adelante en el capítulo de Administración y Mantenimiento de Database Mirroring (ver la sección Redirección de Cliente: ADO.NET / SQL Native Client automatic redirection).

como se hace una Activación de espejeo en un DBMS?

La comunicación entre los diferentes servidores SQL Server de una topología Database Mirroring, se realiza a través de Extremos o Endpoints de SQL Server específicos para Database Mirroring, un tipo de objeto de servidor nuevo en SQL Server 2005, que permiten la creación de caminos de comunicación con Instancias de SQL Server. La ventaja de la utilización de Extremos o Endpoints, es que permiten configurar sus requisitos de Autenticación y Cifrado, ofreciendo así un camino de comunicación más o menos seguro (en función de las necesidades de cada caso). Por defecto, la creación de Extremos o Endpoints (CREATE ENDPOINT) para Database Mirroring a través del Asistente incluido en SQL Server 2005, implicará la creación de Extremos o Endpoints con Autenticación y Cifrado.
los posibles papeles o roles que puede desempeñar una instancia de SQL Server en una solución de Database Mirroring son:

• Servidor Principal. Mantiene la copia activa de la base de datos (base de datos principal), a través de la cual, se ofrece el servicio a los usuarios. Todas las transacciones son enviadas al Servidor Espejo antes de aplicarlas en la base de datos principal.
• Servidor Espejo (Mirror). Mantiene una copia de la base de datos principal (base de datos espejo o mirror database), y aplica todas las transacciones enviadas por el Servidor Principal, manteniendo sincronizada la base de datos espejo.
• Servidor Testigo (Witness). Se trata de un elemento opcional. No es obligatorio o necesario implementar un Servidor Testigo (Witness) en una solución de Database Mirroring.

ejmplos de Creación de espacios de disco con espejo.


puedes usar los siguientes pasos para colocar la BD operativa inmediatamente en el servidor Mirror.

USE
master
GO

ALTER DATABASE NombredelaBD SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS
GO

/////////////////////////////
creacion:
1. Primeramente preparamos nuestra base de datos espejo en nuestro server o instancia que fungirá como tal, aquí dos puntos importantes: Que la base datos que restauremos sea el ultimo backup realizado desde la principal. A la hora de restaurarla tenemos que marcar la opción de NON RECOVERY.



2. En el Management Studio, Explorador de Objetos, Seleccionamos una base de datos, hacemos click derecho sobre ella en la opción, Task, Mirror.

3. El primer paso sería configurar la seguridad, para lo cual vamos a seguir un asistente.


En el primer paso del asistente nos preguntara si queremos tener una instancia de testigo, para este primer ejempo le diremos que No.

4. Luego definiremos el servidor principal

5. Ahora definiremos nuestra instancia o servidor espejo

6. En este paso se definen las cuentas de usuario que utilizaran tanto el servidor principal como el espejo que estén en un dominio. Para nuestro ejemplo dejaremos en blanco esta opción.

7. Finalmente terminanos de configurar el asistente de seguridad.

8. Una vez finalizado nos pedirá si deseamos iniciar el mirroring, le diremos iniciar.

9. Ya tendremos configurado nuestro mirroring como se muestra en la pantalla siguiente, desde aquí podemos iniciar el mirroring, y podemos configurar el tipo de operación que deseamos, tal y cual se planteo al inicio del articulo. Hacemos click en OK.

La Redirección Automática del cliente en una infraestructura de Database Mirroring, es una funcionalidad muy apreciada, y en este caso, es tan fácil como utilizar una sintaxis determinada en la cadena de conexión a SQL Server, como se muestra en el siguiente:

"Data Source=PORTATIL;Failover Partner=PORTATIL\MIRROR;Initial Catalog=Demo;Integrated Security=True;"

replicacion

QUE ES REPLICA?

Un buen número de aplicaciones informáticas están accesibles a través de la red, siguiendo un modelo cliente-servidor. En algunos casos, tiene gran importancia que tales servicios se presten de manera continua. Para esto, se deben utilizar técnicas de replicación.

La replicación es un mecanismo utilizado para propagar y diseminar datos en un ambiente distribuido, con el objetivo de tener mejor performance y confiabilidad, mediante la reducción de dependencia de un sistema de base de datos centralizado.

La replicación de la información en una BDD apunta a aumentar la disponibilidad de la información. Esta disponibilidad puede observarse desde dos perspectivas:

·         Aumentar el paralelismo en las consultas, dado que la misma información residirá en más de una localidad de la red.

·         Mejorar la disponibilidad de los datos ante eventuales caídas de nodos de la red.

El concepto de replicación es muy amplio e involucra muchos aspectos que hacen al diseño de datos de la BDD. Los protocolos de aseguramiento de integridad de la información y los protocolos de actualización de las replicas son los puntos más interesantes para ser tenidos en cuenta.

 Beneficios de la réplica de Datos en un DBMS

Con la replicación se pueden llegar a obtener dos mejoras importantes:

·         1. Por un lado, se garantiza que el servicio ofrecido por la aplicación, no se vea interrumpido en caso de que se dé un fallo en alguna de las réplicas. Además, el tiempo necesario para restablecer el servicio en la aplicación podría llegar a ser grande en algunos tipos de fallo.

·         2. Por otra parte, la capacidad de servicio se ve incrementada cuando las peticiones efectuadas por los clientes únicamente implican consultas.

• Disponibilidad.-El modo en que la replicación incrementa la disponibilidad de los datos para los usuarios y aplicaciones.
•  Fiabilidad.- Al haber múltiples copias de los datos disponibles en el sistema, se dispone de un mecanismo excelente de recuperación cuando existan fallos en nodos.
•  Rendimiento.- Se mejora para las transacciones de consulta cuando se introduce la replicación en un sistema que estuviera aquejado de sobrecarga de recursos centralizados.
•  Reducción de la carga.- Modo en q se utiliza la replicación para distribuir datos en ubicaciones remotas
• 4. Procesamiento Desconectado.- Modo en que la replicación puede implementarse mediante mecanismo instantáneas.
• Soporta muchos usuarios.- Se puede crear múltiples instantáneas personalizadas que satisfagan los requisitos de cada usuario o grupo de usuarios del sistema.
• Soporta Aplicaciones Avanzadas.- Para OLPT(Online transaction Processing), OLAP(Online Analitical Processing)

COMO APLICARLO

Nota: este procedimiento y algunos de los comandos de replicación SQL mostrados en secciones posteriores necesita el privilegio SUPER.

1.    Asegúrese de que las versiones de MySQL instalado en el maestro y en el esclavo son compatibles según dice la tabla mostrada en Sección 6.5, “Compatibilidad entre versiones de MySQL con respecto a la replicación”.

2.    Prepare una cuenta en el maestro que pueda usar el esclavo para conectar. Este cuenta debe tener el privilegioREPLICATION SLAVE . Si la cuenta se usa sólo para replicación (lo que se recomienda), no necesita dar ningún privilegio adicional.

Suponga que su dominio es mydomain.com y que quiere crear una cuenta con un nombre de usuario de replque puedan usar los esclavos para acceder al maestro desde cualquier equipo en su dominio usando una contraseña de slavepass. Para crear la cuenta, use el comando GRANT:

mysql> GRANT REPLICATION SLAVE ON *.*

    -> TO 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass';

Si quiere usar los comandos LOAD TABLE FROM MASTER o LOAD DATA FROM MASTER desde el servidor esclavo, necesita dar a esta cuenta privilegios adicionales:

3. De a la cuenta el privilegio global SUPER y RELOAD .
4. De el privilegio SELECT para todas las tablas que quiere cargar. Cualquier tabla maestra desde la que la cuenta no puede hacer un SELECT se ignoran por LOAD DATA FROM MASTER.

5.    Si usa sólo tablas MyISAM , vuelque todas las tablas y bloquee los comandos de escritura ejecutando un comandoFLUSH TABLES WITH READ LOCK :

6.    mysql> FLUSH TABLES WITH READ LOCK;

Para usar tar para crear un archivo que incluya todas las bases de datos, cambie la localización en el directorio de datos del maestro, luego ejecute el comando:

shell> tar -cvf /tmp/mysql-snapshot.tar .

Si quiere que el archivo sólo incluya una base de datos llamada this_db, use este comando:

shell> tar -cvf /tmp/mysql-snapshot.tar ./this_db

Luego copie el archivo en el directorio /tmp del servidor esclavo. En esa máquina, cambie la localización al directorio de datos del esclavo, y desempaquete el fichero usando este comando:

shell> tar -xvf /tmp/mysql-snapshot.tar

Puede no querer replicar la base de datos mysql si el servidor esclavo tiene un conjunto distinto de cuentas de usuario a la existente en el maestro. En tal caso, debe excluírla del archivo. Tampoco necesita incluir ningún fichero de log en el archivo, o los ficheros master.info o relay-log.info files.

Mientras el bloqueo de FLUSH TABLES WITH READ LOCK está en efecto, lee el valor del nombre y el desplazamiento del log binario actual en el maestro:

mysql > SHOW MASTER STATUS;

+---------------+----------+--------------+------------------+

| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+---------------+----------+--------------+------------------+

| mysql-bin.003 | 73       | test         | manual,mysql     |

+---------------+----------+--------------+------------------+

Una vez que tiene los datos y ha guardado el nombre y desplazamiento del log, puede reanudar la actividad de escritura en el maestro:

mysql> UNLOCK TABLES;

Si está usando tablas InnoDB , debería usar la herramienta InnoDB Hot Backup. Realiza una copia consistente sin bloquear el servidor maestro, y guarda el nombre y desplazamiento del log que se corresponden a la copia para usarlo posteriormente en el esclavo.

Para guardar los nombres de ficheros actual y desplazamientos, debe ejecutar el siguiente comando antes de parar el servidor:

mysql> FLUSH TABLES WITH READ LOCK;

mysql> SHOW MASTER STATUS;

Tras guardar el nombre del log y el desplazamiento, pare el servidor sin bloquear las tablas para asegurarse que el servidor para con el conjunto de datos correspondiente al fichero de log correspondiente y desplazamiento:

shell> mysqladmin -u root shutdown

Asegúrese que la sección [mysqld] del fichero my.cnf en el maestro incluye una opción log-bin . Esta sección debe también tener la opción server-id=master_id , donde master_id debe ser un entero positivo de 1 a 2^32 - 1. Por ejemplo:

[mysqld]

log-bin=mysql-bin

server-id=1

Si estas opciones no están presentes, añádalas y reinicie el servidor.

Pare el servidor que se vaya a usar como esclavo y añada lo siguiente a su fichero my.cnf :

[mysqld]

server-id=slave_id

El valor slave_id , como el valor master_id , debe ser un entero positivo de 1 a 2^32 - 1. Además, es muy importante que el ID del esclavo sea diferente del ID del maestro. Por ejemplo:

[mysqld]

server-id=2

1.    Si hace una copia de seguridad de los datos del maestro usando mysqldump, cargue el fichero de volcado en el esclavo:

shell> mysql -u root -p < dump_file.sql

2.    Ejecute los siguientes comandos en el esclavo, reemplazando los valores de opciones con los valores relevantes para su sistema:

3.    mysql> CHANGE MASTER TO

4.        ->     MASTER_HOST='master_host_name',

5.        ->     MASTER_USER='replication_user_name',

6.        ->     MASTER_PASSWORD='replication_password',

7.        ->     MASTER_LOG_FILE='recorded_log_file_name',

    ->     MASTER_LOG_POS=recorded_log_position;

La siguiente tabla muestra la longitud máxima para las opciones de cadenas de caracteres:

MASTER_HOST	60
MASTER_USER	16
MASTER_PASSWORD	32
MASTER_LOG_FILE	255

8.    Arranque el flujo esclavo:

mysql> START SLAVE;

Si olvida asignar un valor para server-id en el esclavo, obtiene el siguiente error en el log de errores:

Warning: You should set server-id to a non-0 value if master_host is set;

we will force server id to 2, but this MySQL server will not act as a slave.

También encuentra mensajes de error en el log de errores del esclavo si no es capaz de replicar por ninguna otra razón.