PLAN DE CONFIGURACIÓN Y RECUPERACIÓN ANTE

DESASTRES PARA EL SMBD

ALCALDIA DE SAN ANTONIO DEL SENA

Caso de Estudio #1

Aprendices: Mónica Lizeth Alape Rodríguez & Yenisse Pardo Ariza

Programa: (1881789) – Especialización Tecnológica Gestión y Seguridad de BD
Instructor Vocero: Candelaria Victoria Suarez Beleño
Instructor de Apoyo: Adriana Cristina Castilla López
Instructor de Apoyo de Ficha: Belkis Milena Guell Muñoz
Sede: Centro Nacional Colombo Alemán – SENA. Regional Atlántico
Fecha: 11 de agosto de 2019
 CONTENIDO
INTRODUCCIÓN .......................................................................................................................... 3
OBJETIVO GENERAL ................................................................................................................... 4
OBJETIVOS ESPECIFICOS ........................................................................................................... 4
DESCRIPCIÓN DEL PROBLEMA ................................................................................................. 5
PLAN DE RECUPERACION ANTE DESASTRES (DRP) PARA LOS SMBD (SQL Server 2014 y
ORACLE 11g) ............................................................................................................................... 6
RIESGOS ....................................................................................................................................... 7
IDENTIFICACIÓN Y ANALISIS DE AMENAZAS .......................................................................... 8
MODELO DE RECUPERACION SQL Server 2014 y ORACLE 11g ............................................. 9
TIPOS DE COPIA DE SEGURIDAD SQL Server 2014 y ORACLE 11g ..................................... 10
USUARIOS Y ENCARGADOS DE REALIZAR LAS COPIAS Y RECUPERACIÓN DE
INFORMACIÓN. ......................................................................................................................... 11
INSTANCIAS............................................................................................................................... 11
PASOS A RECUPERAR INFORMACIÓN POR DAÑOS EN EL SISTEMA POR PERSONAL O
DAÑOS EN EL SISTEMA. ........................................................................................................... 13
SISTEMA DE ALMACENAMIENTO............................................................................................ 13
 INTRODUCCIÓN

Teniendo en cuenta el Plan de Instalación Para El SMBD Ev. 3 - AA2, SMBD seleccionado
SQL Server 2014 y refiriéndonos también en este trabajo al SMBD ORACLE 11g;
señalamos que una base de datos no es algo sencillo como muchos piensan, logra ser
tan complejo que puede arruinarse y como resultado perder información que se
encontraba almacenada, perdiendo el trabajo de muchos días, meses o años.

Las bases de datos son sensibles y pueden sufrir en cualquier momento algún grado de
corrupción, pese a ello debemos tener mucho cuidado al utilizar herramientas de
recuperación, puesto que se pueden generar daños mayores.

Cada SMBD suministra herramientas que pueden impedir o corregir errores o fallos;
siempre que se quiera ejecutar alguna actualización debemos tener la certeza de que la
base de datos se encuentra en estado consistente, es decir, que no presente ningún
error.

Las bases de datos brindan ciertas posibilidades de respaldo y recuperación, dadas

mediante una configuración, la cual se basa en características de operatividad y de
disponibilidad, por otro lado, se deben tener presentes los requerimientos de las
entidades y áreas de la misma.
 OBJETIVO GENERAL

Elaborar un plan recuperación ante desastres de los SMBD seleccionados para la

Alcaldía de San Antonio del SENA.

OBJETIVOS ESPECIFICOS

֍ Elaborar un plan de recuperación de información ante posibles desastres

informáticos para los SMBD SQL Server 2014 y ORACLE 11g.
֍ Indicar los actores responsables del proceso de respaldo y recuperación ante los
posibles desastres.
֍ Elaborar un cronograma de respaldos para los SMBD seleccionados en este
documento.
 DESCRIPCIÓN DEL PROBLEMA

La Alcaldía objeto de estudio es una institución del estado colombiano, que realiza las
funciones de administración local en una población de este país. Esta Alcaldía está
presidida por el Alcalde elegido por votación popular, quien enfrenta una situación de
caos administrativo a causa de los malos manejos de la información y la inadecuada
utilización de tecnología para el apoyo a los procesos. El Alcalde de “San Antonio del
SENA”, convencido de poder mejorar la situación, presentó un proyecto de inclusión de
tecnología que le fue aprobado por el concejo y propende en realizar todas las mejoras
en las condiciones actuales de manejo de información de las diferentes dependencias y
secretarias de su actual administración.
Una mejora sensible, se da a través de una reingeniería de procesos enfocados en la
utilización de la información generada por las dependencias de la alcaldía, pensando en
optimizar los tiempos de respuesta y flujo de información para la toma de decisiones.

Adicional a esto el alcalde pretende tomar las medidas necesarias para respaldar la
información suministrada por cada dependencia, puesto que más allá de la calidad de
atención y mejorar las herramientas de trabajo a su personal, los datos suministrados
por las bases de datos son el trabajo de todos, mereciendo adaptar las medidas de
seguridad necesarias para el respaldo y recuperación ante posibles desastres humanos
o naturales.
 PLAN DE RECUPERACION ANTE DESASTRES (DRP) PARA
LOS SMBD (SQL Server 2014 y ORACLE 11g)

Un Plan de Recuperación de Desastres, DRP, por sus siglas en inglés, Disaster Recovery
Planning, se entiende como las acciones o prácticas efectivas de medidas de seguridad,
que garantizan una adecuada recuperación de la operatividad mínima de los sistemas
luego de una contingencia o desastre, en la que se vean afectados los procesos y
recursos informáticos que soportan un negocio.

La implementación de un DRP representa para una empresa múltiples beneficios

reflejados en la reducción de costos, disminución de tiempos de inactividad de los
sistemas de información, el respaldo y control de la información existente en las
diferentes aplicaciones y el entrenamiento del personal.

Los desastres a los que se ven expuestos los sistemas informáticos pueden ser de
diversos tipos y así mismo su impacto a nivel físico puede variar. A continuación,
algunos desastres que pueden afectar a una organización:

 Incendios.  Fallas de energía.

 Inundaciones.  Fallas de servicios públicos.

 Huracanes.  Pandemias.

 Tormentas severas.  Sabotaje.

 Deslizamientos de tierra.  Huelgas y paros laborales.

 Tsunamis.  Disturbios Cívicos.

 Terremotos.  Terrorismo.

 Volcanes.  Guerra.

 Incidentes de seguridad.

 Falla de equipamiento.
Los desastres naturales son imposibles de predecir y mucho menos de contener, estos
eventos normalmente presentan daños graves en edificios que impiden el acceso a los
mismos, además de los efectos que causa en los trabajadores debido a las potenciales
pérdidas humanas causadas por el desastre.

Un desastre puede afectar los sistemas de telecomunicación, lo que puede dejar a una
empresa totalmente aislada de proveedores, contratistas y de sus clientes.

RIESGOS
Existen diferentes tipos de riesgos el cual pueden afectar nuestros recursos,
datos/información de nuestra empresa, se debe tener las medidas necesarias para que
no se presenten fallas o errores.
Se identifican los siguientes riesgos:

1. Personal: Ingreso de personal no autorizado a nuestra red, computadoras por

ello se deben crear los diferentes usuarios con contraseña dependiendo su rol,
esto asignando las restricciones necesarias por el administrador de la base de
datos.
2. Hardware: Los equipos deben estar ubicados en zona independientes de las
oficinas, que no estén expuestos al agua, sol, deben contar con buen sistema de
refrigeración y control de personal no autorizado.
3. Software: los programas deben estar licenciados, los equipos protegidos con el
firewall.
4. Datos e información: Deben estar almacenados de formas organizada, con la
restricción de acceso no autorizado.
5. Documentación: la documentación manejada en físico debe ser almacenada en
sitios adecuados, libres de humedad, sol, e igual se deben digitalizar y guardar.
6. Suministro de energía eléctrica: Todos los equipos y distribución de canales
de electricidad deben estar con conectados a una red regulada, la cual servirá
para daños en la luz eléctrica, además estos no pueden pasar el máximo de
amperios.
IDENTIFICACIÓN Y ANALISIS DE AMENAZAS
Para la realización de este punto utilizamos la metodología Magerit 3.0. Partiendo de
allí debemos tener en cuenta que es algo que le puede pasar a los activos sin animosidad
o deliberadamente; es decir, se pueden dar hasta 3 combinaciones:
 Amenazas que sólo pueden ser errores, nunca ataques deliberados.
 Amenazas que nunca son errores, siempre son ataques deliberados.
 Amenazas que pueden producirse tanto por error como deliberadamente
Para afrontar esta casuística, errores y amenazas se han numerado de tal manera
que pueda establecerse este paralelismo. La siguiente tabla (Magerit 3.0) alinea
errores con ataques mostrando cómo se correlacionan:
N° ERROR ATAQUE
1 Errores de los usuarios
2 Errores del administrador
3 Errores de monitorización (log) Manipulación de los registros de actividad
4 Errores de configuración Manipulación de la configuración
5 Suplantación de la identidad del usuario
6 Abuso de privilegios de acceso
7 Deficiencias en la organización Uso no previsto
8 Difusión de software dañino Difusión de software dañino
9 Errores de [re-]encaminamiento [Re-]encaminamiento de mensajes
10 Errores de secuencia Alteración de secuencia
11 Acceso no autorizado
12 Análisis de tráfico
13 Repudio
14 Escapes de información Interceptación de información (escucha)
15 Alteración accidental de la información Modificación deliberada de la información
16 Destrucción de información Destrucción de información
17 Fugas de información Revelación de información
18 Vulnerabilidades de los programas
(software)
Errores de mantenimiento / actualización
19
de programas (software)
20 Manipulación de programas
21 Errores de mantenimiento / actualización Manipulación de los equipos
de equipos (hardware)
22 Caída del sistema por agotamiento de Denegación de servicio
recursos
23 Pérdida de equipos Robo
24 Ataque destructivo
25 Ocupación enemiga
26 Indisponibilidad del personal Indisponibilidad del personal
27 Extorsión
28 Ingeniería social (picaresca)
MODELO DE RECUPERACION SQL Server 2014 y ORACLE 11g

SQL Server 2014

1. Después de conectarse a la instancia apropiada de Motor de base de datos de

SQL Server, en el Explorador de objetos, haga clic en el nombre del servidor para
expandir el árbol de servidores.

2. Expanda Bases de datos y 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 y haga clic en Propiedades, lo
que abre el cuadro de diálogo Propiedades de la base de datos.

4. En el panel Seleccionar una página, haga clic en Opciones.

5. El modelo de recuperación actual se muestra en el cuadro de lista Modelo de

recuperación.

6. Si lo desea, también puede seleccionar otra lista de modelos para cambiar el

modelo de recuperación. Las opciones son Completa, Registro masivo o Simple.

7. Haga clic en Aceptar.

ORACLE 11g

1. Se presume que se tiene una instancia de Oracle (cdb1). Ejecutamos el

superusuario Oracle (raíz) e inicializamos el agente de escucha.

2. (Opcional) Aseguramos de que la base de datos esta en modo de registro de

archivo.

$ sqlplus / as sysdba
SQL> SELECT log_mode FROM v$database;
LOG_MODE
------------
NOARCHIVELOG
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;
SQL> ALTER SYSTEM SWITCH LOGFILE;
3. Compruebe o cambie la ubicacion y el tamaño del archive de copia de seguridad.
$ sqlplus / as sysdba
SQL> show parameter db_recovery
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string /u01/app/oracle/fast_recovery_area
db_recovery_file_dest_size big integer 4560M
4. Use Oracle Recovery Manager (RMAN) para hacer una copia de seguridad de la
base de datos:
$ rman target /
RMAN> backup database plus archivelog;

TIPOS DE COPIA DE SEGURIDAD SQL Server 2014 y ORACLE

11g
TIPO COPIA DE DISPONIBLE EN: RESTRICCIONES
SEGURIDAD
COMPLETO Bases de datos, archivos y En la base de datos
grupos de archivos muestra, solo son posibles
copias de seguridad
completas. En el modelo
de recuperación simple,
las copias de seguridad de
archivos y grupos de
archivos solo están
disponibles para los
grupos de archivos de solo
lectura.
 DIFERENCIAL Bases de datos, archivos y En el modelo de
grupos de archivos recuperación simple, las
copias de seguridad de
archivos y grupos de
archivos solo están
disponibles para los
grupos de archivos de solo
lectura.
REGISTRO DE Registros de transacciones Las copias de seguridad de
TRANSACCIONES registros de transacciones
no están disponibles para
el modelo de recuperación
simple.

USUARIOS Y ENCARGADOS DE REALIZAR LAS COPIAS Y

RECUPERACIÓN DE INFORMACIÓN.
Se crean los usuarios para manejar la seguridad de la información, para que personal
no autorizado no pueda acceder a ellos o cometer errores en la información. Se definen
así:
PLANTA: estos dependiendo de la dependencia que manejen y su respectiva base de
datos, podrá registrar, actualizar, descargar, generar informes. No tendrá permiso para
eliminar información.
ADMINISTRADOR: Él se encargará de toda la gestión, configuración, asignación de
usuarios, contraseñas, podrá crear, ingresar, modificar, actualizar, eliminar, realizar
copias de respaldo, encargado de la recuperación de la información ante desastres.

INSTANCIAS
El sistema manejador de base de datos ORACLE Y SQL SERVER serán instalados en el
servidor, con su respectiva base de datos, se instalará en cada equipo de cómputo las
instancias para que puedan acceder a la base de datos del servidor. A continuación,
veremos cómo funciona las instancias según SMBD.
Instancias en SQLServer.
Cada vez que se instala el motor de base de datos SQL Server, se materializa en un
Servicio sobre el Sistema Operativo, éste servicio ejecuta un proceso denominado
“sqlserver.exe” con su propia configuración y bases de datos (las del Sistema y la(s) del
usuario). Además, pueden ser instaladas varias instancias del servidor en un mismo
equipo. Debido a lo anterior, aun cuando cada base de datos tiene sus propios archivos
(para almacenar sus objetos: tablas, índices, vistas procedimientos almacenados, etc.),
sus archivos de registro de transacciones (Log), configuración y modo de registro,
comparten elementos dentro de la misma instancia como la base de datos Temp (para
operaciones temporales) y los demás recursos definidos como memoria, procesador,
conectividad, etc.
A nivel de administración, la utilización de múltiples instancias o múltiples bases de
datos cuando se tiene un único servidor, puede tener diferentes aspectos a analizar:
 Varias instancias pueden entrar en conflicto por la utilización de recursos
(memoria, acceso a disco y procesador).
 Las tareas de administración como copias de seguridad y mantenimiento se
simplifican.
 Si se tienen entornos de ciclo de vida (producción, desarrollo, pruebas, etc.) es
mejor tenerlos en instancias separadas. Sin embargo, se debe tener en cuenta
que los nombres de base de datos deben ser únicos y se debería adoptar alguna
estrategia en particular.

Instancias en Oracle
En Oracle un usuario accede a una base de datos a través de una instancia, no lo hacen
directamente, es decir que la instancia está formada por memoria y procesos que
ejecuta el servidor.
Las operaciones de lectura o escritura no se realizan directamente sobre los datos, sino
que se hacen a través de la instancia. Una base de datos puede ser abierta por varias
instancias, el sistema entonces asigna los buffers de memoria y una serie de procesos
en background son iniciados. Lo anterior significa que la capacidad de memoria del
servidor determinará la cantidad de instancias de una base de datos que se puede tener.
Los parámetros que determinan estos tamaños se encuentran en un archivo de
configuración, este se lee al iniciar la instancia, pero puede ser modificado para
posteriores inicializaciones de la base de datos.
El proceso tiene las siguientes fases:
 Iniciación. Es cuando se reserva en la memoria el espacio necesario para la
instancia y se activan los procesos necesarios para el funcionamiento de la
instancia.
 Montar la Base de Datos. Aquí se leen los archivos de control que contienen la
información de la ubicación de los archivos que componen la Base de Datos. En
esta fase se pueden realizar tareas de mantenimiento.
 Abrir la Base de Datos. Los datos quedan disponibles para su procesamiento

PASOS A RECUPERAR INFORMACIÓN POR DAÑOS EN EL

SISTEMA POR PERSONAL O DAÑOS EN EL SISTEMA.
1. Revisar qué tipo de daño ocurrió, si Hardware, Software o Base de datos.
2. Comunicar al área o personal encargado de su restauración.
3. Informar cuanto tiempo dura su recuperación.
4. En caso que sean daños en la información base de datos. Comunicar el
administrador de base de datos, restaurar el sistema con las copias de seguridad
realizadas.

SISTEMA DE ALMACENAMIENTO.
Se seleccionó por temas de funcionabilidad y eficiencia un Sistema de almacenamientos
SAN. Estas son sistemas dedicados de almacenamiento en red que acceden a los
recursos mediante conexiones directas entre el servidor y los dispositivos de
almacenamiento de manera que no causan impacto sobre la LAN
El alojamiento y compartición de archivos se realiza mediante un disco virtual que
conforman todos los dispositivos que pertenecen a la red y es en esté, donde la
información se consolida y se comparte entre los diferentes servidores. Un aspecto
importante de las SAN es que, al estar los datos distribuidos entre los dispositivos de la
red, estos tienen una alta disponibilidad y redundancia en caso de fallo en cualquier
componente del sistema.

DIAGRAMA FUNCIONABILIDAD DE UNA SAN