Backups remotos y el load de cpu
Al final, reiniciando el servidor, hemos pasado de 4.8 Mb/s a 12 Mb/s de escritura, así que las copias se han acelerado notablemente.
De todas formas, ahora estamos pensando en montar por NFS los directorios de backups en los servidores locales, de modo que la restauración en el servidor de backups lo hagamos desde ese directorio.
Pros:
- CPU ni se entera
Contras:
- No se encripta la conexión
- El ancho de banda sufre (aunque igual que con scp)
Os comento como lo tenemos:
- Servidor en producción
Hago un backup local de la máquina 1
Hago un backup local de la máquina 2
Hago un backup local de la máquina 3
Los backups se lanzan desde consola: vzdump $i --mode snapshot -dumpdir /backups/servidor/$i --compress gzip
En este servidor tengo:
Copia actual (últimas 24 horas)
Copia diaria
Copia semanal
Copia mensual
Si las hiciera por nfs perdería la redundancia de copias.
El servidor de backup pregunta si ha acabado la primera copia de ese servidor; si ha acabado, comienza la descarga.
Cuando acaba, pregunta por el segundo backup... luego pasamos al siguiente servidor y hacemos lo mismo.
Cuando las descargas se han acabado, pasamos a la restauración de las máquinas en el servidor de backup; si la restauración está ok, manda el mail de confirmación, si está ko, manda el mail de aviso.
El problema es que el load se me pone fácil a 12 en el servidor que está dando el backup (el que recibe me da igual), al parecer el scp tira mucho de cpu
Voy a probar con scp -c blowfish que parece que da un poco más de rendimiento
Lo del lzo... creo que da igual que tarde menos el gzip, si luego tengo que mover datos más grandes. Además la compresión con el gzip "nuevo" ha mejorado mucho los tiempos (pigzwrapper).
Dicen que es más optimo para la cpu usar rsync, pero veremos sin con el blowfish llegan a moverse las máquinas a tiempo.
Con un core i5 un vzdump con su rsync correspondiente no suele ocupar más de un 20% de cpu, 30% en el peor de los casos .
Eso segun las graficas de RTM del manager
Eso si, yo uso LZ que ocupa un pelín más pero tarda menos. Al final me compensa ese poco más de transferencia a cambio de tardar menos en hacer el backup.
¿Por que haces que el servidor remoto se qede preguntando cuando termina el backup y luego " se lo traiga "?
¿No es más cómodo hacer un rsync desde el servidor local al remoto en cuanto termine el vzdump?
jm.trillo
08/03/2013, 12:49
No me ha quedado muy claro, el load de tus maquinas de producción sube por el scp? seguro que no es al comprimir y escribir a disco?
Como haces los backups? Desde consola en un proxmox?
Una opción que se me ocurre es transferir el backup al vuelo hasta el servidor de backups en lugar de hacer el backup en local y luego moverlo, lo que puede ser mas facil o dificil segun tu setup.
Buenas a todos.
Estamos tratando de afinar el tema de backups, porque volvemos a tener problemas.
Ahora mismo hacemos backups de 3 servidores físicos, con 8 virtuales.
El proceso es:
- Backup local
- Servidor remoto pregunta si ha acabado el backup en server1
- Cuando a acabado, se trae cada tar.gz
El problema que tenemos es que las copias están tardando bastante, y a las 9 de la mañana aún se están moviendo las últimas.
El load de la máquina se dispara y hace que no se pueda acceder al servidor mientras está llevando el fichero a la máquina de backup, que generalmente acaba sobre las 10 (estos dos últimos días).
Hemos cambiado el comando gzip por otro (no recuerdo el nombre, lo recomiendan en los foros de proxmox) que hace que los backups vayan más rápidos, pero aún así el load al mover por scp es brutal y nos pilla en horas de producción.
¿Alguna alternativa para mover los backups sin que el load se dispare?
Lo único que se me ocurre es tener dos máquinas que reciban los backups y poder dividir tiempos/carga, pero eso significa aumentar gastos que como siempre, no es lo que mejor nos viene.
