Timeline
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.
Feb 1, 2013:
- 2:28 PM Ticket #2 (Probar purgado de parte del catalogo de la BBDD y reconstrucción) created by
-
La prueba consistirá en ver como se puede recuperar parte del catálogo de un trabajo (sesión) sin tener que recuperar la BBDD completa de ese día ni usar el comando Bscan (si es que es posible)
- 2:20 PM Ticket #1 (Pruebas previas a la puesta en explotación) created by
-
Aquí iran como hijos todos los tickets de las pruebas que hay que hacer
- 2:19 PM WikiStart edited by
- (diff)
- 1:49 PM TracModWSGI created by
- 1:49 PM PageTemplates created by
- 1:49 PM TracGuide created by
- 1:49 PM CamelCase created by
- 1:49 PM TracIni created by
- 1:49 PM TracNotification created by
- 1:49 PM TracTicketsCustomFields created by
- 1:49 PM TracPlugins created by
- 1:49 PM TracRevisionLog created by
- 1:49 PM TracPermissions created by
- 1:49 PM WikiNewPage created by
- 1:49 PM TracLogging created by
- 1:49 PM TitleIndex created by
- 1:49 PM TracWiki created by
- 1:49 PM TracLinks created by
- 1:49 PM WikiHtml created by
- 1:49 PM TracImport created by
- 1:49 PM TracRepositoryAdmin created by
- 1:49 PM TracSupport created by
- 1:49 PM RecentChanges created by
- 1:49 PM WikiFormatting created by
- 1:49 PM TracQuery created by
- 1:49 PM TracBackup created by
- 1:49 PM TracNavigation created by
- 1:49 PM TracCgi created by
- 1:49 PM TracFineGrainedPermissions created by
- 1:49 PM TracBrowser created by
- 1:49 PM TracSyntaxColoring created by
- 1:49 PM WikiProcessors created by
- 1:49 PM TracAccessibility created by
- 1:49 PM WikiRestructuredText created by
- 1:49 PM TracFastCgi created by
- 1:49 PM TracRoadmap created by
- 1:49 PM InterTrac created by
- 1:49 PM TracWorkflow created by
- 1:49 PM WikiDeletePage created by
- 1:49 PM TracEnvironment created by
- 1:49 PM TracTimeline created by
- 1:49 PM TracUpgrade created by
- 1:49 PM InterWiki created by
- 1:49 PM TracStandalone created by
- 1:49 PM TracRss created by
- 1:49 PM TracTickets created by
- 1:49 PM TracAdmin created by
- 1:49 PM TracSearch created by
- 1:49 PM TracChangeset created by
- 1:49 PM TracInstall created by
- 1:49 PM WikiMacros created by
- 1:49 PM WikiStart created by
- 1:49 PM InterMapTxt created by
- 1:49 PM WikiRestructuredTextLinks created by
- 1:49 PM TracModPython created by
- 1:49 PM TracUnicode created by
- 1:49 PM TracInterfaceCustomization created by
- 1:49 PM SandBox created by
- 1:49 PM WikiPageNames created by
- 1:49 PM TracReports created by