Backups incrementales de Alfresco

1. Procedimiento

Vamos a guardar las copias de las siguientes fechas

-Una supercompleta a dia 1 de Enero del año actual. En esta copia se guardará todo lo que hay en este año y los anteriores. Sirve de copia de seguridad de todo lo anterior. Se llamara:
  
   Alfresco.TOTAL.AAAA.tar siendo AAAA el año anterior


- Una completa del año actual hasta el dia 1 del mes inclusive que se llamará

   Alfresco.AAAAMM01.tar siendo AAAA el año actual y MM el mes actual (01 es el dia)

- Una incremental diaria en base a la del dia 1, a partir del dia 2 el 31 inclusive que se llamará
 
      Alfresco.MMDD.tar siendo MM el mes y DD el dia del mes

Se podria aplicar compresión, pero no queda muy justificada pues los ficheros de alfresco están bastante comprimidos.

2. Pasos

1. Supongamos que tenemos 2 carpetas:

  /opt/mybackup-rsync donde se guarda un rsync diario para hacer copia de seguridad
 /opt/mytars  donde se guardan las copias de seguridad en formato tar

2. Realizar el resync de los datos del servidor
Para ello seguimos los pasos del post anterior. Si hay datos de un rsync previo, tardará menos. Sinó, tardará lo suyo

cd /opt/mybackup-resync  # Nos situamos en la carpeta local donde descargar el backup

rsync -avzh usuarioRemoto@IP:/opt/alfresco-4.2.f/alf_data .   # Ejecutamos la copia

3. Miramos que copia vamos a realizar

3.1 Copia total

Vamos a la carpeta padre y ejecutamos la copia

cd /opt     # vamos a la carpeta padre

tar -cvf mytars/alfresco.TOTAL.2018.tar mybackup-rsync

3.2 Si es copia del año hasta hoy dia 01 de Noviembre de 2019. Para ello ejecutamos  (OJO el formato es mm/dd/aaaa  !!)

find ./mybackup-resync -type f -newermt '01/01/2019 0:00:00'  -exec tar -rvf /mytars/alfresco.20191101.tar "{}" +

parece ser que cambiando "{}" por '{}' también funciona y así es mas fácil de usar en scripts

3.3 Si es copia incremental desde el dia 1 de noviembre del año 2019 hasta hoy dia 29 de Noviembre de 2019. Para ello ejecutamos (OJO el formato es mm/dd/aaaa  !!)

find ./mybackup-resync -type f  -newermt '11/01/2019 0:00:00'  -exec tar -rvf /mytars/alfresco.29.tar "{}" +

parece ser que cambiando "{}" por '{}' también funciona y así es mas fácil de usar en scripts

Copiar un LV (Volumen lógico) o un disco a una máquina remota

1. En modo simple

1.1 Ejecutado desde la máquina que tiene el disco a copiar. Hay que tener en cuenta que el usuario debe de tener permiso sobre el directorio donde se va a grabar la imagen

dd if=/dev/midisco | ssh user@targetServer 'dd of=/path/to/target'

1.2 Ejecutado desde la máquina remota al disco a copiar. A veces el "sudo" remoto puede dar problemas, y puede que en aqlgunos casos se pueda obviar

ssh user@targetServer "sudo dd if=/dev/midisco" | dd of=/path/to/target

En mi caso, copiando un disco de 180Gb con 80Gb de datos y el resto vacío, tardó 27 min.

2. Ajustes finos en el comando dd (tweaks)

Según Rod en el año 2015

2.1 Averiguamos el tamaño de bloque del LV, para ello nos vamos al directorio donde está montado (en este caso /opt ) y ejecutamos

stat -fc %s /opt

y nos devuelve 4096

Como norma tenemos que utilizar un múltiplo de la longitud de bloque!

2.2 Si la seguridad del sistema lo permite, se puede seleccionar una encriptación ssh poco segura pero rápida como arcfour si lo permite tu versión de Openssh, o segun(/dev/blog) aes128-ctr pueden acelerar la conexión. Para ver los cifrados que se pueden realizar ejecutamos

ssh -Q cipher localhost 

y en mi caso devuelve

3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc@lysator.liu.se
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com

vemos que aes126-ctr si está y lo usamos

ssh -c aes128-ctr user@targetServer "sudo dd if=/dev/midisco bs=4M" | dd of=/path/to/target

Pero no se ha visto mejoría!

Lo que si que está claro es que el algoritmo de cifrado 3des-cbc enlentece mucho y no se aconseja usar. Por otra parte  según tdg5 , a él le va mejor un bloque de 128K=131072 (bs=131072) le va un poco mas rápido. Hechas las pruebas, tal vez aumente solo el 1% el rendimiento.

3. ¿Comprimimos?

Si comprimimos, ahorramos disco... pero tardamos 2 horas! o sea se multiplica por 5 el tiempo de la copia. De todas formas se puede intentar.

ssh user@targetServer "sudo dd if=/dev/midisco | gzip -1 -" | dd of=/path/to/target

Hay que tener en cuenta que estoy haciendo una copia de seguridad de Alfresco, y parece ser que los ficheros ya vienen comprimidos, por tanto, poco ganamos con la compresión, excepto para laparte din datos del volumen lógico.

4. Opcion scp. 

OJO: No copia particiones, sino ficheros y/o carpetas

En un blog anterior, queríamos hacer una copia de seguidad de Alfresco y teniendo en cuenta que :
1. Estamos en la máquina local donde queremos copiar la carpeta remota
2. Cuidado econ el scp ya que primero hay que indicar el destino y despues el origen
usábamos:

scp -rp /home/backups.destino/ usuarioRemoto@IP:/opt/alfresco-4.2.f/alf_data

donde las opciones:
  r indica copia recursiva de ficheros y subcarpetas
  p para preservar fechas y autorías de ficheros.

también podemos indicar si queremos compresión la opción C. Pero como hemos dicho en este caso,  poco se gana ya que los ficheros de Alfresco vienen con una tasa de compresión alta.

5. Opción rsync

rsync permite la transferencia rápida de ficheros de forma incremental según el atareao.

Para evitar problemas de borrado, voy a excluir la opción--delete.

Verificar que rsync está instalado tanto en la máquina local como en la remota.

De todas maneras, algunos comandos han tenido que modificarse.  Para ello nos situamos en una carpeta local y después ejecutamos la copia. La primera vez tarda bastante, pero después hace una copia incremental.

cd /mybackup-folder  # Nos situamos en la carpeta local donde descargar el backup

rsync -avzh usuarioRemoto@IP:/opt/alfresco-4.2.f/alf_data .   # Ejecutamos la copia

Para hacer la primera copia se ha tardado 1h-20 min

Compresión de ficheros con tar y otros medios

0. Limitaciones con los ficheros grandes

Para poder manejar ficheros grandes, hay que verificar que:
1. La partición del disco duro permita manejar ficheros grandes LFS (por ejemplo FAT32 NO lo permite), por tanto hay que buscar un formato (ext1?) o buscar en internet los formatos que permitan LFS

1. Usando el tar con compresión

Tar tiene una limitación de 68 Gigas. Por desgracia me di cuenta haciendo un backup de 80 Gigas,

Veamos algunas formas  de comprimir con tar

tar -cf   archive.tar    folder   # Sin compresión
tar -cvf  archive.tar    folder   # Sin compresión (v)erbose

tar -cfJ  archive.tar.xz folder   # compresión xz

tar -cvzf archive.tar.gz folder   # compresión gzip (v)erbose  

tar -cvjf archive.tar.bz2 folder  # compresión bzip2 (v)erbose  

2. Ficheros grandes

Para ello es interesante partir el fichero en trozos mas pequeños. Con 7z se puede hacer, pero tarda lo suyo

7z a archive.7z -vsize[b|k|m|g] folder

La opción -v se le pasa el tamaño y las unidades (b:bytes, k=kbytes, m=megabytes, g=gigabytes). Para tamaño de ficheros de 10G con FAT32 falla, pero va bien con ficheros de 1G, pero las copias se ralentizan mucho.

Probamos con otros compresores (xz, gzib, bzip2), pero no permiten hacer compresión de una carpeta a un solo fichero, ni por tanto hacer split. Para ello se debe hacer en combinación con un tar. Hay que tener cuidado con estos compresores ya que si se utilizan solos, hay que meter la opción -k para que no borre el fichero ofiginal,

SHH : Ejecutar comandos y hacer copias desatendidos de ficheros remotos

0. Introducción

Quiero hacer unas copias de ficheros de forma desatendida desde un servidor remoto.

Para ello se ha pensado en ssh.  Pero cada vez que conectamnos nos pide que introduzcamos a mano una contraseña, con lo que la opción de realizar-lo en un CRON-TAB queda descartada.

1. Opcion 1: sshpass

Se instala este programa y se simula que se introduce la contraseña. Ver serverfault 

$ sudo apt-get install sshpass
$ sshpass -p your_Password12345 ssh user@hostname

No se hasta que punto puede funcionar en sistemas heterogeneos (widows-linux) o si existe una version adecuada a windows de sshpass

2. Opción2: compartición de claves RSA

Para ello se actúa así:

0. Comprobar que esté Openssh instalado tanto en el cliente como en el servidor, ejecutando el comando

ssh -V

1. Generar claves en la màquina local

ssh-keygen -t rsa -b 4096 -R 192.XXX.XXX.XXX              

     # Generating public/private rsa key pair. 
     # Enter file in which to save the key (/home/ximo/.ssh/id_rsa):
     # /home/ximo/.ssh/id_rsa already exists.
     Overwrite (y/n)? n

2. Copiar las claves al servidor remoto

ssh-copy-id myuser@192.XXX.XXX.XXX     
     #/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
     #/usr/bin/ssh-copy-id: INFO: 2 key(s) remain to be installed -- if you are prompted now it is to install the new keys
     
     myuser@192.XXX.XXX.XXX's password: 

     #Number of key(s) added: 2

     #Now try logging into the machine, with:   "ssh 'myuser@192.XXX.XXX.XXX'"
     #  and check to make sure that only the key(s) you wanted were added.

3. Ejecutar el ssh sobre el servidor remoto

ssh myuser@192.XXX.XXX.XXX                 
     # Entramos ya sin pedir contraseña 

========================================================================

Esto que viene a continuación es antiguo y ha quedado desfasado



1. Crear el directorio ~/.ssh en la máquina cliente (Nota ~ es el directorio de usuario /home/myuser).

2. Generar la clave rsa en dicha carpeta del cliente y pedirá una contraseña (por ejempo your_Password12345) que se tendrá que guardar. Se generará en el fichero ~/.ssh/id_rsa.pub

client$    ssh-keygen -q -f ~/.ssh/id_rsa -t rsa

3. Desde el cliente copiamos la clave al servidor remoto

client$    scp ~/.ssh/id_rsa.pub  remoteUser@remoteServer_ip:   # No olvidar los 2 puntos ":"      

y nos pedirá la contraseña de remoteUser (que tiene en el remoteServer)

4. en el servidor hacemos un append (añadimos al final del fichero) dicha clave  al fichero ~/.ssh/authorized_keys y le añadimos finalmente una línea en blanco

server$    cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
server$    echo "" >> ~/.ssh/authorized_keys  # y metemos una linea en blanco!!! MUY IMPORTANTE
server$    rm ~/id_rsa.pub                    # y borramos el fichero que hemos descargado

5. Ejecutamos la primera vez en el cliente el acceso al servidor y nos pedirá la contraseña que le hemos dado al generar la clave rsa (en nuestro caso your_Password12345 )

client$    ssh -o PreferredAuthentications=publickey remoteUser@remoteServer_ip

6. Ya podemos entrar con ssh o scp (para copiar ficheros) y ya no nos vuelve a pedir la contraseña

client$    ssh remoteUser@remoteServer_ip

7. Problema: Si rearrancamos la máquina, nos vuelve a pedir la contraseña !!!

Alfresco Backup

1. El fichero de propiedades "alfresco-global.properties".

En un caso concreto se encuentra en /opt/alfresco-4.2.f/tomcat/shared/classes

Las entradas más importantes son:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72

############################### ## Common Alfresco Properties # ############################### dir.root=/opt/alfresco-4.2.f/alf_data #Instalación alfresco.context=alfresco alfresco.host=0.0.0.0 alfresco.port=8080 alfresco.protocol=http share.context=share share.host=0.0.0.0 share.port=8080 share.protocol=http ### database connection properties ### db.driver=org.postgresql.Driver db.username=myuser db.password=mypassword db.name=alfrescodb db.host=192.168.xx.xx db.port=5432 #db.url=jdbc:postgresql://192.168.28.38/alfresco db.url=jdbc:postgresql://${db.host}:${db.port}/${db.name} ### FTP Server Configuration ### ftp.enabled=true ftp.port=21 ### RMI service ports ### alfresco.rmi.services.port=50500 avm.rmi.service.port=0 avmsync.rmi.service.port=0 attribute.rmi.service.port=0 authentication.rmi.service.port=0 repo.rmi.service.port=0 action.rmi.service.port=0 deployment.rmi.service.port=0 ### External executable locations ### ooo.exe=/program/soffice.bin ooo.enabled=true ooo.port=8100 img.root=/opt/alfresco-4.2.f/common img.dyn=${img.root}/lib img.exe=${img.root}/bin/convert swf.exe=/opt/alfresco-4.2.f/common/bin/pdf2swf swf.languagedir=/opt/alfresco-4.2.f/common/japanese jodconverter.enabled=false jodconverter.officeHome= jodconverter.portNumbers=8100 ### Initial admin password ### alfresco_user_store.adminpassword=110079e729078af9e8a4d2fa6b13ed5c ### E-mail site invitation setting ### notification.email.siteinvite=false ### License location ### dir.license.external=/opt/alfresco-4.2.f ### Solr indexing ### #index.subsystem.name=solr #dir.keystore=${dir.root}/keystore #solr.port.ssl=8443 index.subsystem.name=noindex ### BPM Engine ### system.workflow.engine.jbpm.enabled=false

Obervar que la BD de Postgres puede estar o no en el muismo servidor, y por tanto los usuarios y contraseñas de acceso pueden ser distintos también.

2. Pasos a realizar en un hot Backup de Alfresco

1. Copiar el fichero alfresco-global.properties

2. Hacer Backup de los índices de Solr o Lucene si es el caso ??
En este caso, la línea 68 contiene esta información:

   index.subsystem.name=noindex

Por tanto no se están utilizando los índices de solr o lucene, y no utilizamos la indexación de alfresco y no nos afecta esta apartado

3. Hacer un bakcup de la Base de Datos, en este caso como es Postgres, se hará un pg_dump.
para ello de forma remota se puede hacer segun stackoverflow:

PGPASSWORD="mypassword"   pg_dump -h 192.168.xx.xx -Fc -o -U myuser alfrescodb > /home/backups/alfrescodb.dump

4. Hacer backup de la carpeta indicada en la entrada "dir.root" del fichero de propiedades. En este caso opt/alfresco-4.2.f/alf_data .Para ello usamos ssh

scp -rp /home/backups/ usuarioRemoto@IP:/opt/alfresco-4.2.f/alf_data

Pero .....

3. A tener en cuenta

1. Una copia de seguridad de 80Gb con ficheros pequeños me ha costado alrededor de 2 horas con el scp, por tanto hay que saber en que terreno moverse!

2. Haciendo lo mismo pero con un "ssh y dd" tardamos 20 minutos... Pero tenemos que copiar todo el disco (o LV) y nos ocupa 180 Gb.??

ssh usuarioRemoto@IP "sudo dd if=/dev/midisco" | dd of=image.ximo

3. En un post futuro hablaremos sobre como optimizar la copia de un LV