Sauvegardes automatiques à distance SSH


16

J'ai deux machines, Aet B. La machine Apeut entrer B. Aa beaucoup d'espace libre. BLes données sont dans une sorte de situation risquée. Comment sauvegarder automatiquement toutes Bles données de A. Il ne doit pas être très fréquent, mais il devrait être mains libres. Chaque fois que les Abottes seraient assez fréquentes. J'entends que la synchronisation peut le faire.

Réponses:


11

Pour faire cela quotidiennement dans la plupart des distributions Linux, vous devriez pouvoir simplement mettre la rsynccommande (selon la réponse de @ guido ) dans un script et mettre le script dans le /etc/cron.dailyrépertoire. Tant qu'il anacronest installé (peut-être pas par défaut), les cron.dailytravaux manqués seront rattrapés lors du prochain démarrage de la machine (et exécutés à minuit si la machine est commutée).

Pour le script, vous feriez juste:

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

Vous pouvez ajouter l' -zoption (compression) si la sauvegarde se fait sur une connexion lente (ish) ou si vous souhaitez économiser la bande passante, mais d'après mon expérience, cela nuira en fait aux performances avec les machines / réseaux modernes.

Si vous souhaitez conserver le journal de chaque sauvegarde, vous pouvez faire quelque chose comme:

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

Notez que pour que cela fonctionne comme un travail cron, vous devez avoir configuré ssh sans mot de passe pour root sur le serveurA pour vous connecter au serveurB. Il doit s'agir du compte root (c'est-à-dire des clés /root/.ssh) car les cron.dailyjobs sont exécutés en tant que root.


Pas nécessairement si vous utilisez une clé publique et des cronjobs par utilisateur.
Braiam

@Braiam, anacronne reprendra pas les travaux par utilisateur cron. Bien que vous puissiez toujours utiliser su/ à sudopartir du script pour exécuter rsync en tant qu'utilisateur particulier. Mais notez que les clés seront plus solidement maintenues sous /root.
Graeme

1
si vous souhaitez utiliser un travail cron et ssh avec root, il est beaucoup plus sûr de restreindre ce que root peut faire sur la deuxième machine du fichier authorized_keys.
guido

1
@guido, il n'est pas nécessaire de se connecter en tant que root sur serverB simplement parce que vous êtes root sur serverA. @JennyD a déjà donné des suggestions sur ce qu'il faut faire ici, mais userpourrait simplement être un utilisateur normal sur machineB selon ce que vous sauvegardez.
Graeme

1
Votre utilisateur n'a probablement pas accès en lecture aux fichiers sur severB. Si tel est le cas, vous devez utiliser un utilisateur qui le fait ou donner à l'utilisateur actuel les autorisations correctes en l'ajoutant aux groupes appropriés ou en modifiant les autorisations sur les fichiers. Si vous ajoutez un échantillon des erreurs que vous obtenez et la sortie de ls -lcertains fichiers à votre question, les gens peuvent donner des conseils supplémentaires.
Graeme

5

Je suggère d'utiliser rdiff-backup . Je l'utilise maintenant pour faire des sauvegardes incrémentielles automatiques chaque nuit de mes propres données (deux postes de travail, deux serveurs et un compte sur le serveur de quelqu'un d'autre).

J'ai utilisé rsync plus tôt pour cela, mais je suis passé à rdiff-backup car il est plus pratique et il peut effectuer des sauvegardes incrémentielles de gros fichiers tels que des images de disque de machine virtuelle. rdiff-backup est un peu comme mes précédents scripts de sauvegarde rsync, mais c'est fait droit .

J'ai mis un fichier de script dans /etc/cron.daily sur la machine où la sauvegarde est stockée, qui démarre rdiff-backup une fois par jour tôt le matin et récupère les données de la machine distante.


4

En plus de toutes les réponses précédentes, en voici une qui repose sur des clés SSH avec des restrictions sur ce qui peut être fait lorsque vous êtes connecté avec cette clé.

Sur le serveur A

Sur celui-ci, il est moins important si vous créez un utilisateur distinct ou utilisez l'un de vos noms d'utilisateur existants, mais si c'était moi, je créerais un utilisateur distinct. J'utiliserai le nom bkpuserd' utilisateur pour les deux serveurs dans mes exemples ci-dessous.

Une fois connecté bkpuser, créez une clé SSH sans mot de passe.

Sur le serveur B

Activer PubkeyAuthenticationdans sshd_config.

Créez l'utilisateur bkpuser. Définissez un mot de passe très compliqué ou désactivez la connexion par mot de passe pour cet utilisateur (la façon dont vous le faites dépendra de l'unix et de la distribution que vous utilisez). Le fait est que l'utilisateur ne doit se connecter qu'avec une clé SSH. Assurez-vous qu'il bkpuserdispose d'un accès en lecture à tous les répertoires et fichiers que vous souhaitez sauvegarder.

Copiez la partie publique de la clé créée sur A vers ~bkpuser/.ssh/authorized_keyssur B. Modifiez le pour exécuter automatiquement une commande lors de la connexion. Cette commande ne doit pas être un pointeur vers un script shell; à la place, insérez directement le script shell dans la clé. Incluez également une limitation afin que la clé ne puisse être utilisée que depuis le serveur A et aucun autre serveur. Dans l'exemple ci-dessous, je donne au serveur A l'adresse IP 10.1.2.3et je suppose que les fichiers que je veux sauvegarder sont tous sous /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.....

Sur le serveur A

Si vous utilisez l'un des onglets cron qui prend en charge les @rebootentrées, ajoutez une telle entrée à bkpusers crontab avec la commande ssh -i ~bkpuser/.ssh/id_dsa serverB > backup.tar.gz. Si cela ne les autorise pas, définissez-le à tout moment - si c'était mes données, je le ferais probablement tous les jours.


2

Voici une solution complète pour sauvegarder le serveur B sur le serveur A tous les jours à 4h du matin en utilisant SSH.

Créer une connexion SSH automatique du serveur B au serveur A

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

Créer un script de sauvegarde sur le serveur B

nano / root / sauvegarde

# !/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 / sauvegarde

Automatisez la sauvegarde sur le serveur B

crontab -e

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

Pour plus de détails, voir les pages Se connecter à SSH sans entrer de mot de passe sous Linux et sauvegarder un serveur sur Debian ou Ubuntu Linux .


1

Vous pouvez utiliser rsync pour cela (en quelque sorte à l'envers):

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

où:

-avz  archive, compress and be verbose

Je suis sûr que cela -aimplique -r.
Shadur

vous avez tout à fait raison
guido

-1

Le nœud du problème est de savoir comment le faire automatiquement (pas besoin de saisir des mots de passe):

  • démarrer une session screenoutmux
  • exécuter eval $(ssh-agent)
  • ajoutez votre clé avec ssh-add
  • drapeaux pour rsync export RSYNC_RSH="ssh -i ~/.ssh/id_rsa ..."
  • sauvegarde toutes les 24h avec while :; do rsync -av u@h:/p /local; sleep $[24*60*60]; done

+1 pour le sans mot de passe ssh.
Graeme

Donc, je mettrais tout cela dans un script de démarrage, non?
PyRulez

1
Je pense que commence ici la "question vraiment importante", combien de sécurité est nécessaire? Faites-le avec ou sans mot de passe? Cela ne fonctionnera que si vous 1) le faites à partir de B, suspendez ou mettez en veille prolongée A. Cela ne fonctionnera pas si vous désactivez A. Si vous vous passez de mots de passe, vous deviendrez une sorte de «situation à risque».

Il n'est pas nécessaire d'ajouter RSYNC_SSHà la recherche des emplacements standard des clés SSH.
Pavel Šimerda

1
Je le sais. Vous avez également supervisé les ...points où vous pouvez ajouter des arguments utiles. Vous n'avez pas non plus lu mon dernier commentaire où je mentionne la "question vraiment importante" donc je ne le ferais jamais avec des clés sans mot de passe. Vous devrez également l'activer PubkeyAuthenticationet personne ne l'a dit.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.