procedimiento de respaldos. wds
DESCRIPTION
Procedimiento de gestión de respaldos de WDSTRANSCRIPT
PROCEDIMIENTO
GESTIÓN DE RESPALDOS
PROCEDIMIENTO DE GESTION DE RESPALDOS WDS
Control del documento
Título: Procedimiento de Gestión de Respaldos.
Versión: 1.0
Nombre Cargo
Elaborado por Msc. Mabel Medina Arquitecta de Datos
Revisado por Msc. Rene Lazo Ochoa Gerente de producción
Aprobado por Firma
Cargo Msc. Rene Lazo Ochos Fecha 5/08/2014
Reglas de confidencialidad
Clasificación: Uso Interno
Forma de distribución: Documento
Este documento contiene información propietaria de WDS y es emitido confidencialmente para
un propósito específico.
El que recibe el documento asume la custodia y control, comprometiéndose a no reproducir,
divulgar, difundir o de cualquier manera hacer de conocimientos público su contenido, excepto
para cumplir el propósito para el cual se ha generado.
Las reglas son aplicables a todas las páginas de este documento.
Control de cambios
Versión Tipo** Fecha Autor Descripción
1.0 Alta 20/12/2013 Msc. Mabel MedinaRodriguez Creación del documento
PROCEDIMIENTO DE GESTION DE RESPALDOS WDS
1.1 Media 17/05/2014 Msc. Mabel MedinaRodriguez
Ajustes en el proceso de generación automática del
backup
1.2 Alto 5/08/2014 Msc. Mabel MedinaRodriguez
Ajustes generales en el procedimiento, inclusión delos desarrollos de vnz
PROCEDIMIENTO DE GESTION DE RESPALDOS WDS
Procedimientos para la Gestión de Respaldos Fuentes de respaldos, soporte tecnológico, frecuencia y responsabilidades La gestión de respaldos de la organización WDS en su proceso productivo está encaminado a salvaguardar los activos de produccin tantos internos como externos que permiten la construcción, mantenimiento, soporte y evolución de sus desarrollos internos y externos. Este procedimiento aplica como plantilla de uso metodológico a todos los proyectos y desarrollos que la organización enfrente. Las fuentes de información a respaldar clasifican según la siguiente tabla:
Fuentes Soporte Frecuencia Responsable de auditar el proceso
Automático Tiempo restauración
Códigos Fuentes
Repositorio GIT, bitbucket.org y git local server WDS, Disco Externo 2 T WDS
Diario. 10 pm
Msc. Axel Mendoza Pupo. Arquitecto de infraestructura
Si Instantáneo, mediante un clone al repo bare persistido. Caso crítico <= 1 hora
Base documental de la empresa
Repositorio GIT, Google Drive corporativo ( bitbucket.org y git local server WDS), Disco Externo 2 T WDS
Diario. 10 pm
Msc. Axel Mendoza Pupo. Arquitecto de infraestructura Msc. Rene Lazo Ochoa. Gerente de Producción
Si Instantáneo, mediante un clone al repo bare persistido. Caso crítico <= 4 hora
Base document
Repositorio GIT (
Diario. 10 pm
Msc. Axel Mendoza Pupo.
Si Instantáneo, mediante un
PROCEDIMIENTO DE GESTION DE RESPALDOS WDS
al de proyectos
bitbucket.org y git local server WDS), Disco Externo 2 T WDS
Arquitecto de infraestructura Msc. Rene Lazo Ochoa. Gerente de Producción
clone al repo bare persistido. Caso crítico <= 4 hora
Bases de datos estándar <= 1 T
Directorio /btrfs/backups/pg/ de server WDS de Oficina de gerencia matriz, Disco Externo 2 T WDS
Diario, 2:15 am
Msc. Mabel Medina Rodríguez. Arquitecto de datos
Si 12 horas
Bases de datos MegaDataBase >=1 T
Directorio /btrfs/backups/pg/ de server WDS de Oficina de gerencia matriz, Disco Externo 2 T WDS
Mensual. 25 de cada mes, 2:15 am
Msc. Mabel Medina Rodríguez. Arquitecto de datos
Si 96 horas
Son responsables del proceso del monitoreo y configuración de los mecanismos de respaldo y restauración del sistema los siguientes especialista según su responsabilidad y rol dentro de la organización:
Fuente Responsable de configurar y ejecutar la salva y restauración
Responsable de auditar la salva
Códigos Fuentes Msc. Axel Mendoza Pupo.Msc. Arquitecto de infraestructura. Contactos: Correo <[email protected]>. Celular 0984839304
Msc. Rene Lazo Ochoa. Gerente de producción. Contactos: Correo <[email protected]>, <[email protected]>.
PROCEDIMIENTO DE GESTION DE RESPALDOS WDS
Celular 0998258594
Base documental de la empresa
Msc. Axel Mendoza Pupo.Msc. Arquitecto de infraestructura. Contactos: Correo <[email protected]>. Celular 0984839304
Msc. Rene Lazo Ochoa. Gerente de producción. Contactos: Correo <[email protected]>, <[email protected]>. Celular 0998258594
Base documental de proyectos
Msc. Axel Mendoza Pupo.Msc. Arquitecto de infraestructura. Contactos: Correo <[email protected]>. Celular 0984839304
Msc. Rene Lazo Ochoa. Gerente de producción. Contactos: Correo <[email protected]>, <[email protected]>. Celular 0998258594
Bases de datos estándar <= 1 T
Msc. Mabel Medina Rodríguez Arquitecto de datos. Contactos: Correo <[email protected]>. Celular 0984467666
Msc. Rene Lazo Ochoa. Gerente de producción. Contactos: Correo <[email protected]>, <[email protected]>. Celular 0998258594
Bases de datos MegaDataBase >=1 T
Msc. Mabel Medina Rodríguez Arquitecto de datos. Contactos: Correo <[email protected]>. Celular 0984467666
Msc. Rene Lazo Ochoa. Gerente de producción. Contactos: Correo <[email protected]>, <[email protected]>. Celular 0998258594
Procedimiento ante incidencias de respaldo y demanda de restauración Ante la aparición de una incidencia en que impacte en las fuentes de información en sus diferentes regímenes de explotación, ya sea desarrollo, producción o pruebas, la persona que
PROCEDIMIENTO DE GESTION DE RESPALDOS WDS
detecta la incidencia notifica la misma a través de la instancia de jira en el proyecto WDSProduccion, tipeando la issue como tarea y asignando componente respaldo, definiendo como responsable el especialista que es definido en el procedimiento como responsable del tipo de fuente de información. url del proyecto wdsproduccin: https://wdsoltic.atlassian.net/browse/WDSPROD/?selectedTab=com.atlassian.jira.jiraprojectsplugin:issuespanel
Paso 1. Crear la incidencia y definir el tipo Tarea.
PROCEDIMIENTO DE GESTION DE RESPALDOS WDS
Paso 2. Definir el componente, describir la incidencia y asignar el responsable Posterior al registro de la incidencia la plataforma jira notifica vía correo electrónico al responsable, el que a partir de esta entrada, debe aplicar el procedimiento descrito y termina resolviendo la issue, asignando la issue nuevamente a la persona que registra la issues, con este paso la plataforma jira vuelve a enviar un correo electrónico en este caso a la persona que le fue reasignada la issue en estado resuelta, para que este verifique la correcta recuperación cerrando la issue.
Paso 3. Resolviendo la incidencia de soporte asociado a respaldo
PROCEDIMIENTO DE GESTION DE RESPALDOS WDS
Paso 4. Cerrando la incidencia una vez confirmado que se restauró la fuente de información y por tanto la incidencia debe ser resuelta
Infraestructura tecnológica y procedimental para la implementación de los mecanismos de respaldos y recuperación ante incidencias Relacionado con codigos fuentes Se utiliza como soporte tecnológico para la gestión de respaldos de codigos fuentes git (http://gitscm.com/) para el procesamiento de clone de los repos activos y fabric (http://www.fabfile.org/) con elq ue se implementa una solucin de despliegues automaticos que permite automatizar tareas y script preconfigurados. El servidor de WDS matriz, presenta una cofniguracin de tareas programadas, que llama instrucciones favdeploy que permiten diariamente conectarse a los repos corporativos de https://bitbucket.org/, y realizar un pull del remote correspondiente de cada repo que se determina incluir dentro del proceso de respaldos para codigos cuentes. El directorio en el Server de WDS matriz en el que serán clonados las salvas es: /opt/git/
PROCEDIMIENTO DE GESTION DE RESPALDOS WDS
Relacionado con base documental Se utiliza como soporte tecnológico para la gestión de respaldos documentales el git (http://gitscm.com/) para el procesamiento de clone de los repos documentales activos (aquellos nombrados con el formato soltrepo_doc) y fabric (http://www.fabfile.org/) con el que se implementa una solución de despliegues automáticos que permite automatizar tareas y script preconfigurados, ver repo (https://bitbucket.org/reymor/soltfabdeploy_src). El servidor de WDS matriz, presenta una configuración de tareas programadas, que llama instrucciones favdeploy que permiten diariamente conectarse a los repos corporativos de https://bitbucket.org/, y realizar un pull del remote correspondiente de cada repo que se determina incluir dentro del proceso de respaldos para códigos fuentes. El directorio en el Server de WDS matriz en el que serán clonados las salvas es: /opt/git/ Adicional a las salvas automáticas de los repositorios documentales de todos los proyectos, se instrumenta un entorno redundante de información con aquellos documentos administrativos y comerciales, ofertas técnicas, procedimientos, currículos, etc. En este caso además del repo wdsdocumental, se cuenta con un espacio en google drive, para el desarrollo y actualización colaborativa de materiales, así como un gestor documental corporativo basado en Plone. Estos materiales son actualizados al repo WDSdocumental, por el gerente corporativo de la empresa Msc Rene Lazo Ochoa. URLs Google drive: user: [email protected] pass: openerpquito2014 Gestor Documental: http://192.168.1.41:8080/Plone Otros espacios documentales para procedimientos: Portal corporativo WDS: https://wds.soltein.org
Relacionado con Bases de datos
Herramientas Como herramientas para el respaldo se tienen:
PROCEDIMIENTO DE GESTION DE RESPALDOS WDS
● pgpoolII versión 3.3.3: Middlewar que gestiona cluster de bases de datos, garantizando una alta disponibilidad a partir de ofrecer capacidades de balanceo de carga, un pool de conexiones, degeneración de un nodo caído (failover) y recuperación de nodos caídos replicación.
● Pg_dump: Herramienta de línea de comandos que permite hacer un respaldo de alguna de las bases de datos (o todas) en el servidor postgres. Permite hacer el volcado de datos en diferentes formatos ya sean comprimidos, texto plano, etc.
Procedimiento Como procedimiento de respaldo se implementarán tareas programadas en el sistema operativo de los servidores de postgres, que ejecutarán la herramienta pg_dump para respaldar la información de las bases de datos. El backup se ejecutará con una frecuencia específica para cada base de datos a respaldar, dependiendo de la periodicidad de cambio de los datos en las bases de datos de postgresql. Para el caso de la base de datos del sistema contenedora de los datos del negocio (RDC), la tarea programada que ejecutará el respaldo se ejecutará de forma diaria a las 2:15 am. Para la base de datos contenedora de los datos crediticios (RDI), la tarea programada que ejecutará el respaldo se ejecutará de forma mensual, el 25 de cada mes, a las 2:15 am. Cada backup en su nombre contendrá el nombre de la base de datos y la fecha en la que se genera. Los backups se generarán en el directorio /btrfs/backups/pg del servidor de WDS, ubicado en la oficina gerencial matriz, en la carpeta correspondiente según frecuencia de respaldos:
● carpeta daily_backups para respaldos de base de datos RDC (Script de generación de backups correspondiente, ubicado en /opt/daily_backups/rdc.sh).
● carpeta monthly_backups para respaldos de base de datos RDI (Script de generación de backups correspondiente, ubicado en /opt/monthly_backups/rdi.sh).
La correspondiente programación de la tarea automática puede ser modifica en frecuencia para ambos respaldos en : /etc/crontab. Independientemente del proceso automático anterior y para el caso de RDI, una vez ejecutado el backup mensual, se realizará una copia manual del fichero generado hacia el Disco Externo 2 T WDS. Para el caso de RDC, cada viernes se realizará una copia manual del último backup generado en la semana hacia el Disco Externo 2 T WDS. El responsable de la copia anterior es la arquitecta de datos Mabel Medina Rodríguez. Adicional a lo anterior se creará un cluster de base de datos conformado por un servidor primario y uno secundario, exactamente iguales. Para gestionar dicho cluster se tendrá corriendo el pgpool en un servidor adicional, el cual garantizará, entre otras cosas, la replicación de datos en caso de caída de algún nodo, ya sea el primario o el secundario del cluster de base de datos. Con pgpool, al detectarse la caída de un nodo, se degenera el nodo del cluster y pgpool puede notificar a los responsables el evento sucedido. De forma manual al final de cada dia se chequeará el estado de los nodos, en caso de encontrar alguno caído, se ejecutará el proceso de recuperación del pgpool que primeramente replica la información del nodo activo al caído, para garantizar que al levantarlo, estén al mismo nivel de datos. Seguidamente pgpool levanta el nodo caído y lo adjunta nuevamente al cluster.
PROCEDIMIENTO DE GESTION DE RESPALDOS WDS
Teniendo ambos esquemas de respaldo, pg_dump y pgpool, se cuenta con backups automáticos y manuales incrementales de los datos, para algún caso de pérdida de todos los servidores de base de datos y se tiene además las facilidades de replicación que ofrece pgpool, para garantizar la recuperación de nodos caídos con la data debidamente actualizada.
Respaldo redundante Todos los espacios de respaldos descrito anteriormente son además respaldados en un esquema redundante con frecuencia semanal en un disco externo de 2T. Este proceso es supervisado por el Gerente de Produccin de la organización y efectuado por cada uno de los responsables anteriormente descritos.
PROCEDIMIENTO DE GESTION DE RESPALDOS WDS