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 (3)

Deja un comentario

En artículos anteriores ya vimos mucho sobre la parte teórica de hacer backups en general, y de hacer backups con GBAK en particular, así que vayamos ahora a la parte práctica:

La sintaxis general de GBAK

GBAK <opciones> -USER <usuario> -PASSWORD <contraseña> <origen> <destino>

Opciones: con ellas le indicamos a GBAK lo que queremos hacer

Usuario: es el nombre del usuario que realizará el backup o la restauración. Debe ser SYSDBA o el creador de la Base de Datos o un usuario con el rol RDB$ADMIN.

Contraseña: es la contraseña del usuario que realizará el backup o la restauración

Origen: si se hará un backup es nombre completo de la Base de Datos (la cual generalmente tiene la extensión .FDB) o un alias definido en el archivo ALIASES.CONF; si se hará una restauración es el nombre completo del archivo de backup (el cual generalmente tiene la extensión .FBK)

Destino: si se hará un backup, es el nombre del archivo que será generado (generalmente con la extensión .FBK); si se hará una restauración es el nombre que tendrá la nueva Base de Datos (generalmente con la extensión .FDB)

Tipos de opciones

Las opciones de GBAK pueden ser de tres tipos:

  1. Opciones generales
  2. Opciones del backup
  3. Opciones de la restauración

Las opciones generales son las que se pueden usar en ambos casos (es decir, cuando se hace el backup o cuando se hace la restauración) y son las siguientes:

nodbtriggers Impide que se desencadenen los triggers de la Base de Datos.

-pas[sword] <contraseña> La contraseña que el usuario utiliza para conectarse a la Base de Datos. Alternativamente se puede usar -fet[ch_password] para no escribir la contraseña

-fet[ch_password] <nombre_archivo> En lugar de escribir la contraseña en la línea de comandos se puede extraerla de un archivo, de esta manera si hay un curioso mirando lo que escribes no podrá saber cual es tu contraseña

-m[etadata] Solamente hace el backup o la restauración de los metados, los datos introducidos por los usuarios serán ignorados

-role <nombre_del_rol> Si el usuario usó un rol

-se[rvice] <hostname[/port]>:service_mgr Cuando se está haciendo el backup: el archivo se crea en el Servidor, usando para ello al Service Manager. Cuando se está haciendo la restauración: la Base de Datos se crea en el Servidor, usando para ello el Service Manager. Tanto la Base de Datos como el archivo de backup como el archivo de log deben encontrarse en uno de los discos duros del Servidor y cuando se los especifica debe hacerse desde la perspectiva del Servidor, aún cuando se llame a GBAK desde una computadora remota. La ventaja de usar el Service Manager es que el backup y la restauración se hacen muy rápido.

-u[ser] Nombre del usuario de la Base de Datos

-v[erbose] Muestra en la pantalla lo que está haciendo GBAK

-y [nombre_archivo> Crea un archivo de log y escribe todos los mensajes de GBAK que normalmente se mostrarían en la pantalla en el archivo de log. El archivo de log no debe existir. Por lo tanto, si existe, hay que borrarlo antes de ejecutar a GBAK. Si se usa la opción -se[rvice] el archivo de log debe encontrarse sí o sí en uno de los discos duros del Servidor.

-y suppress No muestra los mensajes de GBAK en la pantalla ni los escribe en un archivo de log

-z Muestra la versión de GBAK y del Servidor del Firebird

Las opciones del backup son las que solamente se usan cuando se está realizando el backup y son las siguientes:

-b[ackup_database] Se desea realizar un backup. Es opcional.

-co[nvert] Convierte las tablas externas en tablas internas

-e[xpand] Crea un archivo de backup no comprimido. Por lo tanto, ocupará más espacio en el disco duro

-fa[ctor] n Factor de bloqueo para los dispositivos de cinta

-g[arbage_collect] No recolecta la basura durante el backup, por lo tanto el backup terminará más rápido. Debes usar esta opción cuando inmediatamente después del backup harás un Sweep

-ig[nore] Ignora los checksums mientras realiza el backup

-l[imbo] Ignora las transacciones en limbo mientras realiza el backup

-nt Formato no transportable. Debes usarlo solamente cuando estás 100% seguro que la restauración se hará en el mismo Sistema Operativo y con la misma versión del Firebird

-t[ransportable] Crea un backup que es transportable entre Sistemas Operativos y versiones del Firebird. Es la opción por defecto

Las opciones de la restauración son las que solamente se usan cuando se está restaurando el backup y son las siguientes:

-bu[ffers] Establece el tamaño del caché para la Base de Datos restaurada

-c[reate_database] Restaura a una nueva Base de Datos (el nombre de la nueva Base de Datos no debe existir)

-fix_fss_d[ata] Repara códigos UNICODE_FSS de los datos que estaban mal formados

-fix_fss_m[etadata] Repara códigos UNICODE_FSS de los metadatos que estaban mal formados

-i[nactive] Todos los índices son restaurados como inactivos

-k[ill] No crea los archivos de shadow que fueron definidos en el backup

-mo[de] read_write La Base de Datos restaurada será read/write (o sea: lectura y escritura). Es el valor por defecto

-mo[de] read_only La Base de Datos restaurada solamente podrá ser leída y no se podrán realizar cambios en ella

-n[o_validity] No restaura las restricciones de validación. Sirve para restaurar datos que no cumplen con las restricciones y que no podrían ser restaurados de otra manera

-o[ne_at_a_time] Lo normal es que la restauración se haga en una sola transacción para toda la Base de Datos. El problema es que si se encuentra algún error entonces ninguna tabla será restaurada. Con esta opción se abre una transacción para cada tabla y después de restaurarla se ejecuta el COMMIT. De esta manera se puede restaurar parcialmente una Base de Datos corrupta.

-p[age_size] <tamaño_página> Pone el tamaño de la página de la Base de Datos. Los valores posibles son 4096, 8192, 16384. El valor por defecto es 4096.

-r[eplace_database] Restaura sobre una Base de Datos existente. Esto solamente puede ser realizado por SYSDBA o por el creador de la Base de Datos que será sobre-escrita. ¡¡¡CUIDADO!!! No hay que restaurar sobre una Base de Datos que está siendo usada.

-rep[lace_database] Igual que la opción anterior. Es simplemente una nueva abreviación.

-r[ecreate_database] o[verwrite] Restaura sobre una Base de Datos existente. Solamente puede ser ejecutada por SYSDBA o por el creador de la Base de Datos que será sobre-escrita. Si la Base de Datos está siendo usada el Firebird te lo advertirá porque es algo que no deberías hacer, de todas maneras: debes ser cuidadoso

-use_[all_space] Normalmente cuando se realiza la restauración cada página de la Base de Datos es escrita en un 80%, en cambio si se usa esta opción cada página será llenada al 100%. Es muy útil cuando la Base de Datos restaurada será read-only (y por lo tanto ya no será modificada), porque ahorra mucho espacio en el disco duro.

Ejemplo Nº 1. Un backup normal

GBAK -v -USER SYSDBA -PASSWORD masterkey D:\BASESDATOS\CONTA.FDB D:\BACKUPS\CONTA.FBK

Si en el archivo ALIASES.CONF hemos definido CONTA=D:\BASEDATOS\CONTA.FDB también se podría escribir:

GBAK -v -USER SYSDBA -PASSWORD masterkey CONTA D:\BACKUPS\CONTA.FBK

La opción -v nos muestra en la pantalla lo que está haciendo GBAK.

Ejemplo Nº 2. Un backup con archivo de log

DEL D:\BACKUPS\CONTA.LOG

GBAK -v -USER SYSDBA -PASSWORD masterkey -y D:\BACKUPS\CONTA.LOG D:\BASESDATOS\CONTA.FDB D:\BACKUPS\CONTA.FBK

El archivo de log no debe existir, por eso se lo borra primero. Todo lo que GBAK hubiera mostrado en la pantalla será escrito en el archivo de log, así ese archivo podrá ser revisado cuando se lo necesite.

Ejemplo Nº 3. Una restauración normal

GBAK -c -v -USER SYSDBA -PASSWORD masterkey D:\BACKUPS\CONTA.FBK D:\BASESDATOS\CONTA2.FDB

La Base de Datos restaurada tiene un nombre distinto (CONTA2.FDB) al de la Base de Datos original (CONTA.FDB), esa es la práctica normal y la más recomendada.

Ejemplo Nº 4. Restaurando a una Base de Datos de sólo lectura

GBAK -c -v -mode read_only -use_all_space -USER SYSDBA -PASSWORD masterkey D:\BACKUPS\CONTA.FBK D:\BASESDATOS\CONTA3.FDB

Como -mode es read_only entonces la Base de Datos será de sólo lectura, y como será de sólo lectura entonces se establece que cada página esté llena al 100%, ahorrando así mucho espacio en el disco duro.

Ejemplo Nº 5. Backup y restauración al mismo tiempo

Es muy útil para verificar que el archivo de backup se encuentra en perfecto estado. Un archivo de backup que no se encuentra en perfecto estado puede ser inútil e inservible, por lo tanto una muy buena medida administrativa es verificar que está ok.

GBAK -c [opciones] <base_de_datos_origen> stdout | GBAK -r [opciones] stdin <base_de_datos_destino>

Como puedes ver aquí el programa GBAK se ejecuta dos veces:

  • La primera vez, en lugar de crear al backup en el disco duro (que es lo normal) lo crea en stdout que es la salida estándar (la cual por defecto es la pantalla de la computadora)
  • La barra vertical significa que el programa que se encuentre a continuación (y que en este caso también es GBAK pero podría ser otro) tome como entrada la salida del primer programa ¿en qué lugar? en donde se encuentre stdin
  • El primer GBAK crea el archivo de backup, el segundo GBAK restaura ese archivo de backup

Esta es una forma simplificada de realizar un ciclo backup/restore normal:

  • Con GBAK conectarse a una Base de Datos y crear un archivo de backup
  • Con GBAK leer el archivo de backup y crear una nueva Base de Datos

Artículos relacionados:

Entendiendo a las bases de datos

Entendiendo a los metadatos del programador

Los triggers de la Base de Datos

Haciendo backups con GBAK (1)

Haciendo backups con GBAK (2)

El índice del blog Firebird

El foro del blog Firebird21

 

Delegando el otorgamiento de derechos

9 comentarios

Lo usual es que el creador de la Base de Datos o el usuario SYSDBA se encarguen de otorgarles derechos (también llamados “permisos” o “privilegios”) a los usuarios y a los roles. Sin embargo, en organizaciones grandes esto puede requerir de mucho tiempo entonces tienen la posibilidad de delegar parte de su autoridad en otros usuarios, para que estos otros usuarios también puedan otorgar derechos.

El comando que sirve para otorgar derechos se llama GRANT. A su vez, el comando que sirve para quitar derechos se llama REVOKE y sus sintaxis son las siguientes:

GRANT
   {<privilegios> ON <objeto> | rol}
   TO <beneficiario>
   [WITH {GRANT|ADMIN} OPTION]
   [{GRANTED BY | AS} [USER] otorgador]
REVOKE
   [{GRANT|ADMIN} OPTION FOR]
   {<privilegios> ON <objeto> | rol}
   FROM <beneficiario>
   [{GRANTED BY | AS} [USER] otorgador]

La clásula WITH GRANT OPTION significa que el usuario que recibió ese derecho puede otorgarlo a otros usuarios, si lo desea. Desde luego que solamente puede otorgar los derechos que posee y nada más.

La cláusula WITH ADMIN OPTION se otorga a los roles y significa que el usuario que tiene un rol puede otorgar ese rol a otros usuarios, si lo desea. Por supuesto que solamente puede otorgar su propio rol y nada más.

La cláusula GRANTED BY se usa para que aparezca como otorgador del derecho no quien lo hizo, sino otro usuario. ¿Y por qué se haría eso? Para que ese otro usuario pueda revocar el derecho.

Existe un rol especial, llamado RDB$ADMIN, que le permite a quien lo recibe tener los mismos derechos que el usuario SYSDBA pero solamente en esta Base de Datos. O sea que en la práctica quien posee el rol RDB$ADMIN puede actuar como si fuera el usuario SYSDBA.

Ejemplos:

Conectado como SYSDBA:

GRANT SELECT ON BANCOS TO MARCELA WITH GRANT OPTION;

SYSDBA le otorgó a MARCELA el derecho de hacer SELECT en la tabla BANCOS y también le permite a MARCELA otorgar ese derecho a otros usuarios.

GRANT R_CONTABILIDAD TO SILVIA WITH ADMIN OPTION;

SYSDBA le otorgó a SILVIA el rol R_CONTABILIDAD y también le permite asignar ese rol a otros usuarios.

GRANT RDB$ADMIN TO FATIMA

SYSDBA le otorgó a FATIMA el rol RDB$ADMIN el cual le permite a FATIMA tener todos los derechos sobre todos los objetos de esta Base de Datos. En otras palabras: FATIMA es exactamente igual que SYSDBA en esta Base de Datos, puede hacer todo lo que SYSDBA puede hacer.

GRANT R_CONTABILIDAD TO MARCELA WITH ADMIN OPTION GRANTED BY FATIMA;

SYSDBA le otorgó a MARCELA el rol R_CONTABILIDAD y también le permite otorgar ese rol a otros usuarios, pero lo hizo en nombre de FATIMA. ¿Por qué en nombre de FATIMA? Para que FATIMA pueda, si lo desea, quitarle ese rol a MARCELA.

 Conectado como MARCELA:

GRANT SELECT ON BANCOS TO DIANA;

MARCELA tiene el derecho de otorgar el SELECT a la tabla BANCOS, así que se lo otorga a DIANA. Desde ahora ambas (MARCELA y DIANA) pueden hacer SELECT a la tabla BANCOS.

GRANT INSERT ON BANCOS TO DIANA;

Esto falla y será rechazado por el Firebird porque MARCELA no tiene el derecho de otorgar INSERT en la tabla BANCOS. Ella tiene el derecho de otorgar SELECT en la tabla BANCOS pero no tiene el derecho de otorgar INSERT en la tabla BANCOS y por lo tanto no se le permitirá hacerlo.

GRANT ALL ON BANCOS TO DIANA;

Esto falla por la misma razón: MARCELA solamente puede otorgar el derecho de SELECT y ninguno más. Si intenta otorgar otro derecho entonces será rechazada. Aquí intentó otorgar todos los derechos y fue rechazada.

GRANT SELECT ON PRODUCTOS TO DIANA;

Esto también fallará, porque MARCELA puede otorgar el derecho de hacer SELECT en la tabla BANCOS, pero no puede otorgar el derecho de SELECT en la tabla PRODUCTOS, nunca se le otorgó ese derecho y ella no puede otorgar un derecho que no posee.

REVOKE SELECT ON BANCOS FROM DIANA;

MARCELA le había otorgado el derecho de hacer SELECT en la tabla BANCOS a DIANA, así que MARCELA puede quitarle ese derecho. Desde este momento DIANA ya no podrá hacer SELECT a la tabla BANCOS.

Conectado como SILVIA

GRANT R_CONTABILIDAD TO DIANA;

SILVIA le otorgó el rol R_CONTABILIDAD a DIANA, desde ahora DIANA ya es miembro de ese rol.

GRANT R_CONTABILIDAD TO MIRTHA WITH ADMIN OPTION;

SILVIA le otorgó el rol R_CONTABILIDAD a MIRTHA y también le dió el derecho de asignar ese rol a otros usuarios.

Conectado como FATIMA

GRANT ALL ON PRODUCTOS TO MIRTHA;

Esto falla, no se le permite a FATIMA otorgarle derechos sobre la tabla PRODUCTOS a MIRTHA. ¿Y por qué falla, acaso FATIMA no posee el rol RDB$ADMIN? Sí, pero no lo usó en el momento de conectarse, por eso falló el GRANT.

Conectado como FATIMA y usando el rol RDB$ADMIN

GRANT ALL ON PRODUCTOS TO MIRTHA;

Esto sí funciona ok porque ahora FATIMA se conectó usando el rol RDB$ADMIN y por lo tanto en esta Base de Datos tiene exactamente los mismos derechos que el usuario SYSDBA.

Artículos relacionados:

Agregando, modificando y borrando usuarios

El índice del blog Firebird21