Backups locales y backups remotos

Deja un comentario

El programa GBAK nos permite realizar backups locales y backups remotos.

  • En un backup local, la Base de Datos que está en el Servidor copiamos a nuestro disco duro local
  • En un backup remoto, la Base de Datos que está en el Servidor copiamos en el Servidor

NOTA: En todos los ejemplos de abajo el comando se ve en 3 líneas para que sea más fácil visualizarlo, pero debe escribirse en 1 sola línea.

Caso 1. Backup local

Ejemplo 1. El backup lo realiza el usuario SYSDBA o el creador de la Base de Datos

GBAK -backup -user NombreUsuario -password Contraseña 
\\SERVIDOR-PC\C:\SISTEMAS\BASESDATOS\MiBaseDatos.FDB 
C:\SISTEMAS\BACKUPS\MiBackup.FBK

Ejemplo 2. El backup lo realiza un usuario que tiene el rol RDB$ADMIN

GBAK -backup -user NombreUsuario -password Contraseña -role RDB$ADMIN
\\SERVIDOR-PC\C:\SISTEMAS\BASESDATOS\MiBaseDatos.FDB 
C:\SISTEMAS\BACKUPS\MiBackup.FBK

Ejemplo 3. El backup se hace mediante conexión por TCP/IP

GBAK -backup -user NombreUsuario -password Contraseña 
192.168.1.1:C:\SISTEMAS\BASESDATOS\MiBaseDatos.FDB 
C:\SISTEMAS\BACKUPS\MiBackup.FBK

Si el usuario que quiere realizar el backup no es SYSDBA ni el creador de la Base de Datos entonces sí o sí debe tener el rol RDB$ADMIN y además deberá especificarlo para que el backup pueda realizarse con éxito.

La Base de Datos que se encuentra en la computadora cuyo nombre es SERVIDOR-PC o cuya dirección IP es 192.168.1.1 será copiada al disco duro local del usuario. Desde luego que estos son ejemplos, en tu caso tanto el nombre de la computadora o la dirección IP pueden ser distintos. El programa GBAK puede encontrarse en el disco duro local o en cualquier otra computadora. Si se encuentra en otra computadora debe estar en una carpeta compartida o no se lo podrá ejecutar.

Caso 2. Backup remoto

Ejemplo 4. Un backup remoto usando el nombre de la computadora

GBAK -backup -service \\SERVIDOR-PC\service_mgr -user NombreUsuario -password Contraseña 
C:\SISTEMAS\BASESDATOS\MiBaseDatos.FDB 
C:\SISTEMAS\BACKUPS\MiBackup.FBK

Ejemplo 5. Un backup remoto usando la dirección IP de la computadora

GBAK -backup -service 192.168.1.1:service_mgr -user NombreUsuario -password Contraseña 
C:\SISTEMAS\BASESDATOS\MiBaseDatos.FDB 
C:\SISTEMAS\BACKUPS\MiBackup.FBK

Para que el backup remoto pueda realizarse se debe llamar al administrador de servicios o service manager de una computadora que tenga instalado al Servidor del Firebird.

Cuando se usa el service manager el backup termina más rápido, eso significa que los backups remotos son más rápidos que los backups locales.

Comentarios:

  1. El programa GBAK debe poder acceder a la Base de Datos. Para ello se puede usar la ubicación de la Base de Datos  (como en los ejemplos anteriores) o un alias que se haya especificado en el archivo ALIASES.CONF (que es lo recomendable)
  2. Como el programa GBAK copiará todo el contenido de la Base de Datos entonces solamente podrá finalizar con éxito si es ejecutado por el usuario SYSDBA, por el creador de la Base de Datos, o por un usuario que se conecte con el rol RDB$ADMIN. Eso es muy lógico, si un usuario tiene acceso restringido a una Base de Datos no se le puede permitir copiar todo el contenido de ella.
  3. La conexión a la Base de Datos puede realizarse mediante named-pipes (o sea, especificando el nombre de la computadora, como en el Ejemplo 1.) o mediante su dirección IP (como en el Ejemplo 3.)
  4. Si se quiere realizar un backup remoto entonces hay que usar la opción -service. Esta opción puede recibir un solo parámetro, el cual se llama service_mgr. El service_mgr solamente existe en las computadoras que tienen al Servidor del Firebird instalado. Por ese motivo, si la computadora desde donde se realiza el backup no tiene instalado al Servidor del Firebird hay que llamarlo al service_mgr desde una computadora que sí lo tenga instalado. Se lo puede llamar usando el nombre de la computadora (como en el Ejemplo 4.) o la dirección IP de la computadora (como en el Ejemplo 5.). Desde luego que si la computadora desde donde se ejecuta al programa GBAK tiene instalado al Servidor del Firebird entonces no será necesario escribir esos prefijos.
  5. Cuando se hace un backup remoto, la carpeta en donde se copiará el backup debe estar compartida. El programa GBAK es un programa más, para el Sistema Operativo no tiene algo de especial, es uno más del montón. Por lo tanto, para que pueda copiar el backup en una carpeta debe tener derecho de escritura en esa carpeta. Si la carpeta está en otra computadora, entonces debe estar compartida, sí o sí.
  6. Cuando se quiere realizar un backup hay que diferenciar dos cosas: 1) El programa GBAK debe poder conectarse a la Base de Datos, como si se tratara de un usuario humano más. Es por eso que debe especificarse el usuario, la contraseña, y quizás el rol. 2) El programa GBAK debe poder crear un archivo en una carpeta de un disco duro. Es por eso que debe tener permiso de escritura en esa carpeta.
  7. Cuando se realiza un backup remoto, hay que ver a la carpeta destino desde el punto de vista del Servidor. En los ejemplos 4. y 5. la carpeta C:\SISTEMAS\BACKUPS\ es una carpeta que se encuentra en la misma computadora donde se encuentra el Servidor. No es una carpeta local, es una carpeta remota, y se la ve como local, pero es local para el Servidor.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

Anuncios

Haciendo backups con GBAK (1)

2 comentarios

El Firebird nos permite realizar copias de seguridad (generalmente llamadas backups) de nuestras bases de datos de varias formas diferentes, tal como ya habíamos visto en:

https://firebird21.wordpress.com/2013/07/03/los-metodos-para-hacer-backup/

Cada uno de esos métodos tiene sus ventajas y sus desventajas, ninguno es perfecto (evidentemente, porque si uno fuera perfecto ¿para qué tendríamos los demás?).

En el presente artículo empezaremos a ver como hacer backups usando para ello el programa GBAK. Como el tema es muy largo, lo trataremos en varios artículos.

¿Qué es el ciclo backup/restore?

Todos sabemos que debemos realizar frecuentemente copias de seguridad de nuestra Base de Datos porque si ocurre un accidente (como el disco duro dañado), la única forma rápida y confiable de recuperar su contenido en todo o en gran parte es a través de una copia de seguridad actualizada. Este proceso tiene dos partes:

  1. Copiar todo el contenido de la Base de Datos en un archivo. A este paso se le llama realizar el backup.
  2. Usar el archivo de backup para obtener una Base de Datos operativa, a ese paso se le llama restaurar la Base de Datos.

Por lo tanto, el ciclo backup/restore significa: crear un archivo de backup y luego restaurarlo.

Hay que enfatizar que el proceso no está completo si solamente se realiza el backup. Hay que realizar ambos, sí o sí: el backup y el restore. O sea: la copia de seguridad y la restauración de esa copia.

¿Qué programa usaremos para realizar el ciclo backup/restore?

El programa se llama GBAK.EXE, y con él podremos:

  • Realizar el backup
  • Restaurar la Base de Datos

¿Qué tareas realiza GBAK.EXE?

Cuando hace el backup:

  • Lee todo el contenido de una Base de Datos y copia ese contenido en otro archivo. Pero no lo copia completo. Los índices por ejemplo no son copiados. Gracias a eso el tamaño de la copia es menor de lo que sería si los hubiera copiado.
  • No copia la basura en el backup (la Base de Datos original continúa con toda la basura que tenía)

Cuando restaura la Base de Datos:

  • Pone el TID de cada fila de cada tabla en 1. (El TID es un número que identifica a la transacción que creó la fila). Por lo tanto es como si todas las millones y millones de filas de las tablas hubieran sido insertadas por una sola transacción.
  • Verifica que cada fila tenga datos válidos
  • Crea los índices
  • Calcula las estadísticas de los índices

¿Dónde se encuentra el programa GBAK.EXE?

En la sub-carpeta \BIN de la carpeta donde está instalado el Firebird, por ejemplo en:

C:\Archivos de Programa\Firebird\Firebird_2_5\Bin\

¿Es necesario que el programa GBAK.EXE se encuentre ahí para hacer un backup?

No. Puedes tener una copia del programa GBAK.EXE en cualquier carpeta de tu disco duro. Por ejemplo si tienes un programa de contabilidad en la carpeta:

D:\MisSistemas\Contabilidad\

en esa misma carpeta podrías tener una copia de GBAK.EXE y entonces tu programa ejecutable (por ejemplo: CONTA.EXE) podría buscarlo a GBAK.EXE allí mismo. O sea que si lo deseas podrías tener a GBAK.EXE en la misma carpeta donde tienes a CONTA.EXE

¿Qué versión de GBAK.EXE debo utilizar?

La misma versión que el Servidor del Firebird. Si por ejemplo tu versión del Firebird es la 2.5.4, entonces deberías siempre usar el programa GBAK.EXE que viene incluido en esa versión.

¿Y si no coincide la versión del Servidor del Firebird con la versión de GBAK.EXE?

Hmmmmmmm, eso no es recomendable. Podría funcionar bien pero … también podrían ocurrir errores, no hay garantías.

Una buena posibilidad para que no ocurran errores es tener al programa GBAK.EXE en una carpeta compartida. Y asegurándote que corresponde a la versión del Firebird que se está usando. Para no confundirte, puedes renombrar a GBAK.EXE para que te indique su versión, algo como: GBAK_2_5_4.EXE para saber que es el correspondiente a la versión 2.5.4 del Firebird.

Ejemplo:

  • En la carpeta compartida D:\EJECUTABLES\ tienes una copia de GBAK.EXE
  • Esa copia de GBAK.EXE coincide con la versión del Firebird que utilizas
  • Como tu versión del Firebird es la 2.5.4 entonces lo renombras como GBAK_2_5_4.EXE
  • Tus programas ejecutables que se encuentran distribuidos en un montón de computadoras (en nuestro ejemplo: CONTA.EXE) cuando necesitan hacer un backup llaman al programa D:\EJECUTABLES\GBAK_2_5_4.EXE

¿Cuáles son las ventajas de usar GBAK.EXE para hacer los backups?

  • Se obtiene una copia completa de la Base de Datos
  • Los usuarios pueden continuar trabajando normalmente mientras se realiza el backup
  • Al restaurar el backup se reconstruyen los índices y sus estadísticas
  • Al restaurar el backup se puede cambiar el tamaño de la página
  • En la Base de Datos restaurada se ha recolectado la basura y se ha realizado el barrido (sweep)
  • Se puede ver que tarea está realizando el programa
  • En el disco duro la Base de Datos restaurada se encuentra (generalmente) menos fragmentada que la Base de Datos original, y por lo tanto todos los accesos son más rápidos

¿Cuáles son las desventajas de usar GBAK.EXE para hacer los backups?

  • El archivo generado no puede ser utilizado directamente, debe ser restaurado con la misma versión de GBAK o con una versión posterior, para poder ser utilizado
  • Si la Base de Datos es muy grande, tanto hacer el backup como la restauración demoran mucho tiempo
  • Si la Base de Datos es muy grande, el archivo de backup también lo será
  • Si la Base de Datos es muy grande, habrá un período de muchos minutos (desde que empezó la ejecución del programa GBAK.EXE hasta que terminó) en que no se contará con un backup actualizado. De todo lo que haya ocurrido dentro de la Base de Datos en ese período no se tendrá un backup.

¿Cuáles son las consecuencias de usar GBAK para hacer backups?

  • La Base de Datos restaurada (si no ocurrieron errores durante la restauración) se encuentra en perfecto estado de salud. Eso significa: índices perfectamente balanceados, estadísticas correctas, nada de basura.
  • En la Base de Datos restaurada todas las filas de todas las tablas que se encontraban en la Base de Datos original ahora tienen un TID (identificador de la transacción) igual a 1.
  • Los identificadores de las transacciones (OAT, OIT, OST, NT) ahora tienen valores muy pequeños. NT (next transaction) no es igual a 1 porque al restaurar se realizan algunas tareas dentro de la Base de Datos y esas tareas inician transacciones. Pero de todas maneras el valor de NT siempre es pequeño, típicamente menos que 100.

¿Por qué en la Base de Datos restaurada algunas consultas son más lentas que en la Base de Datos original?

Uno supondría que en la Base de Datos restaurada, como su salud es perfecta todos los SELECT serían más rápidos que en la Base de Datos original pero … no siempre sucede así.

¿Por qué?

Bien, uno de los métodos que utiliza el Firebird para que las consultas sean muy rápidas es guardar en el caché de la computadora donde se encuentra el Servidor las filas retornadas por los últimos SELECTs.

Si el Servidor se apaga, todo el contenido del caché desaparece (porque se encuentra en memoria RAM, la cual es volátil). Pero en las organizaciones que nunca apagan el Servidor el contenido del caché sirve para agilizar de gran manera a las consultas. Si las filas que solicita un usuario ya se encontraban en el caché entonces desde allí le son entregadas, y eso es muchísimo más rápido que leerlas desde el disco duro.

Sin embargo, al restaurar una Base de Datos el caché se vacía (porque los identificadores de las transacciones cambiaron, ahora ya son todos 1) y entonces hay que reiniciar el proceso de ir cargando el caché.

Como consecuencia, algunas consultas (no todas, solamente las que tenían filas en el caché) serán más lentas en la Base de Datos restaurada que en la Base de Datos original. Claro que esto será solamente durante un corto tiempo, luego será distinto.

¿GBAK siempre realiza el backup correctamente?

No. Y esto es algo súper importante para recordar. Al hacer el backup, GBAK no verifica si los datos que está copiando tienen errores o no. Eso solamente se puede descubrir en el momento de la restauración, nunca en el momento del backup.

Por lo tanto, el backup que realizó GBAK …. puede ser totalmente inservible.

¿Terrible?

Sí, así mismo, eso es. Terrible.

Por ejemplo, una columna definida como NOT NULL tiene valores NULL. Tal cosa no debería ocurrir pero a veces la Base de Datos se corrompe y sucede. GBAK copia esas filas sin ningún aviso, ninguna advertencia, ningún mensaje de error. Sin embargo, al querer restaurar ese backup allí sí se enojará … y finalizará la restauración. El archivo que estaba generando se muere ahí mismo, se vuelve completamente inservible.

Hay métodos para solventar ese problema (que veremos en otro artículo) pero lo importante a recordar es:

JAMÁS SE DEBE CONFIAR EN EL BACKUP. JAMÁS

¿Cómo se puede saber si un backup está correcto?

Ya vimos que al hacer el backup GBAK no nos avisa si la Base de Datos tiene errores. Solamente nos avisa cuando está restaurando, así que por lo tanto….

La única manera de verificar que un backup está ok es restaurándolo.

No hay otra forma.

¿Cuál es la mejor manera de hacer y verificar un backup?

Escribiendo un comando que apenas termine el backup lo restaure, de esa manera enseguida sabremos si nuestro backup es confiable o si por el contrario es inútil (y por lo tanto debemos corregir los errores que tiene y realizar otro backup).

Ese comando es el siguiente:

GBAK -b -user SYSDBA -password masterkey MiBaseDatos.FDB stdout | GBAK -r -user SYSDBA -password masterkey stdin Restaurada.FDB

¿Qué hace este comando?

En lugar de crear un archivo de backup en el disco duro (que es lo normal), lo crea en la salida estándar (stdout). Luego realiza la restauración, tomando como archivo de entrada del segundo GBAK el archivo generado por el primer GBAK.

¿Consecuencia?

Que así hacemos un backup y también una restauración. Y si al restaurar ocurre algún error entonces lo sabremos al instante y podremos corregirlo.

Conclusión:

En el Firebird hay varios métodos para hacer backups, usar el programa GBAK.EXE es uno de esos métodos. Como todo, tiene algunas ventajas y algunas desventajas. Nunca jamás hay que confiar en que el backup está correcto y sin errores porque a veces sí tiene errores. Esos errores solamente pueden descubrirse cuando se está restaurando el backup, es el único momento en que se puede saber si el backup está correcto o no. Por lo tanto, una muy buena política administrativa es apenas terminado el backup intentar la restauración. Si el backup no se puede restaurar es inservible e inútil.

Artículos relacionados:

Los métodos para hacer backup

Backup y restauración al mismo tiempo

Backup y restore a una versión más nueva del Firebird

Entendiendo los identificadores de las transacciones

Entendiendo sweep y garbage collection

La Next Transaction después de un ciclo backup/restore

El ciclo backup/restore usando GBAK

El índice del blog Firebird21

El foro del blog Firebird21

Aumentando la velocidad de NBACKUP

2 comentarios

Como recordarás, Firebird viene con dos programas que te permiten hacer backups de las bases de datos:

  • GBAK.EXE
  • NBACKUP.EXE

Ambos tienen sus ventajas y sus desventajas, y es por eso que existen dos. Si uno de ellos fuera mejor en todo entonces el otro no existiría, no tendría razón de ser.

Cuando se hace el backup con el programa NBACKUP.EXE se puede usar el parámetro -D para aumentar la velocidad en que se realiza el backup.

¿Qué significado tiene el parámetro -D?

Habilita o deshabilita la copia directa, es decir sin la intervención del caché del sistema de archivos del sistema operativo.

A veces, escribiendo -D ON se consigue una mayor velocidad y a veces es escribiendo -D OFF se consigue una mayor velocidad.

¿Qué se debe escribir?

NBACKUP -U SYSDBA -P masterkey -B 0 MiBaseDatos.FDB MiBackup.NBK -D ON

Reemplazando por supuesto el ON por el OFF para probar la forma alternativa

¿Cómo saber cuál opción es mejor?

Probando de ambas formas y midiendo los tiempos empleados en realizar los respectivos backups.

En unas pruebas que hizo el autor de este blog con una Base de Datos de 580 Mb, los resultados fueron:

  • con el parámetro -D ON, 27 segundos
  • con el parámetro -D OFF, 12 segundos

En ese caso evidentemente -D OFF fue mejor, pero no siempre será así, dependiendo de tu Sistema Operativo y del tamaño de tu Base de Datos eso podría variar. Entonces, hay que probar.

Conclusión:

Si haces backups por intermedio del programa NBACKUP.EXE entonces deberías probar con el parámetro -D para descubrir si poniéndolo en ON o en OFF se obtienen mejores resultados.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

 

Inferencia de datos

Deja un comentario

Como sabes, las bases de datos son muy útiles para guardar y procesar datos pero también pueden conllevar un compromiso con la seguridad de los mismos. Muchas veces lo que se guarda en sus tablas es para que lo vean solamente algunos usuarios, no todos los usuarios.

Esto es más importante en las aplicaciones que se diseñan para los organismos de seguridad (militares, policías, servicios de inteligencia, etc.) pero también puede ocurrir con empresas comerciales.

¿Qué significa inferir?

Según el Diccionario es obtener una conclusión, deducir algo a partir de los datos con los que se cuenta.

Ejemplo

Tenemos una tabla llamada SALARIOS donde se guarda el salario de cada empleado de la Empresa. El personal de Recursos Humanos es el encargado de elaborar los cheques de pago a esos empleados, pero no deben conocer el salario de los empleados de nivel superior, solamente deben conocer el salario de los empleados de nivel medio y nivel bajo.

INFERIR1

Captura 1. Si haces clic en la imagen la verás más grande

En la Captura 1 estamos viendo el Identificador del Empleado, el Número del Mes, el Número del Año y el Monto de su salario. El Gerente de Recursos Humanos es “Juan” y él sí puede ver esa tabla. Pero su empleada “María” no debería ver el salario del empleado cuyo Identificador es 3, o sea que “María” debería ver esto:

INFERIR2

Captura 2. Si haces clic en la imagen la verás más grande

Al mirar esa tabla ella nota que está faltando un empleado con Identificador igual a 3, y entonces cuando la Empresa contrata a un nuevo empleado cuyo nombre es “Martín” ella trata de usar el Identificador 3 para asignárselo a “Martín” y así no tener números de Identificación faltantes. Pero como el Identificador 3 sí existe (aunque ella no puede verlo) al intentar grabar los datos de “Martín” obtendrá un mensaje de error. Y como “María” es inteligente entonces infiere (es decir: deduce) que sí existe un empleado con Identificador igual a 3 pero que a ella no le permiten verlo.

Y como además de inteligente es curiosa a partir de ese momento se dedica a intentar averiguar los datos del empleado con Identificador 3, mediante tablas cruzadas, o algunas otras técnicas.

Diseñando para evitar inferencias

Si algún usuario puede inferir (deducir) que algo se le está ocultando entonces puede también inferir (deducir) que se trata de algo valioso, algo de lo cual podrá obtener provecho económico o de otro tipo. Por algo se le ocultan los datos ¿verdad?.

Entonces, cuando diseñamos nuestras bases de datos debemos pensar en como evitar las inferencias. No es fácil ante usuarios inteligentes y con muchos conocimientos de Informática pero debemos intentarlo.

La primera y elemental medida es impedir que los usuarios puedan asignar identificadores o códigos. Estos deberían ser elegidos y puestos automáticamente por el Servidor del Firebird o por nuestra aplicación.

Lo segundo a recordar siempre es que los identificadores son para uso interno y los códigos son para uso externo. Eso implica que los usuarios jamás deberían ver los identificadores (ni siquiera necesitan saber que existen) y manejarse siempre exclusivamente con códigos. En general los códigos no deberían cambiarse pero si se cambian no afectarán a la operatividad de la Base de Datos porque ésta no los utiliza para nada, son solamente para mostrárselos a los usuarios.

Tercero, los códigos no deberían ser de la forma “A, B, C, D, E, …” o de la forma “1, 2, 3, 4, 5, …” porque si falta una letra o un número en la secuencia entonces es muy fácil inferir que algo se está ocultando.

Conclusión:

Cuando se diseña una Base de Datos un aspecto importante es el relacionado con la seguridad de los datos. Y dentro de la seguridad hay que tomar en cuenta que los usuarios no autorizados a ver una información no puedan realizar inferencias para saber que esa información existe.

En el caso de nuestro ejemplo “María” rápidamente descubrió que se le estaban ocultando los salarios del empleado cuyo Identificador es 3. ¿Por qué? porque la Base de Datos estaba mal diseñada y se le permitía a ella asignar un Identificador al nuevo empleado. En una Base de Datos bien diseñada ningún usuario, por ningún motivo, puede asignar o cambiar un Identificador o un Código. Si alguna vez se requiere hacer eso entonces debería hacerse exclusivamente usando nuestra aplicación.

Artículos relacionados

Usando IDENTIFICADORES y CÓDIGOS en nuestras tablas

El índice del blog Firebird21

La problemática de la modificación de datos y del borrado de filas

2 comentarios

Los usuarios siempre quieren tener la posibilidad de modificar los datos que ya se guardaron y de borrar las filas de una tabla si por algún motivo los datos o las filas guardados ya no sirven pero nosotros como profesionales de la Informática ¿debemos otorgarles alegremente esa posibilidad?

Hacerlo así es muy riesgoso en cuanto a la seguridad y la confiabilidad de nuestra Base de Datos, veamos algunos ejemplos:

  • Un cajero registra una venta de 6 productos, totalizando la venta 1.200 dólares. O sea que en su caja ingresaron 1.200 dólares por esa venta. Luego modifica la cantidad vendida a 3 productos y por lo tanto el total ahora registrado es de 600 dólares. Y los restantes 600 dólares se van a su bolsillo.
  • Un alumno se aplazó en Matemática pero como es amigo de la secretaria que registra las calificaciones en la computadora le pide que cambie su calificación en esa materia. Y ahora ya está aprobado.
  • Un moroso consuetudinario no puede hacer compras a crédito porque donde va a pedir un crédito le dicen que no se lo pueden otorgar porque está registrado como moroso en la Base de Datos a la cual acceden todos los comerciantes para saber la situación crediticia de los potenciales clientes. Entonces le paga a un operador de esa Base de Datos para que borre su nombre y sus antecedentes de ella. Y listo, ahora ya tiene crédito libre.
  • El empleado que carga los datos de los sueldos a pagar se auto-asigna un aumento de 200 dólares. Como la empresa tiene cientos de empleados nadie se molesta en controlar uno por uno los sueldos para verificar que sean los correctos. Después de haberse impreso la planilla de pagos de sueldos vuelve a disminuir su sueldo en esos 200 dólares. Así que su “aumento de sueldo” solamente estará registrado un corto tiempo, quizás una hora, durante cada mes. El resto del tiempo cualquier consulta a esa tabla mostrará su sueldo correcto.

Estos son solamente algunos ejemplos, hay miles más de “transfugueadas” que pueden hacer “los muchachos” si tienen abierta la posibilidad de hacerlas.

Pero tampoco podemos cerrar totalmente la posibilidad de modificar datos o de borrar filas, a veces los usuarios tienen una necesidad legítima de hacer esas operaciones entonces ¿cuál es la solución?

  • No cualquiera puede hacer esas operaciones, se necesita de un permiso especial para ello, solamente algunos usuarios deben estar autorizados. Los usuarios normales solamente tienen el privilegio de INSERT en las filas, pero no tienen el privilegio de UPDATE ni el privilegio de DELETE.
  • Cada modificación de datos o borrado de filas debe ser registrado en una tabla aparte, no en la tabla original sino en otra tabla. En esta otra tabla se guardarán, entre otros: el nombre del usuario que modificó o borró, el IP de la computadora que usó, la fecha y la hora en que ocurrió
  • En el caso de modificación, cuales eran los datos originales y cuales son ahora los nuevos datos
  • En el caso de borrado, una copia de la fila completa que borró. Alternativamente, en lugar de borrar físicamente la fila suele ser mucho mejor colocarle una “marca de borrado”. Esta es una columna que solamente indica el estado de la fila que puede ser: ACTIVO o INACTIVO. El problema con esta alternativa es que en todas las consultas que involucren a esa tabla deberemos poner en el WHERE la condición de que su estado sea ACTIVO (o INACTIVO, si lo queremos es ver a las filas “borradas”).

Conclusión:

Jamás se puede impedir que personas malintencionadas modifiquen el contenido de nuestra Base de Datos para cometer fraudes pero sí es nuestra responsabilidad dificultarles lo máximo esa posibilidad. Se nos paga (entre otras cosas) para que el contenido de la Base de Datos sea seguro y confiable, no para que cualquiera pueda meter sus pezuñas en ella y hacerle lo que se le antoje. Gente con ganas de cometer fraudes puedes encontrar en cualquier organización, por lo tanto las operaciones de UPDATE y de DELETE deben estar altamente restringidas y debe llevarse un registro minucioso de cualquiera de esas operaciones para que cuando se realice una auditoría se pueda ver claramente quien las hizo, cuando y donde.

Artículo relacionado:

El índice del blog Firebird21

Ejemplos del uso de Zebedee con Firebird

21 comentarios

Aquí hay algunos ejemplos del uso de Zebedee con Firebird.

En estos dos artículos, habíamos visto para que sirve Zebedee y como usarlo. Ahora, para aclarar mejor el tema, algunos ejemplos:

Usando Zebedee con Firebird

Usando Zebedee con Firebird. Parte 2

Servidor

Línea de comandos

START ZEBEDEE -s localhost:3050

Usando un archivo de configuración

START ZEBEDEE -f SERVIDOR1.ZBD

Cliente

Línea de comandos

START ZEBEDEE 3051:99.999.999.99:3050

Usando un archivo de configuración

START ZEBEDEE -f CLIENTE.ZBD

Conexión con una Base de Datos Firebird

CONNECT localhost/3051:E:\BASESDATOS\MiBase.FDB USER SYSDBA PASSWORD masterkey;

NOTAS:

  1. En la computadora donde se encuentra el Servidor de Zebedee debe estar abierto el puerto 11965
  2. Las demás computadoras no necesitan (y no deberían) tener puertos abiertos
  3. Cualquier usuario puede conectarse, no solamente SYSDBA, por supuesto que con sus nombres y passwords correctos
  4. No es obligatorio escribir el comando START, pero si no se lo escribe entonces la ventana “Símbolo del sistema” se queda congelada. Zebedee funciona igual, pero esas ventanas congeladas no les gustan a los usuarios
  5. Las computadoras Cliente deben poder acceder a la computadora Servidor. Eso significa que la IP del Servidor debe ser pública, de una VPN como Hamachi o encontrarse en una red local
  6. No suele justificarse usar Zebedee en una red local, porque el tiempo que se gana al enviar los datos comprimidos se pierde al comprimir y descomprimir esos datos. Se justificaría su uso si aún tratándose de una red local hay computadoras que no son confiables
  7. Si se usa un archivo de configuración, ese archivo no debe encontrarse en una carpeta compartida o cualquiera podría modificarlo a su antojo
  8. Si la conexión con el Servidor de Firebird se realiza a través de Internet entonces usar Zebedee (o algún programa similar) es un requisito ineludible

Artículos relacionados:

Proteger a las bases de datos visibles en Internet

Usando Zebedee con Firebird

Usando Zebedee con Firebird. Parte 2

El índice del blog Firebird21

Usando Zebedee con Firebird. Parte 2

4 comentarios

Zebedee es un programa que nos permite enviar datos de una computadora a otra computadora de forma fácil, rápida y segura. Su principal utilidad es cuando la conexión entre ambas computadoras se hace vía Internet; puede usarse también en una red local pero usarlo en una red local se justifica muy poco.

No necesariamente debe usarse con Firebird, puede usarse siempre que se requiera enviar de forma fácil, rápida y segura datos entre dos computadoras conectadas por Internet pero en el blog solamente mostraremos su uso con Firebird, para los demás casos puedes leer su documentación.

En este artículo habíamos visto lo necesario para hacerlo funcionar correctamente:

https://firebird21.wordpress.com/2013/09/12/usando-zebedee-con-firebird/

y ahora veremos las demás opciones que pueden interesarnos cuando lo usamos con Firebird. En la Captura 1 vemos todas las opciones posibles:

ZEBEDEE1

Captura 1. Si haces clic en la imagen la verás más grande

pero como dijimos anteriormente, solamente algunas de ellas utilizaremos con Firebird.

Instalarlo como Servicio del Windows

Los Servicios del Windows son programas que están siempre ejecutándose: al encender la computadora empiezan a ejecutarse y continúan hasta el momento en que se apaga la computadora. Instalarías a Zebedee como un Servicio si constantemente se están conectando a una Base de Datos mediante Internet; si es algo esporádico entonces no necesitas instalarlo como un Servicio, simplemente lo ejecutas cada vez que lo requieres y ya.

Para que Zebedee se instale como un Servicio:

  1. Debes abrir la ventana “Símbolo del sistema” como Administrador
  2. Debes escribir: Zebedee -S install

ZEBEDEE2

Captura 2. Si haces clic en la imagen la verás más grande

Usando archivos de configuración

Además de escribir las opciones de Zebedee en la línea de comandos también tienes la posibilidad de escribirlas en un archivo de configuración, de esa manera te resultará más fácil personalizarlo. Hay dos archivos de configuración:

  • El que usará el Servidor de Zebedee
  • El que usará el Cliente de Zebedee

En ambos casos los nombres pueden ser cualesquiera pero la extensión debe ser .ZBD si queremos que al hacer doble clic sobre ellos sean utilizados por Zebedee.

Para especificar un archivo de configuración debemos escribir su nombre a continuación de la opción -f

Para impedir que el Zebedee parezca haberse quedado “colgado” debes ejecutarlo con el comando START

ZEBEDEE3

Captura 3. Si haces clic en la imagen la verás más grande

 Todas las líneas son de la forma:

PalabraClave Valor     # Todo lo que viene después del símbolo de numeral es un comentario

Donde PalabraClave es una palabra y Valor es un número, un valor boolean o un string. Si es un string debe estar rodeado por comillas o por apóstrofos. Si es boolean debe ser true o false. Todo lo que escribas a continuación del símbolo # será tratado como un comentario.

Caso 1. El Servidor de Zebedee y el Servidor de Firebird en la MISMA computadora

Si ambos Servidores se encuentran en la misma computadora entonces puedes usar este archivo de configuración, guárdalo por ejemplo con el nombre SERVIDOR1.ZBD:


# Usar este archivo de configuración cuando el Servidor de Zebedee y el Servidor de Firebird están en la MISMA computadora

VERBOSITY 2    # Muestra mensajes detallados

SERVER TRUE    # Se está configurando al Servidor de Zebedee

DETACHED TRUE  # Zebedee se ejecuta en el background. Para que no parezca haberse "colgado" se debe escribir: START ZEBEDEE -f SERVIDOR1.ZBD

UDPMODE FALSE  # No se necesita UDP con Firebird

LOGFILE "./SERVIDOR1.LOG" # Envía los mensajes de LOG a este archivo

REDIRECT NONE  # Cierra todos los puertos de redirección

REDIRECT 3050  # Redirige al puerto 3050, usado por el Servidor de Firebird

TARGETHOST localhost # El Servidor de Firebird está en esta misma computadora

COMPRESSION zlib:9 # Máximo nivel de compresión

KEYLENGTH 256 # Claves de 256 bits, son muy seguras

KEYLIFETIME 36000 # Las claves duran 36.000 segundos (10 horas)

MAXBUFSIZE 16383 # Tamaño máximo del buffer

Caso 2. El Servidor de Zebedee y el Servidor de Firebird en DISTINTAS computadoras

Si ambos Servidores se encuentran en computadoras distintas entonces puedes usar este archivo de configuración, guárdalo por ejemplo con el nombre SERVIDOR2.ZBD:

# Usar este archivo de configuración cuando el Servidor de Zebedee y el Servidor de Firebird están en DISTINTAS computadoras

VERBOSITY 2 # Muestra mensajes detallados

SERVER TRUE # Se está configurando al Servidor de Zebedee

DETACHED TRUE # Zebedee se ejecuta en el background. Para que no parezca haberse "colgado" se debe escribir: START ZEBEDEE -f SERVIDOR2.ZBD

UDPMODE FALSE # No se necesita UDP con Firebird

LOGFILE "./SERVIDOR2.LOG" # Envía los mensajes de LOG a este archivo

REDIRECT NONE # Cierra todos los puertos de redirección

REDIRECT 3050:IP_del_Servidor_Firebird:3050 # Redirige al puerto 3050, usado por el Servidor de Firebird

TARGETHOST IP_del_Servidor_Firebird # El Servidor de Firebird está en OTRA computadora

COMPRESSION zlib:9 # Máximo nivel de compresión

KEYLENGTH 256 # Claves de 256 bits, son muy seguras

KEYLIFETIME 36000 # Las claves duran 36.000 segundos (10 horas)

MAXBUFSIZE 16383 # Tamaño máximo del buffer

Configurando al Cliente

Puedes usar este archivo para configurar al Cliente, guárdalo por ejemplo con el nombre CLIENTE.ZBD:

# Este archivo de configuración debe encontrarse en cada computadora Cliente del Zebedee

VERBOSITY 1 # Mensajes básicos solamente

SERVER FALSE # No es un Servidor de Zebedee (por lo tanto es un Cliente)

DETACHED TRUE # Cierra la ventana "Símbolo del sistema"

TUNNEL 3051:99.999.999.99:3050 # Puedes elegir otro puerto local, no necesariamente debe ser 3051
 # Debes reemplazar 99.999.999.99 por el IP del Servidor de Firebird
 # Debes reemplazar 3050 por el puerto que usa el Servidor de Firebird
# Para conectarte a una Base de Datos:
# ------------------------------------
#
# CONNECT localhost/3051:IP_Servidor_Firebird:Ruta_a_la_Base_deDatos
#
# CONNECT localhost/3051:192.168.0.1:E:\basesdatos\Mibase.fdb USER SYSDBA PASSWORD masterkey;

Artículos relacionados

Usando Zebedee con Firebird

El índice del blog Firebird21

Older Entries