Lentitud en las copias con Amazon AWS S3 – Solucionado

Tenía un script que realizaba una copia de seguridad de toda la instancia Linux  EC2 y tardaba casi dos días en copiar 7GB.

Lo que he visto es que S3 es muy rápido copiando pocos archivos grandes pero es extremadamente lento copiando muchos archivos pequeños. Detecté que los filesystems /proc y /dev, principalmente, eran el causantes de tanta lentitud. Además, estos filesystems tampoco son necesarios copiarlos.

Según el artículo Amazon S3 Performance Tips & Tricks + Seattle S3 Hiring Event, es una buena práctica poner diferentes nombres a los directorios de copia para que se guarden en diferentes particiones de S3 y no todos los datos en la misma, por ejemplo, agrupar por ID de usuario.

En mi caso concreto, lo que hice para solucionar el problema fue un script que únicamente copiaba los directorios que realmente se deben copiar y no todos los del sistema operativo. Es el siguiente:

[root@prt53ws1 backup]# cat backup2.0.sh
#!/usr/bin/sh

YEAR=$(date +%Y)
MONTH=$(date +%m)
DAY=$(date +%d)

echo «Inicio de la copia » $(date)
cd /

# Excluimos los directorios que no queremos copiar con grep -v
for FD in `ls -l / |grep -v proc |grep -v sys |grep -v tmp |awk ‘{print $9}’ |grep -v MySQL |grep -v dev |grep -v ^$`
do
echo Copiando $FD
/usr/bin/aws s3 sync $FD s3://puerto53com-backup/$YEAR/$MONTH/$DAY-full/$FD –storage-class STANDARD_IA –region eu-west-1 –endpoint-url http://puerto53com-backup.s3-accelerate.amazonaws.com

done

echo «Final de la copia » $(date)
[root@prt53ws1 backup]#

La copia ha pasado a tardar 25 minutos (antes casi dos días):

[root@prt53ws1 backup]# egrep «Inicio|Final» nohup.out
Inicio de la copia Thu Oct 11 09:49:40 CEST 2018
Final de la copia Thu Oct 11 10:15:00 CEST 2018
[root@prt53ws1 backup]#

Pero lo mejor es que, como utilizo sync las siguientes copias únicamente sincronizan los datos que han sido modificados desde la última vez, así que tiene que copiar menos y, por lo tanto, dura menos (dos minutos):

[root@prt53ws1 backup]# egrep «Inicio|Final» nohup.out
Inicio de la copia Thu Oct 11 11:12:14 CEST 2018
Final de la copia Thu Oct 11 11:14:28 CEST 2018
[root@prt53ws1 backup]#

Como tengo activado el versionado en el contenedor, si quisiera restaurar una copia de días anteriores, podría hacerlo sin problemas.

También he utilizado Transfer Acceleration. Hay que habilitarlo en el bucket S3 y también con el siguiente comando en el servidor que realiza la copia:

[root@prt53ws1 backup]# aws configure set default.s3.use_accelerate_endpoint true
[root@prt53ws1 backup]#

Uso de TGZ para copiar los datos a S3

El problema es que S3 no conserva los permisos de lectura, escritura y ejecución de los ficheros de Linux, así como su propietario. Así que la alternativa a copiar cada fichero directamente a S3 es comprimirlos en un fichero TGZ, que es el que luego copiamos a S3. Para mi, esta es la solución definitiva que, por cierto, también es la más rápida.

El script que he utilizado es el siguiente:

[root@prt53ws1 backup]# cat backup.sh
#!/usr/bin/sh
PATH=$PATH:/usr/bin
BACKUP=backup_full_$(date +%Y%m%d).tgz

####

echo «Inicio de la copia » $(date)

# Eliminamos el ultimo backup realizado
rm /backup/backup*.tgz

# Creamos la nueva copia
tar cvzf /backup/$BACKUP / –exclude /proc –exclude /dev –exclude /dev/shm –exclude /run –exclude /sys –exclude /MySQL –exclude /tmp –exclude /backup

# La subimos al bucket S3
aws s3 cp /backup/$BACKUP s3://puerto53com-backup/$(hostname)-full/ –storage-class STANDARD_IA –region eu-west-1 –endpoint-url http://puerto53com-backup.s3-accelerate.amazonaws.com

echo «Final de la copia » $(date)
[root@prt53ws1 backup]#

 

COMPÁRTEME

Deja un comentario