OVH Community, your new community space.

Servidores Dedicados: Storage


vicio
14/01/2009, 16:51
Alguien lo ha probado ya? Se pueden aprovechar esos 6TB de espacio o el configurar te limita de alguna forma? Ya se pueden poner todos los niveles de RAID sin pirulas?

Power
09/01/2009, 15:21
Gracias JarFil,

Muy interesantes los datos que aportas.
Ya estoy estudiando cómo utilizar rdiff-backup para los datos que cambian diariamente (bases de datos, mail, logs, etc).

Saludos

web-a
09/01/2009, 14:23
caray, si que está interesante el tema

JarFil
09/01/2009, 05:45
Tras hacer algunas pruebas, creo que no voy a usar cp -la salvo en casos muy puntuales. El problema principal de cp -la es que sólo enlaza los ficheros, pero duplica al completo la estructura de directorios. En cambio rdiff-backup guarda los metadatos en un solo fichero, y los comprime.

Datos de prueba
- 7GB en 180.000 ficheros en 17.000 directorios
- sitios web con tráfico medio-bajo

cp -la
- instantánea: 75MB de metadatos
- cada hora: 10MB de cambios + 75MB de metadatos (61.2GB/mes)
- cada día: 100MB de cambios + 75MB de metadatos (5.2GB/mes)

rdiff-backup
- instantánea: 5MB de metadatos
- cada hora: 2.5MB de cambios + 5MB de metadatos (5.4GB/mes)
- cada día: 50MB de cambios + 5MB de metadatos (1.6GB/mes)

El resultado es que rdiff-backup puede guardar 1 mes de cambios horarios usando un 75% del tamaño original, mientras que cp -la necesita el mismo espacio para guardar apenas cambios diarios.

Power
24/12/2008, 09:07
¡ Sí señor. Eso es una buena explicación !

Pues me has convencido:
cp -la para todo, excepto para los logs, mails y bases de datos.
Para los logs, mails y bases de datos rdiff-backup.

Lo que nunca he utilizado es cpio.
Muchas gracias JarFil.

Saludos y Felices Fiestaspara todos

JarFil
24/12/2008, 02:43
Tras darle algunas vueltas... me parece que tanto el cp -la, como rdiff-backup, como rdiffdir, tienen sus pros y sus contras:

cp -la
- Permite recuperar los ficheros directamente
- Evita que se pierdan las copias anteriores si se corrompe un fichero
- Cada copia crea tantos directorios como en el original
- Usa un 66% de espacio extra (copias diarias, de cuántos días?)
- Necesitaría una herramienta adicional para empaquetar los cambios
- Todas las copias deben estar en el mismo sistema de ficheros (mismo disco, misma partición)

rdiff-backup
- Usa un 8% de espacio extra para copias horarias de 30 días (720 copias)
- Si se corrompe un fichero, sólo se pierden las copias anteriores de ese fichero
- Crea como mucho el doble de directorios que el original
- Necesitaría herramienta adicional para empaquetar los cambios, aunque está preparado para ello
- En la mayoría de los casos necesita herramienta especial para recuperar los ficheros
- Crea más ficheros en cada directorio, además de las copias

rdiffdir
- Usa espacio extra como el rdiff-backup, pero en muchos menos ficheros y sin crear directorios
- Cada fichero de backup es un paquete completo
- Necesita herramienta especial para recuperar los ficheros
- Si se corrompe un fichero, se pierden todas las copias anteriores, de todos los ficheros

Herramientas de backup tradicionales
- Igual que rdiffdir pero usando aún más espacio

El rdiffdir desde luego es bastante peligroso, pero entre los otros dos... creo que la diferencia principal sería que rdiff-backup puede ser más eficiente con el espacio que necesita para almacenar cambios pequeños de ficheros grandes, mientras que cp -la es más simple y seguro a costa de usar más espacio.

Tal vez lo recomendable sería usar uno u otro según el tipo de contenidos:
- rdiff-backup para las bases de datos, logs y parecidos
- cp -la para el resto

Y aparte de eso cpio para sacar snapshots de /.

sdzzds
23/12/2008, 17:20
Gracias por compartirlo Power, cuando tenga un poco de tiempo lo pruebo....

Saludos

Power
23/12/2008, 12:36
Cita Publicado inicialmente por Shuugo
Con el Rsync 2.x el unico problema era los recursos que utilizaba, ahora el 3.0 lo hace perfecto, por lo menos para mi.
Hola,

Y si encima el script (como es mi caso) no corre en el servidor principal sino en el servidor de backup, pues aún mejor.

Saludos

Shuugo
23/12/2008, 11:15
Cita Publicado inicialmente por Power
Pues ahí va:

Código:
#!/bin/bash
# ---------------------------------------------------------------------------------------
# Script de backup remoto con sistema de transferencia diferencial y almacenamiento referenciado
# Script local, origen: máquina remota, destino: directorio local
# Se conecta a una máquina remota por SSH (con claves SSH habilitadas)
# Se hace backup por rsync sobre el último backup obtenido (rsync desenlaza los ficheros que sobreescribe)
# A continuación se copia, localmente, el backup, con enlace duro, sobre un directorio con nombre de la fecha
# De esta forma sólo incrementan espacio de disco los ficheros modificados 
# ----------------------------------------------------------------------
unset PATH    # Ahorra problemas
# ------------- Configuración -------------------------------------------
MAQUINA_REMOTA=******* # Servidor del que hacer backup
PUERTO=**** # Si el servidor usa un puerto SSH no estandard
USUARIO=root
DIR_ORIGEN=/backup/cpbackup/daily
DIR_DESTINO=/store
EMAIL="********@gmail.com"
TEXTO=/tmp/texto_email
#---------------Comandos-------------------------------------------------
ECHO=/bin/echo
RM=/bin/rm
MV=/bin/mv
CP=/bin/cp
DATE=/bin/date
TOUCH=/bin/touch
MOUNT=/bin/mount
SLEEP=/bin/sleep
MKDIR=/bin/mkdir
CAT=/bin/cat
MAIL=/bin/mail
RSYNC=/usr/bin/rsync
#---------------------------Funciones-------------------------------------
mensaje(){
    HORA=$($DATE +%Y-%m-%d\ %T)
    $ECHO $HORA $1 >> ${TEXTO}
    return 0
}
#-------------------------------------------------------------------------
# Borrado de fichero de TEXTO
$RM -f ${TEXTO}
#-----------------------------------Comienzo---------------------------------------------
$ECHO "====================================================================" >> ${TEXTO}
mensaje "Comienzo de Backup Revolution de Cpbackup Daily de $MAQUINA_REMOTA"
$ECHO "====================================================================" >> ${TEXTO}
#---------------Creación de directorio "ultimo" la primera vez--------------------
if [ ! -d $DIR_DESTINO/ultimo ]
    then $MKDIR $DIR_DESTINO/ultimo
fi
#------------Transferencia---------------------------------------------------
$RSYNC -va -e "ssh -p $PUERTO" --delete $USUARIO@$MAQUINA_REMOTA:$DIR_ORIGEN/ $DIR_DESTINO/ultimo >> ${TEXTO}
#-------------Creación de directorio-------------------------------------------------
FECHA=$($DATE +%Y-%m-%d)
$MKDIR $DIR_DESTINO/$FECHA >> ${TEXTO}
#--------------Enlace duro----------------------------------------------
$CP -al $DIR_DESTINO/ultimo/. $DIR_DESTINO/$FECHA/ >> ${TEXTO}
#-----------------------------------Fin---------------------------------------------
$ECHO "====================================================================" >> ${TEXTO}
mensaje "Fin de Backup Revolution de Cpbackup Daily de $MAQUINA_REMOTA"
$ECHO "====================================================================" >> ${TEXTO}
#-----------------Email-----------------------------------------------------------
$CAT ${TEXTO} | $MAIL -s "Backup Revolution de Cpbackup Daily de $MAQUINA_REMOTA" ${EMAIL}
#---------------------------------------------------------------------------------
Como utilizo el sistema de autentificación por llaves en el servidor, no preciso poner contraseña para que rsync conecte.
En caso contrario, tendrá que añadir:
export RSYNC_PASSWORD=**********

Como mi servidor principal tiene cPanel y todas las noches se hace un backup local en /backup/cpbackup/daily utilizo ese directorio como origen del backup remoto.

Como el script corre en el servidor de backup (Kemsirve L) apenas consume recursos del servidor principal.

He comprobado que en funcionamiento del script, el Kemsirve L no llega a tener una carga mucho mayor de 1 y ocupar 500 MB de RAM (el Kemsirve L tiene 1 GB de RAM).

Las particiones en el Kemsirve L son 50GB para /, 2GB para swap, 10GB para /tmp y el resto para /store.

Como el tráfico es dentro de OVH, no cuenta para el tema de la transferencia.
Y la velocidad media a la que va haciendo los backups remotos es de unos 60 Mb/s

Estoy contentísmo con la solución porque con el Backup FTP gratuito ya había tenido muy malas experiencias.

Saludos
Yo he estado usando este sistema ya casi dos años y es una maravilla. Tengo un script parecido funcionando. Con el Rsync 2.x el unico problema era los recursos que utilizaba, ahora el 3.0 lo hace perfecto, por lo menos para mi.

Power
23/12/2008, 09:22
Cita Publicado inicialmente por JarFil
No sé si te podría interesar rdiff-backup. Además de mantener una copiar actualizada, guarda las instantáneas pasadas como deltas. La diferencia sería que las deltas ocupan menos, a veces mucho menos, aunque los ficheros no serían directamente accesibles como con los enlaces... para backup que no se tenga que recuperar demasiadao a menudo, creo que compensa.

http://www.gnu.org/savannah-checkout.../rdiff-backup/
Hola JarFil.
Muchas gracias por tu información.

He estado utilizando Duplicity (que está basado en rdiffdir) durante algún tiempo haciendo backups incrementales diarios sobre el espacio backup FTP gratuito que da OVH.

Pero no me ha acabado de convencer por varias razones:
- Si se corrompe algún fichero del backup, puedes olvidarte de recuperar el backup de ningún día (me ha ocurrido).
- rdiffdir tiene aún algunos bugs (que he sufrido)
- La recuperación del backup de un día es más trabajosa que leer simplemente el fichero "backupeado".
-Y para colmo de males, el sistema de backup FTP de OVH ha funcionado lento y mal.

Por todo eso, he pasado a este sistema de un servidor Kemsirve L que se encarga de hacer backup de mi servidor principal (y de otros futuros servidores).

Y con el sistema de enlaces duros, mediante cp -la, el espacio total ocupado por todos los backups es sólo el espacio del primer backup + el espacio de los ficheros modificados.

Ahora mismo el directorio del backup completo de cada día (en el que veo todos los ficheros de /home y de las bases de datos MySQL) ocupa unos 30 GB y el directorio donde se guardan todos esos backups de todos los días, sólo 50 GB.
(Parece un milagro ésto de los enlaces duros en Linux, que nunca había utilizado).

Mi script está basado en esto que leí hace tiempo:
www.mikerubel.org/computers/rsync_snapshots/

Saludos

JarFil
23/12/2008, 03:54
Cita Publicado inicialmente por Power
Además he hecho un script para que aunque almacene un backup completo por día, el espacio ocupado sea mucho menor, gracias al comando cp -la que crea enlaces duros y sólo ocupan espacio nuevo los ficheros que se han modificado.
No sé si te podría interesar rdiff-backup. Además de mantener una copiar actualizada, guarda las instantáneas pasadas como deltas. La diferencia sería que las deltas ocupan menos, a veces mucho menos, aunque los ficheros no serían directamente accesibles como con los enlaces... para backup que no se tenga que recuperar demasiadao a menudo, creo que compensa.

http://www.gnu.org/savannah-checkout.../rdiff-backup/

Power
22/12/2008, 00:11
Cita Publicado inicialmente por a-n-t-o-n-i-o
hola power, estaria bien que compartieras tu script, yo uso uno muy basico.
Pues ahí va:

Código:
#!/bin/bash
# ---------------------------------------------------------------------------------------
# Script de backup remoto con sistema de transferencia diferencial y almacenamiento referenciado
# Script local, origen: máquina remota, destino: directorio local
# Se conecta a una máquina remota por SSH (con claves SSH habilitadas)
# Se hace backup por rsync sobre el último backup obtenido (rsync desenlaza los ficheros que sobreescribe)
# A continuación se copia, localmente, el backup, con enlace duro, sobre un directorio con nombre de la fecha
# De esta forma sólo incrementan espacio de disco los ficheros modificados 
# ----------------------------------------------------------------------
unset PATH    # Ahorra problemas
# ------------- Configuración -------------------------------------------
MAQUINA_REMOTA=******* # Servidor del que hacer backup
PUERTO=**** # Si el servidor usa un puerto SSH no estandard
USUARIO=root
DIR_ORIGEN=/backup/cpbackup/daily
DIR_DESTINO=/store
EMAIL="********@gmail.com"
TEXTO=/tmp/texto_email
#---------------Comandos-------------------------------------------------
ECHO=/bin/echo
RM=/bin/rm
MV=/bin/mv
CP=/bin/cp
DATE=/bin/date
TOUCH=/bin/touch
MOUNT=/bin/mount
SLEEP=/bin/sleep
MKDIR=/bin/mkdir
CAT=/bin/cat
MAIL=/bin/mail
RSYNC=/usr/bin/rsync
#---------------------------Funciones-------------------------------------
mensaje(){
    HORA=$($DATE +%Y-%m-%d\ %T)
    $ECHO $HORA $1 >> ${TEXTO}
    return 0
}
#-------------------------------------------------------------------------
# Borrado de fichero de TEXTO
$RM -f ${TEXTO}
#-----------------------------------Comienzo---------------------------------------------
$ECHO "====================================================================" >> ${TEXTO}
mensaje "Comienzo de Backup Revolution de Cpbackup Daily de $MAQUINA_REMOTA"
$ECHO "====================================================================" >> ${TEXTO}
#---------------Creación de directorio "ultimo" la primera vez--------------------
if [ ! -d $DIR_DESTINO/ultimo ]
    then $MKDIR $DIR_DESTINO/ultimo
fi
#------------Transferencia---------------------------------------------------
$RSYNC -va -e "ssh -p $PUERTO" --delete $USUARIO@$MAQUINA_REMOTA:$DIR_ORIGEN/ $DIR_DESTINO/ultimo >> ${TEXTO}
#-------------Creación de directorio-------------------------------------------------
FECHA=$($DATE +%Y-%m-%d)
$MKDIR $DIR_DESTINO/$FECHA >> ${TEXTO}
#--------------Enlace duro----------------------------------------------
$CP -al $DIR_DESTINO/ultimo/. $DIR_DESTINO/$FECHA/ >> ${TEXTO}
#-----------------------------------Fin---------------------------------------------
$ECHO "====================================================================" >> ${TEXTO}
mensaje "Fin de Backup Revolution de Cpbackup Daily de $MAQUINA_REMOTA"
$ECHO "====================================================================" >> ${TEXTO}
#-----------------Email-----------------------------------------------------------
$CAT ${TEXTO} | $MAIL -s "Backup Revolution de Cpbackup Daily de $MAQUINA_REMOTA" ${EMAIL}
#---------------------------------------------------------------------------------
Como utilizo el sistema de autentificación por llaves en el servidor, no preciso poner contraseña para que rsync conecte.
En caso contrario, tendrá que añadir:
export RSYNC_PASSWORD=**********

Como mi servidor principal tiene cPanel y todas las noches se hace un backup local en /backup/cpbackup/daily utilizo ese directorio como origen del backup remoto.

lo que me preocupa tambien es el gasto de recursos, supongo que este tipo de backups consumira mas tiempo y cpu si no me equivoco y eso en mi caso no seria bueno.
Como el script corre en el servidor de backup (Kemsirve L) apenas consume recursos del servidor principal.

He comprobado que en funcionamiento del script, el Kemsirve L no llega a tener una carga mucho mayor de 1 y ocupar 500 MB de RAM (el Kemsirve L tiene 1 GB de RAM).

Las particiones en el Kemsirve L son 50GB para /, 2GB para swap, 10GB para /tmp y el resto para /store.

Como el tráfico es dentro de OVH, no cuenta para el tema de la transferencia.
Y la velocidad media a la que va haciendo los backups remotos es de unos 60 Mb/s

Estoy contentísmo con la solución porque con el Backup FTP gratuito ya había tenido muy malas experiencias.

Saludos

a-n-t-o-n-i-o
21/12/2008, 23:46
Cita Publicado inicialmente por Power

Además he hecho un script para que aunque almacene un backup completo por día, el espacio ocupado sea mucho menor, gracias al comando cp -la que crea enlaces duros y sólo ocupan espacio nuevo los ficheros que se han modificado.

Saludos
hola power, estaria bien que compartieras tu script, yo uso uno muy basico.

lo que me preocupa tambien es el gasto de recursos, supongo que este tipo de backups consumira mas tiempo y cpu si no me equivoco y eso en mi caso no seria bueno.

un saludo.

Power
21/12/2008, 23:37
Cita Publicado inicialmente por pedrito
Estoy por pillar uno para hacer backups del resto de servidores, que el ftpbackup que dan con cada servidor es un poco peste... xD
Hola pedrito,

Creo que es un uso ideal para ese tipo de máquina.
Porque efectivamente, el servicio de Backup gratuito por FTP va un día sí y dos no. Y cuando va, está supersaturado.

Yo me he pillado para ese mismo uso un Kemsirve L por 19,99 €, que en mi caso es más que suficiente.
Es una gozada hacer los backups a tope de velocidad con rsync.

Además he hecho un script para que aunque almacene un backup completo por día, el espacio ocupado sea mucho menor, gracias al comando cp -la que crea enlaces duros y sólo ocupan espacio nuevo los ficheros que se han modificado.

Saludos

pedrito
21/12/2008, 03:36
Estoy por pillar uno para hacer backups del resto de servidores, que el ftpbackup que dan con cada servidor es un poco peste... xD

eLkRi
20/12/2008, 17:14
6TB y por 275 te garantizas el SLA... pues es perfecto la verdad por que a ver donde pillas 6TB de disco y 100mbps de ancho de banda por menos de 300€

RePliCanT
20/12/2008, 10:45
Creo que es una oferta muy interesante para que los que tenemos varios servers, podamos cojer uno para usar como Backup, pero el tema de la transferencia lo va a limitar...

sdzzds
19/12/2008, 22:01
Muy buen precio para este nuevo server. Lo que le falta es un backup externo de la misma capacidad aunque sería una locura hacer backups externos de 6TB

Como Marcos, lo que falla es el ancho de banda. Se podría montar Rapidshare2 pero claro no nos van a dejar un ancho de banda en condiciones, sería tirar piedras contra su propio tejado. Puede ser un server peligroso, mal usado.

davidlig
19/12/2008, 21:24
Cita Publicado inicialmente por MarcosBL
+100 Excelente, como servicio y excelente de precio. Me viene pero de perlas para un campus online con contenidos multimedia a saco... eso si.. seguramente lo perjudique el tema SLA/No SLA, a ver como nos lo montamos para el plan de transferencia mensual, porque esto parece estar pensado para servir archivos casi en exclusiva. Sin no se consigue ajustar bien eso, sólo servirá para guardar backups brutales : )

En mi caso preferiría pagar más, bastante más incluso, hasta el doble, y tener un SLA garantizado 100%, es decir, que este tipo de servidores no entrase en el paquete "100 Mbs en el conjunto de tu infraestructura de servidores". Aún asi, suena muy prometedor : D
Para eso tienes el tipo de conexión Unmetred Series (muy caro desde mi punto de vista)

MarcosBL
19/12/2008, 19:42
+100 Excelente, como servicio y excelente de precio. Me viene pero de perlas para un campus online con contenidos multimedia a saco... eso si.. seguramente lo perjudique el tema SLA/No SLA, a ver como nos lo montamos para el plan de transferencia mensual, porque esto parece estar pensado para servir archivos casi en exclusiva. Sin no se consigue ajustar bien eso, sólo servirá para guardar backups brutales : )

En mi caso preferiría pagar más, bastante más incluso, hasta el doble, y tener un SLA garantizado 100%, es decir, que este tipo de servidores no entrase en el paquete "100 Mbs en el conjunto de tu infraestructura de servidores". Aún asi, suena muy prometedor : D

davidlig
19/12/2008, 16:24
Pues no está nada mal la verdad

oles@ovh.net
19/12/2008, 16:16
Buenos días

Iniciamos un nuevo modelo de servidor dedicado : "storage".

Los servidores "storage" han sido concebidos y optimizados para una
necesidad importante de almacenamiento con una seguridad a la
carta: con o sin seguridad y seguridad a elegir entre raid 0, 1, 5, 6, 10.

Comenzamos esta gama con un Superplan Storage que es un
Intel Dual Core 2x66+ (bajo consumo), con 2GB de RAM y
6TB de discos (4x1.5TB SATA2).

El servidor está conectado a la red via 100Mbps. Hemos hecho un
esfuerzo particularmente importante en el precio: el servidor cuesta tan
sólo 89Euros/mes (+IVA) con unos gastos de instalación de 49Euros (+IVA)

Para saber más
http://www.ovh.es/particular/product...an_storage.xml

La interfaz manager no permite aún una configuración flexible de los
discos en todos los sentidos (sin raid, lvm, con raid 0, 1, 5, 6 o 10) pero
con el acceso rescue, todo es posible...

Pensamos que el manager será "storage-friendly" dentro de 2 semanas,
más o menos.


Amistosamente,
Octave