A partir de la versión 8.2 de Bacula Enterprise, los clientes pueden realizar copias de seguridad automáticas de las Snapshots del sistema de archivos. También es posible administrar Snapshots de los sistemas a través de las interfaces de Bacula.
El plugin proporciona restauración a nivel de archivo en el estado de generación de la snapshot, con total garantía de integridad. Esta función puede ser muy útil para realizar copias de seguridad integradas con grandes bases de datos MySQL, PostgreSQL, MongoDB, etc.
Actualmente, se admiten los siguientes backends de Snapshots:
- BTRFS
- ZFS
- LVM
De forma predeterminada, las Snapshots se montan (o están disponibles directamente) en el directorio .snapshots del sistema de archivos raíz. (En ZFS, el valor predeterminado es .zfs/snapshots).
El programa de back-end Snapshot se llama bsnapshot y está disponible en el paquete bacula-enterprise-snapshot. Para utilizar la función de administración de Snapshots, el paquete debe estar instalado en el cliente.
El programa bsnapshot se puede configurar usando el archivo /opt/bacula/etc/bsnapshot.conf. Los siguientes parámetros se pueden ajustar en el archivo de configuración:
- sudo = <yes∣no> Usa sudo para ejecutar comandos
- disabled = <yes∣no> Deshabilitar la compatibilidad con Snapshots
- retry = Establecer el número de reintentos para algunas operaciones
- snapshot_dir = Use un nombre personalizado para el directorio de Snapshots. (.SNAPSHOT, .snapdir, etc.)
- lvm_snapshot_size = Especifique un tamaño de instantánea personalizado para un volumen LVM dado
- mountopts = Especifica una opción de montaje personalizada para un dispositivo determinado (disponible en 10.0.4)
- trace = Especifique un archivo de seguimiento
- debug = Especificar un nivel de depuración
Hay un ejemplo como sigue:
# cat /opt/bacula/etc/bsnapshot.conf trace=/tmp/snap.log debug=10 lvm_snapshot_size=/dev/ubuntu-vg/root:5% mountopts=nouuid mountopts=/dev/ubuntu-vg/root:nouuid,nosuid
Quiesce de Aplicación
Al utilizar Snapshots, es muy importante desactivar las aplicaciones que se ejecutan en el sistema. La forma más sencilla de desactivar una aplicación es detenerla. Por lo general, tomar la instantánea es muy rápido y el tiempo de inactividad dura solo unos segundos.
Si el tiempo de inactividad no es posible y/o la aplicación proporciona una forma de deshabilitar, se puede usar un script más avanzado. A continuación se describe un ejemplo.
Directivas de Nuevos Directores
El uso del Plugin de Snapshot en FileDaemon está determinado por la nueva directiva Enable Snapshot FileSet. El valor predeterminado es no.
FileSet {
Name = LinuxHome
Enable Snapshot = yes
Include {
Options = { Compression = LZO }
File = /home
}
}
De forma predeterminada, las Snapshots se excluyen del cliente al final de la copia de seguridad. Para mantener las instantáneas en el cliente y guardarlas en el catálogo durante un período determinado, es posible utilizar la directiva SnapshotRetention en los recursos del Client o del Job. El valor predeterminado es 0 segundos. Si, para un Job determinado, se establecen las directivas de retención de Snapshots de Client y Job, se utilizará la directiva de Job.
Client {
Name = linux1
...
Snapshot Retention = 5 days
}
Para eliminar instantáneas automáticamente, puede utilizar el siguiente comando RunScript:
Job {
...
Client = linux1
...
RunScript {
RunsOnClient = no
Console = "prune snapshot client=%c yes"
RunsAfter = yes
}
}
En RunScripts, la palabra clave AfterSnapshot de la directiva RunsWhen permitirá que se ejecute un comando inmediatamente después de que se cree la snapshot. AfterSnapshot es un sinónimo de la palabra clave AfterVSS.
Job {
...
RunScript {
Command = "/etc/init.d/mysql start"
RunsWhen = AfterSnapshot
RunsOnClient = yes
}
RunScript {
Command = "/etc/init.d/mysql stop"
RunsWhen = Before
RunsOnClient = yes
}
}
Información de Salida del Job
La lista de todos los dispositivos utilizados por el Plugin de Snapshots se muestra en el log del Job y indica si había Snapshots disponibles.
JobId 3: Create Snapshot of /home/build JobId 3: Create Snapshot of /home/build/subvol JobId 3: Delete snapshot of /home/build JobId 3: Delete snapshot of /home/build/subvol ... JobId 3: Bacula 127.0.0.1-dir 7.2.0 (23Jul15): Build OS: x86_64-unknown-linux-gnu archlinux JobId: 3 Job: Incremental.2015-02-24_11.20.27_08 Backup Level: Full ... Snapshot/VSS: yes ... Termination: Backup OK
Nuevos Comandos snapshot de bconsole
El nuevo comando snapshot mostrará el siguiente menú por defecto:
*snapshot
Snapshot choice:
1: List snapshots in Catalog
2: List snapshots on Client
3: Prune snapshots
4: Delete snapshot
5: Update snapshot parameters
6: Update catalog with Client snapshots
7: Done
Select action to perform on Snapshot Engine (1-7):
El comando snapshot también puede tener los siguientes parámetros:
[client=<client-name> | job=<job-name> | jobid=<jobid>] [delete | list | listclient | prune | sync | update]
También puede utilizar los comandos tradicionales list, llist, update, prune o delete en Snapshots.
*llist snapshot jobid=5
snapshotid: 1
name: NightlySave.2015-02-24_12.01.00_04
createdate: 2015-02-24 12:01:03
client: 127.0.0.1-fd
fileset: Full Set
jobid: 5
volume: /home/.snapshots/NightlySave.2015-02-24_12.01.00_04
device: /home/btrfs
type: btrfs
retention: 30
comment:
* snapshot listclient
Automatically selected Client: 127.0.0.1-fd
Connecting to Client 127.0.0.1-fd at 127.0.0.1:8102
Snapshot NightlySave.2015-02-24_12.01.00_04:
Volume: /home/.snapshots/NightlySave.2015-02-24_12.01.00_04
Device: /home
CreateDate: 2015-02-24 12:01:03
Type: btrfs
Status: OK
Error:
Para actualizar el catálogo con las snapshots del cliente (o snapshot sync), el Director contacta con FileDaemon, enumera las snapshots del sistema y crea registros de catálogo de las instantáneas.
*snapshot sync
Automatically selected Client: 127.0.0.1-fd
Connecting to Client 127.0.0.1-fd at 127.0.0.1:8102
Snapshot NightlySave.2015-02-24_12.35.47_06:
Volume: /home/.snapshots/NightlySave.2015-02-24_12.35.47_06
Device: /home
CreateDate: 2015-02-24 12:35:47
Type: btrfs
Status: OK
Error:
Snapshot added in Catalog
*llist snapshot
snapshotid: 13
name: NightlySave.2015-02-24_12.35.47_06
createdate: 2015-02-24 12:35:47
client: 127.0.0.1-fd
fileset:
jobid: 0
volume: /home/.snapshots/NightlySave.2015-02-24_12.35.47_06
device: /home
type: btrfs
retention: 0
comment:
Restricciones del Back-End LVM
LasSnapshots LVM son bastante primitivas en comparación con ZFS, BTRFS, NetApp y otros sistemas. Por ejemplo, no es posible utilizar Snapshots si el grupo de volumen (VG) está lleno. El administrador debe mantener algo de espacio libre en el VG para crear Snapshots.
La cantidad de espacio libre necesario depende de la actividad del volumen lógico (LV). Bsnapshot usa el 10% del LV de forma predeterminada. LV puede configurar este número en el archivo bsnapshot.conf.
[root@system1]# vgdisplay --- Volume group --- VG Name vg_ssd System ID Format lvm2 ... VG Size 29,81 GiB PE Size 4,00 MiB Total PE 7632 Alloc PE / Size 125 / 500,00 MiB Free PE / Size 7507 / 29,32 GiB ...
Tampoco es recomendable dejar Snapshots en el backend de LVM. Tener varias instantáneas del mismo LV en el LVM ralentizará el sistema.
Opciones de Depuración
Para obtener información de bajo nivel sobre el bsnapshot, se debe usar la TAG de depuración «snapshot» en el comando setdebug.
*setdebug level=10 tags=snapshot client *setdebug level=10 tags=snapshot dir
Disponível em: 
Português (Portugués, Brasil)
English (Inglés)
Español
