Timeline
Feb 8, 2013:
- 2:17 PM Ticket #12 (Ejemplo de un commit de una modificación de fichero en /etc/bacula) created by
-
Pongo aquí un ejemplo de como subir al repositorio svn un commit de un fichero que se ha modificado. Los commit hay que hacerlos cuando se ha comprobado que el cambio va bien, para que queden reflejadas las diferencias con las versiones anteriores y así quede documentado el cambio y todo el mundo pueda ver el histórico de cambios.
En este caso ha cambiado el fichero bacula-sd.conf. Lo sabemos porque "svn status" nos devuelve su nombre precedido por M (modificado).
Con "svn diff bacula-sd.conf", podemos ver las diferencias con la versión que está en el repositorio. Todos estos comandos svn se ejecutan estando en /etc/bacula.
Para subir el commit hacemos (de hecho yo lo he hecho ya):
svn ci bacula-sd.conf -m "Cambiado /dev/sg7 por /dev/changer"
Esto nos dice: "Committed revision 3.".
Ahora podemos referenciar aquí en el trac esa revisión poniendo [3] simplemente. Y si pinchamos en este enlace nos aparece muy bonita la comparación de los ficheros cambiados con los antiguos.
- 1:59 PM Ticket #2 (Probar purgado de parte del catalogo de la BBDD y reconstrucción) closed by
- fixed
Feb 5, 2013:
- 12:48 PM Breve tutorial de SVN edited by
- (diff)
- 12:47 PM Breve tutorial de SVN edited by
- (diff)
- 12:47 PM Breve tutorial de SVN edited by
- (diff)
- 10:53 AM Ticket #11 (Comandos de actualización de SVN) closed by
- fixed
- 10:40 AM Breve tutorial de SVN edited by
- (diff)
- 10:35 AM Breve tutorial de SVN created by
- 10:35 AM WikiStart edited by
- (diff)
- 9:37 AM WikiStart edited by
- (diff)
- 9:36 AM Guía sobre el uso del trac created by
- 9:36 AM WikiStart edited by
- (diff)
- 9:12 AM Ticket #11 (Comandos de actualización de SVN) created by
-
Para quien lo maneje mejor, que nos indique los comandos básicos para la gestión del SVN desde el cliente !!
- 8:54 AM Ticket #10 (Ubicación de los ficheros de configuración de bácula) created by
-
Al objeto de meterlos en svn, es necesario saber cuales son los ficheros implicados y donde están.
Pongo a Pepe en copia para que los ponga aquí.
Feb 4, 2013:
- 1:15 PM Ticket #9 (Condiciones de visibilidad de un medio para bácula) created by
-
Para que Bacula utilize una cinta (un volumen), han de cumplirse dos condiciones:
1.- que tenga una cabecera de volumen colocada por bacula; es decir, haya sido etiquetado
2.- que su etiqueta y el 'slot' que ocupa esté almacenado en el catálogo y que el volumen esté marcado como 'InChanger?' (si no se ve hay que usar update slots=n1,n2,...).
Por defecto, los scripts que se proporcionan pueden manejar un autocargador cuyos 'slots' se comparten por todos los 'drives', si se quieren definir grupos de slots exclusivos para cada 'drive' habría que modificar la macro 'mtx-changer' (aunque no lo he hecho, creo que es posible).
- 10:27 AM Ticket #8 (Limitar a arcserve la visibilidad de determinados slots (y drives) de ...) created by
-
Como no tenemos licencia de particionamiento de la librería neo, tenemos que hacerlo a mano. En arcserve es importante que vea solo determinados slots y determinados drives para que no tenga la tentación de descargar una cinta de bácula de alguna lectora que no deba.
En cualquier caso debemos asumir que las recuperaciones de arcserve serán muy manuales y auditadas de manera que quien las haga se asegure de que no entre en conflicto con bácula y sus medios.
- 10:24 AM Ticket #7 (Limitar a bácula la visibilidad a determinados slots de una librería.) created by
-
Para que vea solo determinados slots.
- 10:22 AM Ticket #6 (Definición del procedimiento para migrar de Arcserve a Bácula.) created by
- 10:10 AM Ticket #5 (Definir y probar la automatización de migrado de trabajos de backup de ...) created by
-
Actualmente en arcserve estamos usando un modelo de backup llamado D2D2T (disk to disk to tape) (http://en.wikipedia.org/wiki/Disk_staging), que se llama también "disk staging", de hecho arcserve le llama así.
Las ventajas principales de este sistema son:
- El destino del backup al ser disco no resulta limitante en la velocidad.
- Se elimina la necesidad de hacer multiplexación en las cintas, ya que las sesiones se migran posteriormente de forma secuencial. Esto reduce el efecto del "shoe shinning" en las cintas aumentando su velocidad y durabilidad.
- La tasa de éxito del backup aumenta al ser el disco un elemento menos susceptible a fallo que uno tan mecánico como las librerías de cinta.
- La velocidad de recuperación de datos recientes aumenta mucho al hacerse de disco y no de cinta.
El objetivo de este ticket es ver como implementa el staging bácula, como hay que configurarlo, que necesidades tiene y hacer las pruebas correspondientes.
- 10:04 AM Ticket #4 (Hacer sitio en la NAS antigua para pool de backup de bácula) created by
-
Al objeto de realizar los backups contra disco inicialmente.
- 10:02 AM Ticket #3 (Probar la migración de medios entre librerías) created by
-
El escenario sería:
- Hemos realizado una serie de trabajos de backups contra la librería IBM en cintas LTO5. En un momento dado pasamos a usar la librería NEO4000 con cintas LTO4 y queremos migrar las cintas de la primera a la segunda.
Lógicamente al ser de menor capacidad se usarán el doble de cintas. Aparte hay que comprobar como queda todo esto en la BBDD (o catálogo). Si bácula identifica que un determinado fichero o una sesión de backup está disponible en dos conjuntos de cintas.
También hay que tener claro como nos permite seleccionar un conjunto u otro.
