postheadericon Sauvegarder les données de son serveur avec rsync

Ah mais cette fois j’en ai marre … marre de lire à gauche et à droite que rsync n’est pas un outil de backup digne de ce nom. Je m’en vais vous montrer le contraire, et pas plus tard que tout de suite !

Introduction

Soit la situation suivante : j’ai un serveur dédié, par exemple en release 2 OVH (mais cela marchera tout aussi bien avec d’autres distributions Linux). Mes données se trouvent dans /home et je souhaite en faire une sauvegarde quotidienne et incrémentale sur un autre serveur (Linux lui aussi, voire pourquoi pas en release 2).

Incrémentale ? Bah oui, tant qu’à faire, je souhaite ne sauvegarder que les fichiers créés ou modifiés depuis la veille, tout en gardant évidemment un backup complet de mes données aussi récent que possible. Cela n’offre que des avantages :

  1. Économie de temps de transfert et de bande passante (puisqu’on ne transfère tous les jours que les fichiers qui ont été ajoutés / modifiés)
  2. On dispose toujours d’un backup complet qui date du matin même (les backups se faisant la plupart du temps la nuit ou au petit matin)
  3. On garde un historique des fichiers qui ont été modifiés au jour le jour. Idéal en cas de hack du serveur, au premier coup d’oeil : on voit ce qui a été ajouté / modifié et à quelle date.

Création d’un utilisateur sur le serveur de backup

On commence par créer un user dont le répertoire sera dédié au backup. Cela peut se faire en SSH via la commande adduser ou bien par Webmin :  Système > Utilisateurs et groupes > Créer un nouvel utilisateur

Dans mon exemple, mon utilisateur se nommera backupserveur1.

Mise en place des clés SSH

Il faut faire en sorte que les deux serveurs puissent dialoguer de manière cryptée et sans devoir s’échanger de mot de passe. Donc, si ce n’est pas encore fait, il convient de générer une paire de clés SSH.

Donc, sur le serveur source (le serveur à sauvegarder) :
ssh-keygen -b 1024 -t dsa

(valider par la touche “enter” les questions qui vous sont posées)

Personnellement, je dédie ces clés à la procédure de backup entre les 2 serveurs, je les stocke donc dans un répertoire différent. Par exemple :

mkdir /usr/share/keys/
mv /root/.ssh/id_dsa.pub /usr/share/keys/key-rsync.pub
mv /root/.ssh/id_dsa /usr/share/keys/key-rsync

Il convient à présent de copier la clé publique (pas de gaffe, attention) dans le fichier authorized_keys de l’utilisateur backupserveur1 sur le serveur de backup. Il s’agit donc de copier le contenu de key-rsync.pub dans /home/backupserveur1/.ssh/authorized_keys (voire authorized_keys2 selon votre configuration SSH).

Le script

C’est là que ça devient rigolo car le script lui-même tient en une seule et unique ligne que vous pouvez, par exemple créer dans un fichier /root/toto/backup.sh:

#!/bin/bash

rsync -a -e "ssh -i /usr/share/keys/key-rsync" -b --backup-dir=../home-`date -I` --delete /home/ --exclude-from=/root/toto/backup-exclude backupserveur1@11.22.33.44:home/

A mettre en cron, une fois par jour vers 5 heure du matin par exemple.

Explications

Quel sera l’effet de cette ligne de code ?

Elle va tout simplement synchroniser votre répertoire /home avec le répertoire éponyme, lui même situé dans le répertoire de backupserveur1 sur le serveur à distance (donc dans /home/backupserveur1/home). Vous aurez donc ainsi un miroir de votre /home sur le serveur de backup, mis à jour quotidiennement. Jusque là, c’est déjà pas mal … mais en plus cela aura pour effet de créer un répertoire /home/backupserveur1/home-AAAA-MM-JJ qui contiendra tous les fichiers qui ont été modifiés depuis la veille, et seulement eux !

Alors, plutôt sympa rsync, non ? 😉

Dans l’instruction ci-dessus, notez que :

  1. /usr/share/keys/key-rsync doit correspondre à l’emplacement de votre clé SSH
  2. backupserveur1 est bien sûr le nom de l’utilisateur que vous avez préalablement créé sur le serveur de backup
  3. 11.22.33.44 correspond à l’adresse IP du serveur de backup
Attention au fichier /root/toto/backup-exclude

Comme je le disais ci-dessus, ce mini-script sauvegarde l’intégralité de votre /home … ce qui n’est pas forcément souhaitable. Il est donc prévu un fichier “backup-exclude” où vous pouvez lister tous les fichiers et/ou répertoires qui se trouvent dans /home et que vous ne souhaitez pas sauvegarder.

Cette fonction est absolument essentielle sur les serveurs en release 2 OVH car les bases de données MySQL se trouvent précisément dans /home/mysql (c’est une originalité de cette distribution) et le fait de copier les fichiers qui s’y trouvent ne constitue pas un bon backup des bases. A vrai dire, il est même fortement recommandé de ne pas toucher à ces fichiers (donc de ne pas les copier) quand MySQL tourne. Et comme MySQL tourne en permanence … pas touche ! Pour savoir comment backuper proprement vos base, voyez ce billet : Bases de données MySQL : backup quotidien (que vous pouvez d’ailleurs astucieusement combiner avec le système de backup décrit ici)

A titre personnel, sur les serveurs en release OVH, je ne sauvegarde pas les logs ni les stats des sites hébergés (en plus du fameux /home/mysql). Voici donc à quoi ressemble mon “backup-exclude” :

/log
/mysql
www/stats

Je crois que c’est à peu près tout, ouf 🙂

Ah non, j’oubliais, il convient de lancer une première fois le scirpt “à la main” pour que les deux serveurs puisse se reconnaitre. Il s’agit donc simplement de taper…

sh /root/toto/backup.sh

… et de répondre par “yes” à la question qui est posée. Cette question ne sera plus posée à l’avenir et le script peut alors être mis en tâche cron, il s’exécutera sans problème. Notez aussi que ce premier backup risque d’être assez long (cela dépend évidemment quantité de données à transférer) puisque toutes vos données vont devoir être copiées une première fois. Par la suite, les backup seront nettement plus rapide dans la mesure ou seuls les nouveaux dossiers/fichiers (ainsi que ceux qui auront été modifiés) seront transférés quotidiennement.

24 réponses à to “Sauvegarder les données de son serveur avec rsync”

  • vetdomain:

    Bravo pour ce post. Mais que se passe-t-il ensuite ??? Imaginons le gros crash sur le serveur A. Depuis votre manager OVH, vous allez basculer l’ip fail-over sur le serveur B.

    Quelles manip faire sur le serveur B ? Déplacer le dernier back up à la racine de /home, bien sûr.

    Mais ça ne suffit pas pour que ça marche.

    -…il manque httpd.conf, bind, samba… et quid de qmail qui s’arc-boute à l’ip fixe du serveur A ?

    Comment resolvez-vous ce point dans votre stratégie de backup ?

  • Nico:

    Hep, hep ! ‘tention là, vous êtes en train de confondre backup et haute disponibilité 😉

    Le but du billet était de montrer comment on peut créer un backup incrémental des données (et pas du système, nuance) à l’aide de rsync. Ce genre de backup est sacrément utile en cas de corruption des données car il permet de conserver un historique de tout ce qui a été modifié sur les n derniers jours (n étant à votre meilleure convenance). Qui plus est, c’est le genre de backup particulièrement économe en terme de ressources utilisées puisqu’on ne transfère quotidiennement qu’une faible quantité de fichiers vers le serveur de backup.

    C’est donc un bonne solution pour récupérer un fichier, une base de donnée (voire éventuellement un mail) qui aurait été effacé/altéré au cours des n derniers jours.

    Cela peut aussi représenter une solution pour restaurer un serveur en cas de crash complet du système (nécessitant donc la réinstallation du serveur) mais c’est moins pratique : il faut en effet réinstaller complètement le système et recréer les hébergements de chaque site un à un, avant de restaurer les données (les données étant donc, en gros, les fichiers de chaque site, les bases de données et les boites mail) en les recopiant dans l’autre sens. Sans oublier bien sûr les inévitables changement de propriétaire des fichiers (chown) qui vont bien… Pas impossible, mais ça prend inévitablement un peu de temps … et on en manque toujours dans ces cas là 😉

    Par ailleurs, notez que rien ne vous empêche d’utiliser rsync pour sauvegarder les fichiers de config que vous souhaitez, notamment (liste non exhaustive) les configurations de Bind, Apache, MySQL, le serveur FTP, SSH, etc.

    Quoi qu’il en soit, le point important est donc que le serveur de backup (le B donc) n’est pas censé être une réplique prête à l’emploi du serveur A et il n’y a donc pas lieu de basculer d’IP failover.

    A vrai dire, pour répondre à votre préoccupation, je ne vois guère que la virtualisation (les VPS peuvent être intégralement sauvegardés, assez facilement qui plus est) ou bien la haute disponibilité. La vraie : celle qui se fait à grand renfort de DRBD et de Heartbeat et qui permet de synchroniser 2 serveurs et même évetuellement les mettre en load balancing.

  • Nico:

    Cela dit, je viens de m’apercevoir que le titre de ce billet (“Sauvegarder son serveur dédié grâce à rsync”) peut prêter à confusion. Je viens donc de le modifier pour qu’il en décrive plus justement le contenu.

  • Della:

    Bonjour,

    Merci pour ce tutoriel car il correspond exactement à ce que je cherchais depuis longtemps^^

    J’aurais aimé avoir juste une précision concernant la partie sur les clés SSh.

    Les commandes que vous indiquez, il faut les effectuer sur le serveur contenant les données ou sur le serveur de backup??

    Le script à mettre en cron, il faut bien le mettre sur le serveur de données?

    Merci d’avance.
    Je vous souhaite une excellente continuation.

  • Nico:

    Ravi que ce billet vous soit utile 🙂

    Toutes les commandes sont à exécuter sur le serveur contenant les données. Idem pour le cron (encore qu’avec rsync … enfin bref, inutile de compliquer inutilement les choses ;)).

    A vrai dire, sur le serveur de backup, il n’y a qu’à :

    1) Créer un utilisateur et son répertoire (backupserveur1 -> /home/backupserveur1).

    2) Copier la clé publique (donc générée au préalable sur le serveur de données) dans /home/backupserveur1/.ssh/authorized_keys (ou authorized_keys2, voir configuration SSH) pour que le serveur contenant les données puisse se connecter automatiquement au serveur de backup.

  • Della:

    Je vous remercie pour votre réponse rapide et explicite^^

    Merci beaucoup de votre aide.

    J’ai juste une dernière question et après, promis, j’arrête de vous embêter^^

    Pour mettre le script bash en cron sur webmin, je ne suis pas très sûre de moi:
    Quand je met “créer une nouvelle tâche cron” dans webmin, qu’est ce que je met dans le champ “commande”?
    Est-ce que je dois juste mettre ca: /root/toto/backup.sh ??

    Je voudrais éviter de faire une bétise.

    Merci d’avance pour votre aide.
    Et encore merci de votre disponibilité.

    Della

  • Nico:

    Vous pouvez effectivement (pourquoi pas) vous servir de Webmin pour ajouter la tâche cron. La commande exacte à lancer est :

    sh /chemin/vers/script.sh

    Vous pouvez également lui adjoindre >/dev/null 2>/dev/null, histoire d’envoyer la sortie de la commande dans /dev/null et ainsi ne pas polluer vos logs. Soit :

    sh /chemin/vers/script.sh >/dev/null 2>/dev/null

  • Della:

    Merci beaucoup!

    Bonne continuation.

  • Phil:

    Désolé mais c’est totalement imbitable.
    Vous parlez d’une commande rsync, mais elle ne figure nulle part, les instructions sont dans le désordre le plus total. J’aimerais un étape par étape pour y arriver. On se logge où ? comment ? Pourquoi on crée un compte spécial ? Et on lui donne quoi comme paramètre, etc, etc. Je n’en suis qu’au tiers et déjà j’ai “interprété” ce que vous avez dit et je suis SÛR que ça ne va pas marcher.
    Donc voilà, pardonnez mon exaspération, mais c’est toujours comme ça : on a aucune info, on est obligé de partir à la pêche, d’essayer dix mille méthodes et au final, c’est frustration sur frustration.

  • Nico:

    De fait, la frustration est palpable … mais il ne sera pas dit que je ne tiendrai pas compte de tous les commentaires, même désobligeants. Il doit forcément y avoir un fond de vérité, je vais donc tenter de clarifier le billet, notamment en précisant ce qui doit être fait sur quel serveur.

    En revanche, n’attendez pas que je détaille les quelques instructions linux qui figurent dans le billet – à propos, je ne comprends pas bien le bout de phrase “Vous parlez d’une commande rsync, mais elle ne figure nulle part” – pour plus de détails quant à leur fonctionnement, il vous suffit de taper “man rsync” dans Google (ou éventuellement connecté en SSH sur votre serveur) et de lire la doc.

    Merci de patienter quelque peu, mon emploi du temps est un peu bousculé ces derniers jours. Je m’y attèle dès que possible.

  • Jappy:

    bonjour nico, juste pour expliquer le commentaire négatif, on ne voit pas le lien rsync si on n’ajuste pas la fenetre Script en appuyant sur la fleche bas

    un peu simple pour expliquer mais en fait si on connait peu de chose, on voit rien

    merci pour ce site

  • Nico:

    Cela ne se produi(sai)t qu’avec Internet Explorer … mais bon dieu qui utilise encore ce navigateur ? 😀

    Non, sans rire, je viens de rajouter un ou deux retours à la ligne pour améliorer la lisibilité mais je ne pense pas que ce soit ça qui ait énervé l’intervenant précédent. J’ai partiellement réécrit ce billet depuis lors car, à l’époque, il est vrai qu’il manquait un peu de clarté. A présent, je pense que même notre ami Phil devrait pouvoir y trouver son bonheur 😉

  • Citizen:

    Je confirme, c’est clair, lisible, didactique, et toutes les infos que j’attendais s’y trouve.
    Mille merci.

  • Bonjour,
    Merci pour cet excellent tuto, simple et efficace et qui, je pense, enlevera bien des soucis a de nombreux webmaster qui ne sont pas au top (pas du tout!) avec Linux. En tout cas, avec moi, ca en fait un de plus.

    Une question:
    Je ne trouve, sur mon serveur backup, un fichier authorized_keys2 que dans /root/.ssh/ et non pas dans /home/backupserveur1/.ssh/
    Dois-je creer ce fichier (/home/backupserveur1/.ssh/authorized_keys2/) ou alors copier ma cle dans le fichier existant /root/.ssh/authorized_keys2 ?
    Merci.
    Steph-

  • Nico:

    Il vous faut effectivement créer le fichier /home/backupserveur1/.ssh/authorized_keys2 (et même au besoin le répertoire .ssh).

    Inutile de toucher à /root/.ssh/authorized_keys2 : ce fichier concerne l’utilisateur root (il est donc même préférable de ne pas y toucher).

  • Merci! 🙂
    Effectivement, tout ce qui commence par “root”, je prefere eviter d’y toucher.

  • Bon, bon bon…
    Un petit probleme.
    Le script fonctionne dans le sens ou il va bien recuperer les donnees pour les copier sur le serveur de backup, mais il y a un probleme de permission. Aucun des fichier ne peut etre ajoute et aucun repertoire ne peut etre cree:
    “Permission denied (13)”
    “rsync error: some files could not be transfered”
    etc, etc…
    Betement je pensais qu’il fallait ajouter des droits a l’utilisateur “backupserveur1” ou alors l’ajouter dans des groupes, mais ca ne semble pas etre aussi simple que ca! J’ai cherche dans les forums, suis tombe sur des histoires de SUDO etc… mon seuil de competence est largement depasse!!! 🙁
    Si vous aviez une solution miracle (on ne sait jamais) ou alors une indication qui puisse me mettre sur la voie, je suis preneur!

  • Nico:

    Difficile malheureusement de vous répondre sur base de ces seules informations.

    Eu égard à votre commentaire précédent, je commencerais peut-être par aller jeter un coup d’oeil du côté des permissions/propriétaire du répertoire /home/backupserveur1/.ssh ainsi que du fichier /home/backupserveur1/.ssh/authorized_keys2

  • Bravo!
    Votre reponse m’a mis sur la voie qui m’a menee a la solution miracle! J’ai simplement du changer les droits d’ecriture sur un repertoire (si simple!).

    J’ai un script qui a l’air de fonctionner (dans une version test, je fais une sauvegarde d’un repertoire) et il me semble a voir compris quelque chose a ce que j’ai fait, ce qui n’est pas la moindre des victoires. 😉

    Bon, je vais essayer de m’en sortir tout seul maintenant…
    essayer…

    Merci infiniement pour votre aide.

  • Desty Nova:

    Je cherchais une bonne soluce de sauvegarde des fichiers pour haute dispo, après avoir mis en place un serveur miroir avec configuration prête à l’emploi en cas de crash du serveur de prod et bascule IP failover.

    Merci donc pour cet article.
    Pour compléter mes connaissances limitées en admin Linux, j’ai googlisé quelques trucs notamment pour adapter la commande rsync à mes besoins.
    Ex: partir sur une liste blanche (include-from) au lieu d’une liste noire (exclude-from) et formater le backup-include correctement: http://www.developpez.net/forums/d699437/systemes/linux/administration-systeme/rsync-exclure-sauf/

    Bon conseil aussi de creuser un peu le man rsync pour bien comprendre ce qu’on fait et ne pas supposer que les commandes fournies sont sans erreur.
    Merci a toi, keep on the good work

  • Jibi:

    Bonjour et merci pour ce joli tuto,

    J’aimerais avoir votre avis sur l’utilisation que je vais faire de Rsync : voilà le topo
    – J’ai 3 serveurs, A, B et C chez Online
    – Le serveur A est mon serveur principale
    – Le serveur B est mon serveur de secours
    – Le serveur C est mon serveur de sauvegarde

    J’aimerais mettre en place un système simple mais fonctionnelle (voir rapide) pour qu’en cas de pépin sur mon serveur A, le B prenne la relève le plus vite possible.

    Mon idée est alors de faire des sauvegardes régulières de A sur C, et de mettre à jour A et B simultanément (nouveau site, nouveau FTP, nouvelle config ..) ainsi en cas de pépin, j’ai exactement les même configs sur les deux serveurs et n’est plus qu’a prendre la dernière sauvegarde présente sur C et la transférer pour avoir les données à jours.

    Ou alors on peut directement passer les données de A à C, mais en cas de pépin sur A, C devient inutilisable puisqu’il sera sa copie ?

    Pensez-vous que c’est une bonne solution, y a t-il mieux à faire ?

    Merci.

  • Nico:

    A mon sens, un montage tel que vous l’imaginez n’a de sens que dans une architecture type “haute-disponibilité”, ce qui supposerait de mettre en place une synchronisation permanente des données entre A et B ainsi qu’une bascule automatique d’une IP failover de A vers B en cas de défaillance de A (j’ignore si c’est faisable chez Online, je ne connais pas du tout). Cette bascule d’IP est tout à fait indispensable car, sans cela, que ferez vous en cas de défaillance de A ? Changer les DNS de chaque domaine hébergé sur le serveur en prenant dans les dents cette foutue période de propagation des DNS ? Bof…

    Les architectures HA sont relativement complexes à mettre en place et à maintenir dans le temps. Elles ne se justifient que si les sites hébergés sont d’importance suffisamment critiques pour ne tolérer aucun downtime, jamais. Dans tous les autres cas (de loin les plus fréquents), un serveur de production et un serveur de backup suffisent largement. Il est vrai que cela suppose potentiellement quelques heures d’interruption de service en cas de perte totale du serveur A, le temps pour les techniciens du datacentre de faire les réparations qui s’imposent, mais c’est le genre de chose qui arrive somme toute très rarement…

  • Jibi:

    Merci bien 🙂

  • pilou:

    Super tuto. Bien pratique quand on n’y connait pas grand chose. Pour ma part j’ai ajouté au rsync l’option -v pour avoir la liste des opérations effectuées. Pour la copie de la clé SSH j’ai utilisé “ssh-copy-id -i /usr/share/keys/key-rsync.pub login@host:path”

    a+

Laisser un commentaire