Nota
En esta es una traducción del articulo llamado Backup der ZODB donde se ofrece la información de como reparar una ZODB.
Usualmente la base de datos de Plone esta configurado en el archivo var/filestorage/Data.fs y los archivos cargados desde la interfaz de Plone pueden encontrarse como BLOBs in var/blobstorage.
Truco
Para mas detalle sobre estos archivos y directorios consulte Directorios de ZODB.
Zope provee un script repozo.py que le permite realizar copias de seguridad de la ZODB durante su funcionamiento.
Para instalaciones Plone 4.3 usando configuraciones buildout bajo Linux se encuentra en el directorio:
Nota
Esto puede variar entre versiones de Plone y Zope.
Advertencia
Ejecutar repozo sólo se puede realizar una copia de seguridad completa de nuevo después de cada compactación de ZODB. El procedimiento de compactación se recomienda realizar con significativamente menos frecuencia que la copia de seguridad.
Para generar una copia de seguridad incremental, primero que debe crear el directorio backups, el cual se usara con el programa repozo con los siguientes comando:
$ mkdir backups
$ ./bin/repozo -BvzQ -r backups -f var/filestorage/Data.fs
Para generar una copia de seguridad completa, se debe realizar los siguientes pasos:
$ ./bin/repozo -BvzF -r backups -f var/filestorage/Data.fs
Zope provee un script repozo.py que le permite no solo realizar copias de seguridad de la ZODB sino también restaurarlas.
Para restaurar una copia de seguridad completa, se debe realizar los siguientes pasos:
En primer lugar detener el servivio del servidor Zope (Zeo y sus clientes o la instancia Zope standalone).
Localiza la ruta donde se hicieron las copias de seguridad incrementales. Para en este articulo usamos backups.
Compruebe que los archivos de copia de seguridad incrementales se encuentran dentro de este directorio. Las secuencias de comandos de copia de seguridad escriben de forma automática la base de datos en el directorio de copia de seguridad en uno de los dos formatos, una copia incremental y una copia de seguridad completa. Puede detectar la diferencia al ver las extensiones de archivo:
Truco
Cree una copia del archivo Data.fs con los posibles objetos corruptos, por previsión.
Entonces ejecute el programa repozo con el siguiente comando:
$ ./bin/repozo -Rv -r backups -o var/filestorage/Data.fs
El resultado de la ejecución de comando debería ser algo así:
looking for files between last full backup and 2006-06-23-19-39-20... files needed to recover state as of 2006-06-23-19-39-20: /srv/plone/instance/backups/2006-06-23-18-49-47.fs /srv/plone/instance/backups/2006-06-23-18-55-56.deltafs Recovering file to /srv/plone/instance/var/filestorage/Data.fs Recovered 6435866 bytes, md5: 4470d48dfeae1f6201cc594142408bfe
Esto comando examina las copias de seguridad disponibles, busca el mas reciente y mezcla cualquier copia de seguridad incremental (si esta presente). Ademas este creará un archivo Data.fs en la ubicación especificada con el parámetro -o en base a las copias de seguridad realizadas por repozo del repositorio llamado backups especificado con el parámetro -r.
Por ultimo, asegúrese de iniciar el servidor Zope (Zeo y al menos un cliente o la instancia Zope standalone.
A veces, es necesario retroceder en el tiempo y recuperar datos perdidos, o crear una base de datos de pruebas de las copias de seguridad de los datos de producción.
Para recrear el archivo de datos para una fecha en particular utilice el programa repozo, primero que debe tener acceso al repositorio de copias de seguridad (en este articulo usamos backups), el cual se usara con el programa repozo con el siguiente comando:
$ ./bin/repozo -R --r backups --date='2014-07-02' -o var/filestorage/Data.fs
Esto comando creará un archivo Data.fs en la ubicación especificada con el parámetro -o en base a las copias de seguridad realizadas por repozo del repositorio llamado backups especificado con el parámetro -r y con la fecha especifica 2014-07-02 usando el parámetro --date.
Truco
Yo siempre uso la fecha de mañana para –date=’yyyy-mm-dd’ fin de obtener todos los cambios del día de hoy.
Nota
El detalle del parámetro --date se puede consultar en la referencia de recuperar de copia de seguridad de repozo.
Además, se puede personalizar con programa repozo.py para crear copias de seguridad incrementales y completas, usando la receta plone.recipe.zope2instance crea una envoltura del script repozo.py que genera con el nombre repozo en el directorio bin.
También se puede crear de forma automática una tarea de este comando de respaldo de datos con la receta z3c.recipe.usercrontab. Para este propósito, inscrita en el archivo buildout.cfg la siguiente configuración:
[buildout]
parts =
...
backup-crontab
[backup-crontab]
recipe = z3c.recipe.usercrontab
times = 15 0 * * *
command =
${buildout:bin-directory}/repozo -BvzQ -r ${buildout:directory}/backups \
-f ${buildout:directory}/var/filestorage/Data.fs
Con la receta collective.recipe.backup puede crear un script que puede crear copias de seguridad de múltiples ZODBs. Además crear catálogo separado para su propia ZODB.
[buildout]
parts =
...
backup
[backup]
recipe = collective.recipe.backup
additional_filestorages =
Extra
Super
Para realizar copias de seguridad a múltiples puntos de montaje se utiliza la receta collective.recipe.filestorage, en la sección [backup] también se puede simplificar:
[backup]
recipe = collective.recipe.backup
additional_filestorages = ${mountpoints:parts}
Las siguientes opciones adicionales proporciona la receta collective.recipe.backup:
Lugar donde se almacenan las copias de seguridad.
El valor por defecto es var/backups dentro del directorio Buildout.
El uso explícito de location es importante tener en cuenta que la última parte de la especificación se usa como prefijo. La declaración:
location = ${buildout:directory}/backups
Allí en la carpeta de proyectos buildout las sub-carpetas generadas backups_Catalog y backups_Extra. Este contendrá la copia de seguridad de cada base de datos.
Número de copias de seguridad completas que se conservan.
El valor por defecto es 2.
Todas las copias de seguridad anteriores, incluyendo sus copias de seguridad incrementales se eliminan automáticamente.
Si el valor se establece en 0, todas las copias de seguridad se mantienen.
Lugar donde se guardan los respaldos de datos snapshot.
El valor por defecto es var/snapshotbackups dentro del directorio Buildout. En definición explícita se aplicarán respecto la ruta de las mismas reglas para el prefijo de carpeta, como en location.
El valor por defecto es true.
El final está comprimido las ZODB en formato *.fsz y no *.fs.gz.
Al usar la receta collective.recipe.backup este patrón cambia en la directiva command bajo la sección [backup-crontab] como se muestra a continuación:
[backup-crontab]
command = ${buildout:bin-directory}/backup -q
Las copias de seguridad antiguas se deben eliminar después de un cierto tiempo. En este ejemplo, las siguientes copias de seguridad incrementales después de dos semanas y copias de seguridad completas después de cinco semanas se eliminan:
[buildout]
parts =
...
remove-incremental-backups
remove-full-backups
[remove-incremental-backups]
recipe = z3c.recipe.usercrontab
times = 8 0 * * *
command = find ${buildout:directory}/backups -name \*deltafs -ctime +14 -delete
[remove-full-backups]
recipe = z3c.recipe.usercrontab
times = 8 0 * * *
command = find ${buildout:directory}/backups -name \*dat -ctime +35 -delete
Puede comprobar la definición de las tareas crontab ejecutando el siguiente comando:
$ crontab -l
Nosotros podemos realizar copias de seguridad de blob storage. Desde la versión 4.0 en Plone normalmente todas las imágenes y los archivos (Binary large objects - Blob) se almacenan en el sistema de archivos. En Plone 3 es opcional. Por lo tanto también necesita copias de seguridad de este almacenamiento blob.
Con la receta collective.recipe.backup partir de la versión 2.0 también puede ser crear copias de seguridad del almacenamiento Blob.
Si no se especifica el directorio donde Plone (o Zope) almacena sus blobs en la receta plone.recipe.zope2instance también puede especificar explícitamente la ruta del directorio con la declarativa blob_storage de la receta collective.recipe.backup:
[buildout]
parts =
instance
backup
[instance]
recipe = plone.recipe.zope2instance
user = admin:admin
blob-storage = ${buildout:directory}/var/blobstorage
[backup]
recipe = collective.recipe.backup
Si es necesario, buildout puede crear varios scripts para crear los archivos de copia de seguridad para los ZODBs y los almacenamientos blob:
[buildout]
parts =
...
filebackup
blobbackup
[filebackup]
recipe = collective.recipe.backup
backup_blobs = false
[blobbackup]
recipe = collective.recipe.backup
blob_storage = ${buildout:directory}/var/blobstorage
only_blobs = true
Los siguientes atributos se añadieron nuevos:
Directorio donde se guardan los blob-storage.
Esta opción se ignora si backup_blobs = false.
Si nada es especificado para blob-storage, se intenta para determinar un valor de una sección que utilice en las siguientes recetas:
Directorio donde se almacenan los archivos de copia de seguridad.
El valor por defecto es var/blobstoragebackups dentro del directorio Buildout.
Directorio donde se crean las copias de seguridad snapshots.
El valor por defecto es var/blobstoragesnapshots en Directorio Buildout.
Esto sólo creara una copia de seguridad de los Blob-Storages, no los ZODBs.
El valor por defecto es false.
Use el programa rsync con Hard Links para crear las copias de seguridad de blob.
El valor por defecto es true.
Si el programa rsync no está instalado, o debido a que los Hard Links no funcionan (Windows), en este caso el atributo debe establecerse en false. Entonces se crea una copia simple con shutil.copytree de Python.
Actualmente los tipos soportados por la receta collective.recipe.backup no Blob-Storages adicionales. Para esto posiblemente tendría que ser creado su propia sección Buildout, lo que crea un segundo conjunto de scripts de copia de seguridad, por ejemplo:
[extrablobbackup]
recipe = collective.recipe.backup
blob_storage = ${buildout:directory}/var/extrablobstorage
only_blobs = true
De uso común es la receta collective.recipe.backup y la herramienta rsync para crear la copia de seguridad. Aquí se conocen. Los hard links creados para ahorrar espacio en disco y crear copias de seguridad incrementales. Sin embargo, para esto se requiere de Linux / Unix o Mac OS X.
Con el programa rsync ahora también puede ser usado para crear copias de seguridad en servidores remotos: usando el script rsync-backup.sh.
Para el sistema operativo Windows, debería ejecutarse usando el programa Cygwin. Si no, puede establecerse esto use_rsync = false y el directorio de almacenamiento de blob se copia a continuación de la copia de seguridad.
Alternativamente, se utiliza la receta collective.recipe.rsync. Para este propósito, por ejemplo, cree el archivo rsync.cfg con la siguiente contenido:
[rsync-file]
recipe = collective.recipe.rsync
source = TUSITIO.COM:/srv/www.TUSITIO.COM/var/filestorage/Data.fs
target = var/filestorage/Data.fs
script = true
[rsync-blob]
recipe = collective.recipe.rsync
source = TUSITIO.COM:/srv/www.TUSITIO.COM/var/blobstorage/
target = var/blobstorage/
script = true
Truco
Para obtener más información sobre el comando rsync consulte el artículo de Mike Rubel: Easy Automated Snapshot-Style Backups with Linux and Rsync.
El código fuente de este archivo esta hospedado en GitHub. Todos pueden actualizar y corregir errores en este documento con unos clic - sin necesidad de descargar.
Para mas información básica acerca de como actualizar este manual y referencia a sintaxis Sphinx, por favor consulte la guía Escribiendo y actualizando el manual.