Una de las tareas más importantes del administrador de Alfresco es planificar una correcta estrategia de backup
En Alfresco nos encontramos con diferentes elementos sobre los que hacer backup:
Datos estáticos:
- Servidor de aplicaciones
- Ficheros de configuración y personalización de Alfresco
Datos dinámicos:
- Almacen de datos.
- Índices.
- Metadatos.
Vistas las dependencias que hay entre ellos en el
articulo de arquitectura se entiende que no es posible restaurar Alfresco si no se dispone de la base de datos o del almacén. El caso de los índices es caso a parte puesto que es posible regenerarlos teniendo los otros dos elementos, pero este proceso puede llegar a ser costoso en tiempo dependiendo del volumen de datos (puede llegar al orden de días si el volumen es grande).
El almacen de datos es el directorio al que apunta la propiedad dir.root
Los índices están ubicados en el directorio apuntado por lucene-indexes aunque estos no deben ser copiados para evitar tener datos corruptos. En su lugar se debe copiar el directorio backup-lucene-indexes el cual es una copia que se realiza de forma automática a las 03:00 am.
Es importante tener en cuenta que la copia de este directorio debe producirse preferentemente después de esta hora. Si es necesario es posible cambiar la hora de este job en el fichero
scheduled-jobs-context.xml:
<bean id="indexBackupTrigger" class="org.alfresco.util.CronTriggerBean">
<property name="jobDetail">
<ref bean="indexBackupJobDetail" />
</property>
<property name="scheduler">
<ref bean="schedulerFactory" />
</property>
<!-- trigger at 3am each day -->
<property name="cronExpression">
<value>0 0 3 * * ?</value>
</property>
</bean>
La base de datos debe ser copiada con las herramientas que proporcione el fabricante o terceros.
De esta forma el backup se podría resumir en:
- Hacer backup de backup-lucene-indexes
- Hacer backup de base de datos
- Hacer backup de la ubicación del almacen de datos
Es muy importante realizar las copias de seguridad en el orden indicado arriba por varios motivos, imaginemos que se sube un fichero durante la copia:
- Si se crea una entrada en la base de datos después de realizar el backup de índices se puede regenerar el índice de la última transacción realizada con la reindexación en modo AUTO.
- Si tenemos un fichero que existe en base de datos pero no en el sistema de ficheros tendremos un nodo huerfano. Aparecería en Alfresco como si existiera pero tendriamos un error al intentar abrirlo.
- Si existe en el sistema de ficheros pero no en base de datos tendriamos un fichero sin referenciar pero mantendriamos la coherencia de los datos.
Restauración completa
Los pasos que deberemos seguir para recuperar una copia completa serán:
- Parar Alfresco
- Mover dir.root a otra ubicación si es posible/necesario
- Mover backup-lucene-indexes a lucene-indexes, si la copia automática es buena se puede utilizar la misma que esté en el servidor, en caso contrario se tendrá que usar la del último backup
- Restaurar la base de datos
- Arrancar Alfresco
Si tenemos una copia valida de
backup-lucene-indexes y la propiedad index.recovery.mode=AUTO se generaran los indices de los elementos subidos después de la última copia ahorrandonos mucho tiempo en el arranque.
Restauración de un documento
Si queremos recuperar un documento que ya hemos eliminado de la papelera, es posible recuperarlo a partir de una consulta a la base de datos que nos indique cual es la ubicación en el sistema de ficheros del documento.
Recordatorio del proceso de borrado de ficheros en Alfresco
Para ello deberemos recuperar la base de datos completa desde la última copia y a continuación ejecutar la siguiente consulta, que en mi caso va a recuperar el fichero 'trashcleaner-0.0.2.amp':
select a.node_id,
a.string_value,
e.content_url
from
alf_node_properties a,
alf_qname b,
alf_content_data c ,
alf_node_properties aa,
alf_content_data d,
alf_content_url e
where
a.string_value='trashcleaner-0.0.2.amp' and
a.qname_id=b.id and
b.local_name='name' and
c.id=aa.long_value and
aa.node_id=a.node_id and
aa.long_value=d.id and
d.content_url_id=e.id;
Esto nos devuelve el id del nodo, el nombre del fichero y la ubicación en disco:
+---------+------------------------+------------------------------------------------------------------+
| node_id | string_value | content_url |
+---------+------------------------+------------------------------------------------------------------+
| 551 | trashcleaner-0.0.2.amp | store://2011/5/26/10/14/5579b1ba-a7f7-4a5e-a5d2-e5c1b27afe3c.bin |
+---------+------------------------+------------------------------------------------------------------+
podremos encontrar el contenido en el directorio:
alf_data/contentstore/2011/5/26/10/14/5579b1ba-a7f7-4a5e-a5d2-e5c1b27afe3c.bin
Si esta consulta nos devolviera varios valores porque tuvieramos el fichero en varios espacios podríamos mirar el espacio del que cuelga con la siguiente consulta buscando por el identificador del nodo:
select c.string_value
from
alf_child_assoc a,
alf_qname b,
alf_node_properties c,
alf_qname bb
where
child_node_id=
551 and
a.type_qname_id=b.id and
b.local_name='contains' and
a.parent_node_id=c.node_id and
c.qname_id=bb.id and
bb.local_name='name';
+--------------+
| string_value |
+--------------+
| Sistemas |
+--------------+
1 row in set (0.00 sec)
Para consultas más complejas, como por ejemplo filtrar por tipo de contenido, o documentos versionados y demás recomiendo la descarga de
Mysql Workbench para sacar un Diagrama EER y poder ver de una forma visual las dependencias que existen entre cada una de las tablas.
La clave en este punto es que el la tabla
alf_node_properties tiene un long_value, el cual es el ID para una columna en la tabla
alf_content_data que referencia a la tabla
alf_content_url
Aqui teneis el diagrama para esta consulta:
