sábado, 4 de julio de 2009

Copia de seguridad remota


Hace más de un año comenté cómo planeaba y ejecutaba las copias de seguridad en el vServer.

Dije además que enviaba las copias de seguridad a otros servidores remotos para salvaguardar la información de una forma más efectiva, hoy veremos cómo.

Supongamos el caso más sencillo; un vServer y una sola aplicación.

Supongamos también que en el servidor hemos programado una sola tarea de copia de seguridad de la aplicación que cada día a la misma hora machaca la copia del día anterior.

Para acabar de definir el escenario necesitaremos otro vServer en otro lugar que llamaremos remoto, con un recurso compartido (nombre asignado a una carpeta física en disco) al que tiene acceso y control total el usuario SDV.

Ya lo tenemos todo.

Veamos cómo conseguir que nuestra copia de seguridad diaria se copie también en el equipo remoto.

Soy muy amigo de las tablas de configuración y suelo tener en cada aplicación una tabla CFG con un sólo registro conteniendo datos redundantes como la ip-pública del servidor donde publico la aplicación, alias que le pongo a la aplicación, nombre del usuario SDV, su contraseña, etc. Siempre viene bien poder tenerlos a mano dentro de algún proceso y así parametrizo el proceso usando los datos de CFG en vez de tenerlos declarados dentro del proceso. Es mejor cambiar datos de una tabla que editar el proceso si alguno de estos datos cambian.

Así pues declaro una tabla CFG con los siguientes campos: ip pública del servidor remoto, nombre del usuario sdv remoto, contraseña del usuario sdv, nombre del recurso compartido remoto (donde voy a guardar la copia de seguridad remota), y senda completa (senda, nombre y extensión) del archivo vcs que voy a mandar.

Si estos datos suelen ser siempre los mismos, incluso podemos ponerlos como contenido inicial de los campos, en el proceso ONINIT-MAP-SERVER cargamos la tabla CFG por el índice Código, vemos si no hay registros (if !n) y hacemos un Alta directa en la tabla CFG.

Si la tabla CFG es de un sólo registro, para su edición lanzamos un proceso que carga la tabla CFG por el índice Código, selecciona ficha por posición 1, lee la ficha seleccionada y añade como retorno el formulario de edición de la tabla.

Para capturar la senda completa del archivo vcs que voy a mandar uso un proceso como el siguiente:


El proceso con origen una ficha de la tabla CFG, presenta el diálogo para seleccionar un fichero, si aceptan el diálogo y han indicado una ruta, me la guardo ( fAjustaSenda convierte las barras \ en dobles barras \\ ).

Como vamos a enviar periódicamente información entre servidores preparo una tabla de ENVIOS. En esta tabla anotaremos los datos de cada envío; servidor remoto a donde se envía, usuario y contraseña que usamos para ello, fecha y hora del envío, y su resultado como booleano, así como la fecha y hora de finalización para controlar cuánto tardamos.

Ahora sólo queda hacer un proceso no-privado para poder programarlo como tarea en vServer.

En este proceso sin origen cargamos la tabla CFG para tomar los datos que necesitamos del registro 1; ip pública del servidor remoto, nombre del usuario sdv, su contraseña, carpeta remota donde hacer el envío, y de la senda del archivo a enviar nos quedamos con su nombre y extensión (fExtraerNombreExtDeSenda) que luego usaremos añadiéndole un prefijo.

A continuación en el proceso damos un Alta directa en la tabla ENVIOS, anotando en el Pre los datos necesarios, y quedándonos en el Post con el Código del registro de envío.

Preparo además una variable local fecha para guardar la Fecha del envío formateada AAMMDD para añadirla como prefijo al nombre y extensión del archivo que mandamos en el servidor remoto, así no machacaré las copias de seguridad del servidor remoto cada día, si no que las iré guardando todas, todas, todas, con su fecha en el nombre.

Sólo queda componer en el proceso la vrl-destino, es decir, en qué carpeta del servidor remoto vamos a guardar y con qué nombre la copia de seguridad, en qué servidor y con qué usuario y contraseña, mandarlo, y en función del resultado apuntarlo en la tabla ENVIOS.

Y eso es todo amigos.

Sólo queda programar como tarea en el servidor este proceso para que se ejecute cada día tras la copia de seguridad y ya está. Nuestros datos doblemente a buen resguardo.

Os propondría variaciones sobre el tema como tener varios registros en la tabla de configuración, es decir, distintos servidores a los que mandar la copia, o bien todos los días a todos, o cada día a uno, e incluso mandar copias de diferentes carpetas origen (lunes, martes, miércoles, etc...).

Usando una táctica similar se puede mandar también el mapa relativo a la copia de seguridad, archivos de configuración de vServer, etc.

Life is soft!

3 comentarios:

  1. Hola Domingo:

    Voy a darte otra opción por si no quieres utilizar SDV o funciones remotas, así como ahorrarte otro vMotor.

    Yo lo hago así porque tuve algún problema con SDV, bajaba mucho el rendimiento hasta que terminaba el tráfico del archivo y alguna vez, si se producía un error, al ser del lado del servidor, este caía y se iba todo al garete.

    Para esta "receta" necesitas un servidor ftp, sftp, ssh o lo que quieras (preferiblemente cifrado), un pequeño script VBS, BAT, Python, Java, PHP o lo que quieras que simplemente renombre el fichero .vcs, le añada la fecha y suba un fichero al FTP (Hay millones en la red).

    Pones una tarea programa de windows que ejecute este script y te olvidas de sobrecargar el vMotor.

    En fin, otra idea.

    ResponderEliminar
  2. Es una lástima que el cliente (mio) que más lo necesita genera un vcs de casi 6 Gigas. No es viable subirlo a un servidor ftp. Por lo demás me parece una solución estupenda.

    ResponderEliminar
  3. @Adelo,

    Muchas gracias por la "receta", me parece perfectamente válida: no necesitas un vServer al otro lado y descargas al motor de la tarea de envío por SDV.

    En mi caso lo hago así porque al otro lado siempre hay un vServer, además me conoces y sabes que soy bastante cabezón al intentar hacerlo todo con sólo recursos propios de Velneo.

    @Paco,

    Un vcs de 1GB me tarda como 20 minutos por este método (de ONO a ONO y una buena conexión).

    De todas formas 6GB de datos me parecen excesivos, seguro que es por campos objeto.

    Si es así me plantearía separar los campos objeto incluso a otra aplicación.

    Es una idea.

    Un saludo,

    ResponderEliminar