Pré-requis

  • Une machine sous Debian que nous allons backuper, appelons-la production
    • Un serveur de backup avec accès SSH (SSH est requis pour rsync mais vous pourriez avoir un simple serveur FTP), appelons-la backup
  • Savoir modifier des fichiers de configuration et relancer un service

Configurez le compte sur le serveur de backup

Pour pouvoir envoyer les sauvegardes vers le serveur backup via rsync, nous avons besoin de nous identifier sur ce serveur à partir de production sans spécifier de mot de passe.

Tout d'abord, travaillons en root sur production : sudo -s

Créez les clef SSH pour root : ssh-keygen -t rsa

Après avoir tapé la commande précédente, la clef publique va s'installer dans /root/.ssh/id_rsa.pub et la clef privée dans /root/.ssh/id_rsa

À présent, considérons backup, vérifiez que votre serveur SSH sur backup accepte l'authentification par clefs privées. Dans le fichier /etc/ssh/sshd_config, les lignes suivantes doivent apparaître (non commentées) :

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile     %h/.ssh/authorized_keys

Sinon, ajoutez-les et relancez le service ssh.

Maintenant, ajoutez l'utilisateur prod_server sur backup : useradd prod_server
Vous pourriez avoir envie changer son dossier home, je suppose que vous savez comment le faire.

Retour sur production, copiez la clef publique dans le fichier /home/prod_server/.ssh/authorized_keys de backup.
La méthode bourrin : scp /root/.ssh/id_rsa.pub root@backup:/home/prod_server/.ssh/authorized_keys
La méthode gentlemen : copiez-collez le contenu de production:/root/.ssh/id_rsa.pub à la fin du fichier backup:/home/prod_server/.ssh/authorized_keys

Si vous avez tout fait correctement, vous devriez pouvoir vous connecter en ssh depuis votre compte root de production sur le compte prod_server de backup sans spécifier de mot de passe.

Installez backninja (et ses amis)

Sur production, entrez la commande : sudo apt-get install backupninja duplicity rsync

Configurez le dump des bases de données

C'est parti, configurons backupninja !

Pour MySQL, copiez le fichier d'exemple à partir de /usr/share/doc/backupninja/examples/example.mysql dans le dossier /etc/backup.d/10-alldb.mysql et modifiez-le pour vos propres besoins (le fichier est simple et bien commenté).

databases   = all
backupdir   = /var/backups/mysql
hotcopy     = no
sqldump     = yes
compress    = yes
configfile = /etc/mysql/debian.cnf

Pour PostgreSQL, même chose ! Copiez le fichier /usr/share/doc/backupninja/examples/example.mysql dans le dossier /etc/backup.d/10-alldb.pgsql et modifiez les valeurs souhaitées.

backupdir = /var/backups/postgres
databases = all
compress = yes
format = plain

Pourquoi est-ce que j'utilise le préfixe 10- au début de mes fichiers ? Pour la même raison pour laquelle vous préfixez vos fichiers de configuration Nginx : pour gérer l'ordre de lecture. J'ai besoin de créer les dumps des bases de données avant de créer le backup des fichiers, sinon Duplicity enregistrera les fichiers de la veille, et les fichiers que nous venons de créer devront attendre le lendemain pour être sauvegardés ! Donc, les fichiers de configuration qui vont créer les dumps seront préfixé par 10- et les fichiers pour configurer le backup incrémental de Duplicity seront préfixés par 20-, par exemple.

Les dumps SQL seront stockés dans /var/backups/ selon ma configuration actuelle.

Configuration de Duplicity pour le backup incrémental

Comme tout à l'heure, copiez le fichier d'exemple : cp /usr/share/doc/backupninja/examples/example.dup /etc/backup.d/20-files.dup

Et modifiez les valeurs, en particulier la valeur desturl :

# Disable testconnect because we use desturl
testconnect = no

# You may change this if you are a partition-maniac
tmpdir = /tmp

[gpg]
# Using symetric encryption for archive files
# Note that an encryption method is mandaory, either with symetric or private keys
# Don't forget to note that password somewhere !
password = whateveryouwant

[source]
# Specify the paths to your files
include = /var/spool/cron/crontabs
include = /var/log
include = /var/mail
include = /var/www
include = /etc
include = /root
include = /home
include = /usr/local

# And to your database dumps !
include = /var/backups/mysql
include = /var/backups/postgresql

# There are some files we don't need
# Don't forget to add the tmpdir in the exclude list, if it was included in the previous paths !
exclude = /home/*/.gnupg
exclude = /var/cache/backupninja/duplicity
exclude = /tmp

[dest]
# Adjust these to your own taste
incremental = yes
increments = 15
keep = 30
keepincroffulls = all

# Specify the backup server crendentials
## desturl = file:///usr/local/backup
## desturl = rsync://user@other.host//var/backup/bla
## desturl = s3+http://
## desturl = ftp://myftpuser@ftp.example.org/remote/ftp/path
desturl = rsync://prod_server@backup//home/prod_server/data

# Only if you choose FTP
# ftp_password = whateveryouwant

Cette configuration utilise un chiffrement symétrique pour les archives sauvegardées. Si vous voulez mettre en place un chiffrement asymétrique, vous pouvez lire la documentation et adapter la configuration.

Configurez la fréquence des backups

Vous avez peut-être remarqué que backupninja a créé un cronjob dans /etc/cron.d/backupninja mais si vous ouvrez ce fichier, vous constaterez que le cronjob est lancé toutes les heures. Pourquoi ? Parce que le cronjob n'est utilisé que pour lancer le backup, qui vérifie si une mise à jour du backup est nécessaire avant de lancer réellement l'opération de backup. Pour modifier les heures et la fréquence des mises à jour, vous pouvez modifier le fichier /etc/backupninja.conf :

when = everyday at 01:00

Ajustez la valeur selon vos souhaits. Vous pouvez combiner plusieurs lignes, si vous voulez plusieurs dates de démarrage (en savoir plus).

Démarrez votre backup, et vérifiez son bon fonctionnement

C'est le moment de démarrer votre backup pour la première fois ! Si vous ne voulez pas attendre une heure pour que le cron se lance, vous pouvez lancer le backup immédiatement avec la commande backupninja -d -n

Si aucune erreur ne s'affiche pendant l'exécution, bravo ! Vous venez de configurer backupninja avec succès !

À présent, contrôlons que notre backup est bien arrivé : connectez-vous à backup et listez le fichiers dans le dossier /home/prod_server/data/

Vous devriez voir les fichiers d'index créés par Duplicity, vous ne pouvez pas les ouvrir sans utiliser quelques commandes :

  • Afficher le statut des "collections" : duplicity collection-status file:///home/prod_server/data
  • Lister les fichiers dans l'archive : duplicity list-current-files file:///home/prod_server/data
  • Restaurer le dernier backup dans un dossier précis duplicity restore file:///home/prod_server/data/ /home/prod_server/test-restore/ (si vous ne voyez des erreurs mais que les fichiers sont bien présents à la fin de l'exécution de la commande, c'est parce que Duplicity essaye de restaurer les atributs "prorpiétaire" des fichiers, et qu'il ne peut pas le faire si vous n'avez pas lancé la commande en root).

Vous devez avoir le programme Duplicity installé sur le serveur backup  pour pouvoir utiliser ces commandes en mode shel sur backup.

Vous pouvez aussi lancer ces commandes sur le serveur production et accéder aux backups stockés sur backup en utilisant la desturl que vous avez configurée au lieu du préfixe file:// que vous utilisez quand vous lancez la commande sur backup.

Conclusion

Vous devriez maintenant être capables d'implémenter une solution complète de backup en utilisant backupninja.

J'espère que cet article vous a été utile, vous pouvez rédiger un commentaire via le formulaire ci-dessous si vous rencontrez des problèmes avec cette documentation.