SSH copias de seguridad remotas automáticas


16

Tengo dos máquinas Ay B. La máquina Apuede encajar B. ATiene mucho espacio libre. BLos datos se encuentran en una especie de situación de riesgo. ¿Cómo hago una copia de seguridad de todos Blos datos de forma Aautomática? No tiene que ser terriblemente frecuente, pero debe ser manos libres. Cada vez que Aarranca sería bastante frecuente. Escuché que la sincronización puede hacer esto.

Respuestas:


11

Para hacer esto diariamente en la mayoría de las distribuciones de Linux, debería poder simplemente poner el rsynccomando (según la respuesta de @ guido ) en un script y colocar el script en el /etc/cron.dailydirectorio. Mientras anacronesté instalado (puede que no sea por defecto), los cron.dailytrabajos perdidos se recuperarán la próxima vez que la máquina arranque (además de ejecutarse a medianoche si la máquina se cambia).

Para el guión que simplemente harías:

#!/bin/sh
rsync -a user@serverB:/source/folder/ /destination_folder

Podría agregar la -zopción (compresión) si la copia de seguridad se realiza a través de una conexión lenta (ish) o si desea ahorrar ancho de banda, pero en mi experiencia realmente afectará el rendimiento con las máquinas / redes modernas.

Si desea mantener un registro de cada copia de seguridad, puede hacer algo como:

#!/bin/sh
rsync -av user@serverB:/source/folder/ /destination_folder \
  >/var/log/backup_log 2>&1

Tenga en cuenta que para que esto funcione como un trabajo cron, debe tener ssh sin contraseña configurado para root en el servidor A para iniciar sesión en el servidor B. Debe ser la cuenta raíz (es decir, las claves /root/.ssh) ya que los cron.dailytrabajos se ejecutan como raíz.


No necesariamente si usa una clave pública y cronjobs por usuario.
Braiam

@Braiam, anacronno recogerá crontrabajos por usuario . Aunque siempre puede usar su/ sudodesde el script para ejecutar rsync como un usuario en particular. Pero tenga en cuenta que las claves se mantendrán más seguras debajo /root.
Graeme

1
si desea usar un trabajo cron y ssh con root, es mucho más seguro restringir lo que puede hacer root en la segunda máquina en el archivo autorizado_keys.
guido

1
@ guido, no es necesario iniciar sesión como root en el servidor B solo porque usted es root en el servidor A. @JennyD ya ha sugerido qué hacer aquí, pero userpodría ser un usuario normal en machineB dependiendo de lo que esté respaldando.
Graeme

1
Lo más probable es que su usuario no tenga acceso de lectura a los archivos en severB. Si este es el caso, debe utilizar un usuario que lo haga o otorgarle al usuario actual los permisos correctos ya sea agregándolo a los grupos correctos o cambiando los permisos en los archivos. Si agrega una muestra de los errores que está recibiendo y la salida de ls -lalgunos de los archivos a su pregunta, la gente puede darle más consejos.
Graeme

5

Sugeriría usar rdiff-backup . Lo uso ahora para hacer copias de seguridad incrementales automáticas todas las noches de mis propios datos (dos estaciones de trabajo, dos servidores y una cuenta en el servidor de otra persona).

Utilicé rsync anteriormente para esto, pero cambié a rdiff-backup ya que es más conveniente y puede hacer copias de seguridad incrementales de archivos grandes, como imágenes de disco de máquinas virtuales. rdiff-backup es muy parecido a mis scripts de copia de seguridad rsync anteriores, pero está bien hecho .

Puse un archivo de secuencia de comandos en /etc/cron.daily en la máquina donde se almacena la copia de seguridad, que inicia rdiff-backup una vez al día temprano por la mañana y recupera los datos de la máquina remota.


4

Además de todas las respuestas anteriores, aquí hay una que se basa en claves SSH con restricciones sobre lo que se puede hacer al iniciar sesión con esa clave.

En el servidor A

En este caso, es menos importante si crea un usuario separado o usa uno de sus nombres de usuario existentes, aunque si fuera yo, crearía un usuario separado. Usaré el nombre bkpuserde usuario para ambos servidores en mis ejemplos a continuación.

Cuando inicie sesión bkpuser, cree una clave SSH sin contraseña.

En el servidor B

Habilitar PubkeyAuthenticationen sshd_config.

Crea el usuario bkpuser. Establezca una contraseña muy complicada o desactive el inicio de sesión de contraseña para ese usuario (exactamente cómo lo haga dependerá de qué unix y distribución esté ejecutando). El punto es que el usuario solo debe iniciar sesión con una clave SSH. Asegúrese de que bkpusertenga acceso de lectura a todos los directorios y archivos de los que desea hacer una copia de seguridad.

Copie la parte pública de la clave creada en A ~bkpuser/.ssh/authorized_keysen B. Edite para ejecutar automáticamente un comando en la conexión. Ese comando no debe ser un puntero a un script de shell; en su lugar, inserte el script de shell en la clave directamente. También incluya una limitación para que la clave solo se pueda usar desde el servidor A y ningún otro servidor. En el siguiente ejemplo, le doy al servidor A la dirección IP 10.1.2.3y supongo que todos los archivos de los que quiero hacer una copia de seguridad están debajo /data.

from="10.1.2.3",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="cd /data;/usr/bin/tar -cf - *; /usr/bin/logger -t BACKUP -p daemon.info \"INFO: Backup-files on $HOST fetched from ${SSH_CLIENT%% *} by $USER\";" ssh-dss AA.....

En el servidor A

Si está utilizando una de las pestañas cron que admite @rebootentradas, agregue dicha entrada a bkpusers crontab con el comando ssh -i ~bkpuser/.ssh/id_dsa serverB > backup.tar.gz. Si no lo permite, configúrelo en cualquier momento que desee; si fuera mi información, probablemente lo haría a diario.


2

Aquí hay una solución completa para hacer una copia de seguridad del servidor B en el servidor A todos los días a las 4 a.m. con SSH.

Cree una conexión SSH automática del servidor B al servidor A

ssh-keygen -t dsa -b 1024
ssh-copy-id -i ~/.ssh/id_dsa.pub "-p ssh_port root@server_a"

Crear una secuencia de comandos de respaldo en el servidor B

nano / root / backup

# !/bin/sh

# Variables loading
HOST="root@server_a"
PORT=22
DIR="/var/backups/server_b"

# Directories creating
ssh -p $PORT $HOST <<EOF
    mkdir -p $DIR/home
    logout
EOF

# Files backing up
rsync -aze "ssh -p $PORT" --delete /home/user $HOST:$DIR/home

chmod 744 / root / backup

Automatizar la copia de seguridad en el servidor B

crontab -e

0 4 * * * /root/backup > /dev/null

Para obtener más detalles, consulte las páginas Conéctese a SSH sin ingresar una contraseña en Linux y haga una copia de seguridad de un servidor en Debian o Ubuntu Linux .


1

Puede usar rsync para esto (de alguna manera inversa):

serverA# rsync -avz user@serverB:/path-to-backup.tar.gz /var/backup

dónde:

-avz  archive, compress and be verbose

Estoy bastante seguro -aimplica -r.
Shadur

tienes toda la razón
guido

-1

El quid de la cuestión es cómo hacerlo automáticamente (no es necesario ingresar contraseñas):

  • comenzar una screeno tmuxsesión
  • ejecutar eval $(ssh-agent)
  • agrega tu clave con ssh-add
  • banderas para rsync export RSYNC_RSH="ssh -i ~/.ssh/id_rsa ..."
  • copia de seguridad cada 24h con while :; do rsync -av u@h:/p /local; sleep $[24*60*60]; done

+1 para el sin contraseña ssh.
Graeme

Así que pondría todo esto en un script de inicio, ¿verdad?
PyRulez

1
Creo que aquí comienza la "pregunta realmente importante" ¿cuánta seguridad se necesita? ¿Hacerlo con contraseñas o sin él? Esto solo funcionará si 1) lo hace desde B, suspende o hiberna A. No funcionará si apaga A. Si no tiene contraseñas, se convertirá en una especie de "situación de riesgo".

No es necesario agregar RSYNC_SSHpara buscar ubicaciones estándar de claves SSH.
Pavel Šimerda

1
Yo sé eso. También supervisó los ...puntos donde puede agregar argumentos útiles. Tampoco leíste mi último comentario donde menciono la "pregunta realmente importante", por lo que nunca lo haría con claves sin contraseña. También deberá habilitarlo PubkeyAuthenticationy nadie lo dijo.
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.