Opiniones, noticias y artículos de nuestro equipo

Entradas etiquetadas como ‘sql’

Backups 101: ¿Qué debemos tener en cuenta? Políticas, retención, storage, restauración y herramientas.

Las copias de seguridad de las plataformas son una parte esencial de la administración de sistemas. Es, por lo tanto, un tema ampliamente estudiado y para el que se han creado multitud de herramientas. Sin embargo, realizar buenos backups sigue siendo una tarea compleja en la que interviene la definición de la política, el estudio y la elección de la(s) herramienta(s) y su implementación.

1 · Política de backups

La política de backups es la definición de los diferentes aspectos de las copias de seguridad: ¿de qué se debe hacer backup? ¿Cada cuánto se realiza la copia de seguridad? ¿Qué retención deben tener? ¿Dónde se guardan las copias? ¿Cuánto tiempo es aceptable que se pueda tardar en recuperar datos?

Obviamente, siempre es deseable tener copias diarias de todos los ficheros con una retención alta y almacén local para recuperar rápidamente, así como externo para mayor protección. Sin embargo, esto está reñido con la eficiencia y con los costes: robots de cintas, ocupación de disco, espacio físico para guardar las copias, etc. Por lo tanto, es necesario encontrar un compromiso marcando máximos en los costes, y priorizando los backups de los recursos más críticos.

Cada proyecto o plataforma tiene sus propias necesidades que es necesario definir para establecer la política. Para ello, es útil:

  • Diferenciar entre distintos entornos (preproducción, desarrollo, test, producción, etc.)
  • Determinar los costes de las posibles pérdidas de datos
  • El tiempo que se tardaría en la recuperación
  • Valorar los recursos disponibles (hardware, velocidad de la red, discos remotos, etc.)
  • Analizar qué es imprescindible copiar y qué no.

2 · Guardado y retención de backups

Un aspecto importante de seguridad a la hora de establecer una política de backups es dónde se van a guardar las copias de seguridad. Cuando se definen planes de prevención de riesgos en cuanto a tecnología se suele considerar el vaulting para mitigar los efectos de un posible incidente en el site donde se realizan los backups. Esta practica consiste en mover a otra localización periódicamente una copia completa de los datos, por ejemplo una vez al mes. Esto es habitual cuando el soporte físico es en cinta.

Esto es distinto del archiving, que consiste en mover datos antiguos que no se están utilizando a una localización distinta. Un backup es siempre una copia, mientras que el archiving consta de los datos originales que son trasladados porque no se utilizan pero no se quieren eliminar definitivamente.

Aunque hay diversas opciones de storage es interesante considerar el servicio Glacier de Amazon. Su bajo coste es una gran ventaja, pero el hecho que la restauración no esté asegurada en un tiempo concreto y que pueda tardar algunas horas lo descarta para el vaulting mientras que lo convierte en interesante candidato para archiving, donde no hay exigencias de recuperación de datos en tiempos limitados.

3 · Restauración

El objetivo final de un backup es poder restaurarlo en caso de pérdida de los datos. Por lo tanto, tener presente la restauración a la hora de definir una política de backups o escoger una herramienta es clave. Para ello, es importante haber decidido previamente (en la gestión de riesgos) los siguientes puntos:

  • RTO (Recovery Time Objective)
    Es el tiempo máximo en el que se debe alcanzar un nivel de servicio mínimo tras una caída del servicio (por ejemplo, debido a pérdida de datos) para no causar consecuencias inaceptables en el negocio.
  • RPO (Recovery Point Objective)
    Es el periodo de tiempo máximo en el que se pueden perder datos de un servicio. Si el periodo de tiempo es de 6 horas, se deben realizar backups cada menos tiempo y poder recuperar la información antes de agotar el periodo.

El tiempo de restauración de un backup en caso de pérdida de datos forma parte del tiempo en que no hay servicio, por lo que cuanto menos tarde antes se restablecerá el proceso de negocio.

4 · Herramientas

Las herramientas nos permiten implementar la política de backup. Dada la variedad de plataformas, se han creado muchísimas herramientas que actúan a diferentes niveles. Algunos tipos de backups y herramientas (hay muchos más) se muestran a continuación:

4.1 · Sincronización

Este tipo de backup permite que dos directorios en localizaciones distintas (en la misma máquina o en hosts separados) contengan los mismos ficheros. Muchas de las herramientas que permiten la sincronización se basan en rsync o en su librería.

  • Rsync: la herramienta más conocida de sincronización de ficheros, tiene muchas opciones que dan gran flexibilidad.
  • Duplicity: se basa en la librería de rsync para realizar backups de ficheros comprimidos y encriptados.
  • Unison: permite la sincronización de directorios aprovechando características de distintos sistemas y herramientas.

4.2 · Copias

El sistema básico de realizar backups es la copia de los ficheros a un espacio aparte. En este caso, se pueden utilizar herramientas de un gran rango de diversidad y complejidad.

  • fwbackups: herramienta con una interfaz simple pero con muchas opciones, permite programar backups a distintos niveles.
  • Bacula: herramienta muy completa que permite realizar backups de varios niveles (total, diferencial, incremental), de distintos clientes (linux, solaris, windows) y a diversos soportes (cinta y disco). Es software libre aunque tiene opción de soporte comercial.
  • Mondorescue: este software permite realizar backup de una instalación entera, y puede dejar las copias en numerosos soportes físicos.

4.3 · Bases de datos

Las bases de datos piden un trato especial. Guardar los ficheros que contienen las bases de datos no suele ser un buen sistema de backup, ya que una copia del fichero en un momento cualquiera puede generar una base de datos inconsistente. Por ello, cada servidor suele proporcionar un sistema de copias de seguridad, a menudo basadas en volcados de datos en distintos formatos.

  • MySQL: mysqldump realiza un volcado en los datos de la base de datos en SQL. Esto permite realizar backups y crear esclavos entre otros usos.
  • PostgreSQL: pg_dump hace, igual que mysqldump, un volcado de los datos en lenguage SQL.
  • SQL Server: el servidor de bases de datos de Microsoft ofrece la utilidad SQL Server Management Studio que permite programar las distintas tareas de backups, además de tareas previas y posteriores, especificando cuándo, de qué y a qué nivel se realiza la copia de seguridad de forma que sea consistente y fácilmente recuperable.

4.4 · Snapshots

Los snapshots son “fotografías” del sistema o de una parte que permiten recuperarlo en un estado que se sabe que es correcto. Los snapshots se pueden realizar a distintos niveles:

  • Sistema de ficheros: hay sistemas de ficheros que permiten realizar backups en forma de snapshots. ZFS dispone de esta utilidad.
  • Volúmen de disco: LVM ofrece esta posibilidad para recuperar volúmenes.
  • Máquinas virtuales: muchos gestores de máquinas virtuales permiten realizar snapshots de las mismas. KVM, Xen o VMWare entre otros disponen de esta característica.
  • Ficheros: con rsnapshot se pueden realizar backups en forma de snapshot aprovechando el rsync y mediante hardlinks de forma transparente. Back In Time también realiza snapshots de directorios, aunque únicamente para entornos de escritorio.

4.5 · Continuous Data Protection

Consiste en guardar automáticamente una copia de todos los cambios realizados en los datos, adquiriendo una copia remota de todas las versiones. Esto permite realizar recuperación de los datos de cualquier momento. Aunque hay sistemas optimizados para guardar únicamente las diferencias y ocupar poco espacio en disco, este sistema tiene penalizaciones en la red dada la continua transferencia de datos.

  • AIMstor: permite definir fácilmente políticas mediante una interfaz gráfica y soporta distintos tipus de backup, replicación y archiving.
  • RecoverPoint: soporta replicación remota de datos mediante protocolos síncronos y asíncronos.
  • InMage DR-Scout: tiene un repositorio de capacidad optimizada y soporta diversas plataformas (Windows, Linux, Solaris,…).

5 · A tener en cuenta

Con la infinidad de herramientas disponibles, la elección puede ser complicada. Para simplificar la búsqueda y reducir las opciones, es imprescindible definir las necesidades propias y lo que ofrecen las soluciones para encontrar la herramienta que mejor las cubra. Algunas cuestiones que pueden ayudar en la elección de una herramienta son las siguientes:

  • Instalación: ¿Está paquetizada o es necesario compilar? ¿Es fácil de instalar? ¿Tiene requerimientos especiales?
  • Configuración y mantenimiento: ¿Es fácil de mantener? ¿Es capaz de implementar la política? ¿Cuánto tiempo de aprendizaje requiere? ¿Tiene interfaz gráfica?
  • Restauración: ¿La restauración es fácil y rápida? ¿Puede un usuario restaurar un fichero suyo o debe ser siempre el administrador?
  • Compatibilidad: ¿Sirve para todos los sistemas de la plataforma? ¿El servidor debe correr en un sistema concreto?
  • Soporte físico: ¿Permite backup a cinta, DVD, sistemas de ficheros remotos, disco…?
  • Licencia: ¿Es software libre o comercial? ¿Dispone de soporte para empresas?

6 · Conclusiones

La variedad de opciones permiten definir ampliamente la política de backups de forma que se pueda utilizar una o varias herramientas para la misma plataforma, así como distintos niveles y retenciones para distintos ficheros. A menudo no hay una solución única y fija, y raramente la misma política sirve para dos plataformas diferentes.

Aunque es recomendable ser flexible para los pequeños cambios (la política o los recursos pueden sufrir modificaciones), realizar grandes cambios en el sistema de backups puede ser complejo, por lo que es importante realizar un buen estudio para escoger la mejor opción. La clave se encuentra en definir y cubrir las necesidades de cada plataforma ajustando el sistema a los recursos disponibles.

Sobre la autora

Foto de perfil de Alba Ferrer, Systems Engineer en CAPSiDE

Alba Ferrer es Ingeniera Informática por la Facultad de Informática de Barcelona (FIB/UPC) y Georgia Tech (USA), y Administradora de Sistemas (SysAdmin) en CAPSiDE. Activa dentro de la comunidad Perl de Barcelona y del grupo Sudoers de Barcelona. Miembro de las comunidades de Software Libre de Ubuntu (ubuntu.cat) y Caliu. Puedes seguir aquí sus tweets.

¿Cómo conectar a un mirror server después de un failover en DB Mirroring de Microsoft SQL Server?

DB Mirroring copia todos los objetos de la base de datos del servidor principal al mirror server (servidor espejo o replicado).
De todos modos, esto no copia los inicios de sesión (o logins) del servidor principal al mirror o espejo, y esto comporta que después del failover no se pueda conectar a la base de datos del mirror server.

Para resolver este problema necesitamos conocer el SID del login en el servidor principal.
Cuando sepamos el SID del login, podemos crear un nuevo login en el mirror server utilizando este SID.

Para conocer el SID del login del server principal debemos ejecutar la siguiente sentencia en el servidor principal:

SELECT sid  FROM sys.server_principals where name = ‘<LoginName>’

Para crear el login en el mirror server utilizando el SID del servidor principal, podemos ejecutar la siguiente sentencia en el servidor espejo (mirror server):

CREATE LOGIN <LoginName> WITH PASSWORD = ‘<Paswword>’ sid = <sid for same login on principal server>

Recuerde que el <LoginName>, el <Password> y el <SID de login en el servidor principal> deben ser exactamente los mismos en ambos servidores: principal (main) y espejo (mirror).

Finalmente se debe cambiar la cadena de conexión de la aplicación incluyendo el parámetro de “failover partner”:

Data Source=myServerAddress;
Failover Partner=myMirrorServerAddress;

Initial Catalog=myDataBase;
User Id=sqluser;
Password=sqlpassword;

Sobre el autor

Toni Planas - Systems Engineer at CAPSiDE

Toni Planas es Ingeniero de Sistemas y forma parte del equipo de especialistas de CAPSiDE. A lo largo de su carrera profesional se ha convertido en especialista de tecnologías y soluciones de Microsoft, centrándose sobretodo en lo referente a Sistemas Operativos, Bases de Datos SQL Server y Soluciones de Correo/Mensajería.

¿Cómo hacer DB Mirroring utilizando certificados? (SQL Server 2008 R2)

A continuación facilitamos un método de puesta a punto de Mirroring de Base de Datos en SQL Server 2008 R2.
Las sentencias a ejecutar se encuentran organizadas por orden secuencial (o cronológico) de ejecución y clasificadas entre el servidor principal (o máster) y el de mirroring (o “reflejo de Base de Datos”).

Siguiendo los pasos estipulados en la tabla siguiente podrá configurar un sistema de DB Mirroring de SQL Server 2008 (R2).
Tenga en cuenta que es probable que su instalación de SQL Server o que su Base de Datos difiera del sistema estándar que comentamos. Recomendamos primero que comprenda el porqué de todos los pasos explicados a continuación y luego los aplique bajo su criterio según los requisitos de sus sistemas.

Principal
Mirror
Prepare instances
Create database
master key, if needed
USE master
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘<strong password>’
GO
USE master
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘<strong password>’
GO
If you want or
need  to delete the data base master key
USE master
GO
DROP MASTER KEY
GO
USE master
GO
DROP MASTER KEY
GO
Make certificates
USE master
GO
CREATE CERTIFICATE LAB_SRV1_cert
       WITH SUBJECT
= ‘LAB-SRV1
certificate’
GO
USE master
GO
CREATE CERTIFICATE LAB_SRV2_cert
       WITH SUBJECT
= ‘LAB-SRV2
certificate’
GO
If you want or need to
delete certificates
USE master
GO
DROP CERTIFICATE LAB_SRV1_cert
GO
USE master
GO
DROP CERTIFICATE LAB_SRV2_cert
GO
Create mirroring
endpoint
USE master
GO
CREATE ENDPOINT Endpoint_Mirroring

STATE =
STARTED

AS TCP (
      LISTENER_PORT=5022
      , LISTENER_IP = ALL

)

FOR DATABASE_MIRRORING(
      AUTHENTICATION
= CERTIFICATE
LAB_SRV1_cert
      , ENCRYPTION = REQUIRED ALGORITHM
AES
      , ROLE = ALL

)
GO
USE master
GO
CREATE ENDPOINT Endpoint_Mirroring

STATE =
STARTED

AS TCP (
      LISTENER_PORT=5022
      , LISTENER_IP = ALL

)

FOR DATABASE_MIRRORING(
      AUTHENTICATION
= CERTIFICATE
LAB_SRV2_cert
      , ENCRYPTION = REQUIRED ALGORITHM
AES
      , ROLE = ALL

)
GO
If you want or need to delete endpoint
USE master
GO
DROP ENDPOINT [Endpoint_Mirroring]
GO
USE master
GO
DROP ENDPOINT [Endpoint_Mirroring]
GO
Backup certificates
USE master
GO
BACKUP CERTIFICATE LAB_SRV1_cert

TO FILE
= ‘C:\BACKUPS\LAB_SRV1_cert.cer’
GO
USE master
GO
BACKUP CERTIFICATE LAB_SRV2_cert

TO FILE
= ‘C:\BACKUPS\LAB_SRV2_cert.cer’
GO
Copy certificates
between instances
Use any secure copy method
Use any secure copy method
Configure inbound connections
Create logins
USE master
GO
CREATE LOGIN LAB_SRV2_login

WITH PASSWORD
= ‘<strong
password>’
GO
USE master
GO
CREATE LOGIN LAB_SRV1_login

WITH PASSWORD
= ‘<strong password>’
GO
Create user for
login
USE master
GO
CREATE USER LAB_SRV2_user FOR
LOGIN LAB_SRV2_login
GO
USE master
GO
CREATE USER LAB_SRV1_user FOR
LOGIN LAB_SRV1_login
GO
Associate the
certificate with the user
USE master
GO
CREATE CERTIFICATE LAB_SRV2_cert
   AUTHORIZATION LAB_SRV2_user
   FROM FILE
= ‘C:\BACKUPS\LAB_SRV2_cert.cer’
GO
USE master
GO
CREATE CERTIFICATE LAB_SRV1_cert
   AUTHORIZATION LAB_SRV1_user
   FROM FILE
= ‘C:\BACKUPS\LAB_SRV1_cert.cer’
GO
Grant CONNECT
permission at login for the remote mirroring endpoint
USE master
GO
GRANT CONNECT

ON ENDPOINT::Endpoint_Mirroring TO
[LAB_SRV2_login]
GO
USE master
GO
GRANT CONNECT

ON ENDPOINT::Endpoint_Mirroring TO
[LAB_SRV1_login]
GO
Prepare database
Create database
CREATE DATABASE [DBMTest] ON  PRIMARY
 (NAME =
N’DBMTest’,
   FILENAME = N’C:\MSSQL\DATA\DBMTest.mdf’)
LOG ON
 (NAME =
N’DBMTest_log’            ,
   FILENAME = N’C:\MSSQL\DATA\DBMTest_log.ldf’)
GO
USE [DBMTest]
GO
CREATE TABLE [dbo].[TTest](

[ID] [int] IDENTITY(1,1) NOT NULL,

[DayAndTime] [datetime] NOT NULL
)
GO
Backup database
BACKUP DATABASE [DBMTest]

TO
DISK =
N’C:\BACKUPS\DBMTest.bak’
   WITH NOFORMAT,
   INIT, 

NAME = N’DBMTest-Full
Database Backup’
,
   SKIP,
   NOREWIND,
   NOUNLOAD, 
   STATS =
10
GO
Backup transaction
log
BACKUP LOG [DBMTest]
   TO DISK = N’C:\BACKUPS\DBMTest_log.bak’
   WITH NOFORMAT,
   INIT, 

NAME = N’DBMTest-Transaction
Log  Backup’
,
   SKIP,
   NOREWIND,
   NOUNLOAD, 

STATS =
10
GO
Restore database
RESTORE DATABASE [DBMTest]
   FROM
DISK =
N’C:\BACKUPS\DBMTest.bak’
   WITH
FILE =
1, 
   MOVE N’DBMTest_log’
TO N’C:\MSSQL\DATA\DBMTest.ldf’,
   NORECOVERY,

NOUNLOAD, 

STATS =
10
GO
Restore transaction
log
RESTORE LOG [DBMTest]

FROM
DISK =
N’C:\BACKUPS\DBMTest_log.bak’
   WITH
FILE =
1, 
   NORECOVERY, 
   NOUNLOAD, 
   STATS =
10
GO
Configure the mirroring
partners and start mirroring
First, on the mirror
instance
ALTER DATABASE DBMTest

SET PARTNER
= ‘TCP://LAB-SRV1:5022′
GO
And then, on
the principal instance
ALTER DATABASE DBMTest

SET PARTNER
= ‘TCP://LAB-SRV2:5022′
GO
Configure performance
and safety mode
High performance (asynchronous
mode)
ALTER DATABASE DBMTest SET
PARTNER SAFETY
OFF
GO
High safety
(synchronous mode)
ALTER DATABASE DBMTest SET
PARTNER SAFETY
FULL
GO
Managing database
mirroring
Pause mirroring
ALTER DATABASE DBMTest SET PARTNER SUSPEND
Resume mirroring
ALTER DATABASE DBMTest SET PARTNER RESUME
Manual failover (asynchronous
mode)
ALTERDATABASE DBMTest SET SAFETY FULL
GO
ALTERDATABASE DBMTest SET PARTNER FAILOVER
GO
ALTERDATABASE DBMTest SET SAFETY FULL
GO
Manual failover
(synchronous mode)
ALTERDATABASE DBMTest SET PARTNER FAILOVER
GO
Remove database mirroring
ALTER DATABASE DBMTest SET PARTNER OFF

Sobre el autor

Toni Planas - Systems Engineer at CAPSiDE

Toni Planas es Ingeniero de Sistemas y forma parte del equipo de especialistas de CAPSiDE. A lo largo de su carrera profesional se ha convertido en especialista de tecnologías y soluciones de Microsoft, centrándose sobretodo en lo referente a Sistemas Operativos, Bases de Datos SQL Server y Soluciones de Correo/Mensajería.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.