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.

Lenteurs Proftpd

Note à moi-même : dans mes futures configurations, toujours inclure ceci dans mes fichiers configurations Proftpd (il s’agit du serveur FTP que j’utilise habituellement)

IdentLookups			off
UseReverseDNS			off

Les résolutions DNS sont souvent un facteur de ralentissement du serveur FTP et sont rarement utiles dans le cadre de serveur LAMP. Marre des clients qui râlent à cause de leur connexion FTP qui rame, donc basta ! 🙂

Bases de données MySQL : backup quotidien

Voici un petit script tout simple qui vous permettra de gérer une sauvegarde quotidienne de vos bases de données MySQL. Il utilise mysqldump, mais sans l’option all-databases. Il génère donc un fichier par base et par jour (plus pratique pour la restauration des backups). La date de chaque backup se trouve dans le nom du fichier et 30 jours d’historique sont conservés. Il est donc possible de récupérer l’état de chaque base de J à J-30 🙂

Mise en garde

Attention, ce script crée un dossier /home/backupsql (paramètre modifiable) dans lequel il crée et il supprime des fichiers. N’utilisez pas ce répertoire pour stocker quoi que ce soit…

Le script

#!/bin/bash

#
# PARAMETRAGE
#

PASSWORD=xxxxxxxx
CHEMINSQL=/var/lib/mysql
CHEMINBACKUPSQL=/home/backupsql

#
# SCRIPT BACKUP MYSQL
#

mkdir -p $CHEMINBACKUPSQL
find $CHEMINBACKUPSQL -mtime +30 -exec rm -f {} \;
for base in `ls $CHEMINSQL/`
do
if [ -d $CHEMINSQL/$base ]
then
mysqldump -u root --password=$PASSWORD $base > $CHEMINBACKUPSQL/`date -I`-$base.sql
fi
done

Appelez le par exemple backup.sh et n’oubliez pas de le mettre en cron (avec l’instruction “sh /chemin/que/vous/voulez/backup.sh“) , une fois par jour (de préférence la nuit lorsque le trafic sur votre serveur est faible voire nul).

Explications

Il n’y a que 3 paramètres à modifier :

PASSWORD=xxxxxxxx
CHEMINSQL=/var/lib/mysql
CHEMINBACKUPSQL=/home/backupsql

PASSWORD est votre mot de passe root MySQL (pas le pass root du serveur). CHEMINSQL est le répertoire dans lequel se trouvent vos bases (probablement /var/lib/mysql). CHEMINBACKUPSQL est évidemment le répertoire dans lequel vous voulez stocker les backups.

Le reste n’est qu’une petite boucle qui va parser le répertoire CHEMINSQL et effectuer un mysqldump sur chaque base trouvée.

Notez la ligne :

find $CHEMINBACKUPSQL -mtime +30 -exec rm -f {} \;

Elle est destinée à effacer tous les fichiers vieux de plus de 30 jours dans le répertoire CHEMINBACKUPSQL, on conserve ainsi 1 mois de sauvegardes. Si vous souhaitez modifier cette période de temps, il suffit de modifier le 30 par le nombre de jours voulu.

Offre de VPS infogéré

Bon, allez, c’est décidé, je lance une offre de VPS infogéré. Je n’arrête pas de voir de tous côtés des webmasters qui souhaitent quitter le “mutu” pour passer au serveur dédié, mais qui ne savent pas très bien par où commencer … et à qui on a raconté tout et n’importe quoi !

Voici donc officiellement l’offre Syrelis spéciale “dédié pour débutants” !

Le but est clairement d’assister les webmasters dans leur passage au serveur dédié, de leur mettre le pied à l’étrier en quelque sorte. Cette offre fait déjà le bonheur de plusieurs client (qui ont fait office de bêta-testeurs, merci à eux). Il est à présent temps de proposer officiellement le produit. Envie de passer au dédié ? On vous attend sur nos VPS. Et la liberté reste totale : une fois que vous vous sentirez à l’aise avec la bête, rien ne vous empêche de migrer votre VPS sur un votre serveur dédié à vous…

Release OVH : spamassassin et le bug de l’an 2010

Un bug connu depuis belle lurette déclenche encore pas mal de faux-positifs sur certains spamassassin. C’est dû au fait qu’une des règles utilisées fai(sai)t que tout mail qui a une date éloignée dans le futur voit sa probabilité d’être considéré comme spam augmenter fortement. Jusque là, rien que de très normal : il est louche de voir passer des mails dont la date est en avance de plusieurs années sur le date présente. Oui mais voilà, la règle en question (assez ancienne) stipulait que 2010 est une année éloignée dans le futur … suffisamment éloignée pour titiller spamassassin. Pas de bol, on y est finalement arrivés en 2010 !

Ce bug a été très vite mis à jour dès le début de cette année, à vrai dire dès qu’un grand nombre d’admin ont commencé a voir passer des cargaisons entières de faux-positifs (des mails classés abusivement comme spam par spamassassin). Le bug a été rapidement corrigé et la situation est revenue à la normale. Cela supposait cependant de faire la mise à jour qui va bien … ce qui n’a toujours pas été fait à l’heure actuelle sur la distribution phare d’OVH : la release 2.

Pour ceux qui utilisent cette distribution et qui se servent de spamassassin, il convient donc de faire le mini-patch suivant : dans le fichier /usr/share/spamassassin/72_active.cf (ligne 565), remplacer :

header   FH_DATE_PAST_20XX    Date =~ /20[1-9][0-9]/ [if-unset: 2006]

Par :

header   FH_DATE_PAST_20XX    Date =~ /20[2-9][0-9]/ [if-unset: 2006]

Votre spamassassin considérera alors comme “futur éloigné” les dates de 2020 à 2099 (et non plus 2010 à 2099).

Release 2 OVH : garder son serveur à l’heure

C’est au moins la millième fois qu’on me pose la question, alors vite vite un petit billet.

Mais comment fait-on pour garder son serveur à l’heure ? Rien de plus simple, il suffit d’installer NTP. Sous Debian, cela se limite donc à un petit :

apt-get install ntp

Et si on a un serveur en release 2 OVH ? Hein ? Fichue release 2 si complexe à gérer !

Et bien non, ce n’est pas plus compliqué, Gentoo a aussi son getionnaire de paquets. Paf :

emerge net-misc/ntp

Après, rien ne vous empêche d’aller fureter dans /etc/ntp.conf, par exemple pour ajouter le serveur de temps OVH (server 213.186.33.99). Ne pas oublier de relancer NTP par après…

/etc/init.d/ntpd restart

Ah oui, j’oubliais, il est aussi bon de lancer NTP au démarrage du serveur. Manipulation inutile sous Debian mais nécessaire sous Gentoo. Donc :

rc-update add ntpd default

Et pissétout 🙂

SSH : Somme des ressources par utilisateur

Ce n’est qu’un petit quelque chose mais je me le note ici, ça resservira sûrement plus tard…

Question : en SSH, comment savoir quelle est la somme des ressources (mémoire, CPU) consommées par un seul et même utilisateur ? Si possible sans trop se prendre la tête… On pense tout de suite à des outils comme top, htop, ps,… Oui mais ça ne fait pas la somme par utilisateur. Et bien grâce à ce petit topic sur le forum OVH (et indirectement cette page), voici une bien jolie commande à passer en SSH et qui répond à la question :

ps aux | awk 'NR != 1 {x[$1] += $4} END{ for(z in x) {print z, x[z]"%"}}'

La commande ci-dessus donne la quantité de mémoire consommée par utilisateur. On peut évidemment très facilement étendre ça au CPU :

ps aux | awk 'NR != 1 {x[$1] += $3} END{ for(z in x) {print z,  x[z]"%"}}'

Bon, les erreurs d’arrondi restent lourdingues mais c’est quand même pas mal.

Debian : Mise à jour de Bind9 fait buguer Webmin

Une récente mise à jour de Bind dans les dépôts Debian induit un léger bug dans Webmin / Virtualmin.

Ceux qui sont dans le cas (Webmin / Virtualmin installé sur une Debian Lenny) et qui mettent à jour (apt-get upgrade) apercevront sans doute que Bind “ne tourne plus”. En tout cas c’est ce que vous dira votre Webmin. Si vous essayez alors de lancer Bind via Webmin, vous obtiendrez une jolie erreur “Unknown Error”. Pas vraiment rassurant…

Heureusement, c’est en fait nettement moins grave qu’il n’y paraît : Bind tourne bel et bien (un petit passage en SSH vous le confirmera vite), c’est simplement Wembin qui ne le détecte plus. Pour fixer ça, il suffit de se rendre dans Webmin -> Servers -> BIND DNS Server -> Module Config -> System configuration et ajouter ceci dans Default PID file location(s) :

/var/run/bind/run/named/named.pid

Avec le bon chemin vers named.pid, Webmin retrouvera ses petits et il ne vous embêtera plus 🙂

Source : https://www.virtualmin.com/node/14569 (inscription nécessaire sur le site)

Attention, cela concerne aussi les nouvelles installations : pour ceux qui ont l’habitude d’installer Virtualmin sur Debian, ne soyez pas surpris de constater que Bind ne “semble” pas tourner sur une installation fraîche (la manipulation pour fixer le bug est évidemment identique).

Allez, c’est parti

Bon, et bien voilà… Des années après l’avènement du web 2.0, je me décide enfin à bloguer un petit coup. Il n’est jamais trop tard pour bien faire.

Je me suis concocté un chouette petit template WordPress (chacun appréciera) et hop, c’est parti !