Faire un backup automatisé de son site avec son NAS Synology

Vous avez pu le voir récemment avec l’incendie chez OVH, il y a toujours une bonne raison de rajouter un support supplémentaire de backup, pour avoir un autre accès rapide à ses données pour remettre son site en service.

Pourquoi donc un NAS Synology ? Parce que j’en ai un depuis des années, que la communauté est assez énorme, et que c’est somme toute assez simple à installer : On le branche à sa box, au courant, on installe et on l’oublie. Si ça vous va, appelons le « Syno » pour la suite, ça sera plus simple.

Ce tutoriel va vous guider dans la mise en place d’un backup des données depuis votre site, récupérées automatiquement par le Syno depuis le ou les sites. Pourquoi ne pas les envoyer depuis le site ?

Parce que les accès au Syno devraient être disponibles sur chaque serveur distant, ce qui évite de devoir changer tous les accès si un client tombe dessus.
Parce que tous les serveurs ne peuvent envoyer des données à distance automatiquement
Parce que vous pourrez consulter vos logs à un seul endroit, ce qui est assez pratique.

Evidemment, ça ne sera pas votre seul backup, ça ne sera pas le plus redondant et ça vous ne vous dispense pas d’observer la règle 3-2-1 [en]. Mais ça vous fera potentiellement un backup accessible même sans Internet, qui pourra entre autres vous servir pour bosser en local sur des données fraîches.

Note : si vous avez un Syno récent, vérifiez si vous pouvez installer Active Backup, ça vous évitera une bonne partie du tuto dans votre terminal et ça sera un peu plus maniable. Evidemment, moi j’ai un vieux Syno donc ¯\_(ツ)_/¯.

Note 2 : On est encore sur une version un peu brouillon de l’article, mais j’ai tout testé comme il faut.

Créer le dossier de destination

Premier point tout bête, mettez votre synology à jour.
Accédez au Panneau de configuration du back-office de votre NAS depuis votre navigateur via un user admin.
Passez en mode avancé ( toutes les icônes visibles )
Créez un nouveau Dossier Partagé nommé « Backups » ( imaginatif hein ) qui sera restreint aux admins pour le droit d’écriture. Donnez à vos utilisateurs habituels un droit de lecture, bien entendu.

Configurer l’accès SSH

Créez un utilisateur spécifique aux backups. N’oubliez pas de lui donner les droits d’écriture au dossier Backups. Mettez le au niveau admin sinon ça coincera avec le SSH.
Activez les dossiers utilisateurs dans Utilisateur / Avancé / Activer le service d’accueil utilisateur ( ça sera utile pour les clés SSH ).
Activez le service SSH dans « Terminal & SNMP »
Dans votre terminal, accédez au NAS ( ssh monuser@ipdunas ) et tapez votre mot de passe. ( Vous pouvez ajouter votre clé SSH pour aller plus vite la prochaine fois )
Générez une clé SSH ( ssh-keygen -t dsa ) et notez le contenu de la clé publique ( fichier .pub dans ~/.ssh/ ) qui vous sera utile pour vos serveurs.
Vérifiez les permissions des fichiers liés à SSH avec les commandes suivantes.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
chmod 644 -f ~/.ssh/*.pub ~/.ssh/authorized_keys ~/.ssh/known_hosts

Créer le script de backup

Ici, rien d’extraordinaire, on crée un fichier shell dans lequel on va mettre des appels à rsync qui vont synchroniser un dossier distant (votre site) avec un dossier sur votre NAS. On ne détruit aucun fichier, et si une copie plus récente avec le même nom existe, on archive l’ancienne avec une date spécifique. Sauvegardez le sous un nom simple comme backup.sh et notez le chemin absolu vers ce fichier.

#!/bin/bash

rsync \
    -ruvzb \
    --backup-dir=_old \
    --suffix="-old-$(date +'%m%d%Y')" \
    monclient@monclient.com:/dossier-backups/ \
    /volume1/Backups/clients/monclient/;

Evidemment, lancez le une fois pour voir. Vous devrez notamment ajouter votre clé SSH publique au serveur distant. ( Copier le contenu du fichier .pub cité plus haut dans le fichier ~/.ssh/authorized_keys sur le serveur distant : je ferais un tuto à part si ça intéresse quelqu’un )

Programmer le backup

On retourne dans le back-office du Syno, dans la partie « Planificateur de tâches ».
Créez une nouvelle « tâche planifiée » de type « script défini par l’utilisateur ».
Nommez la tâche « backup », activez la et assignez la à l’utilisateur backup.
Programmez la par exemple à 3h du matin, mais vous pouvez aussi bien la lancer toutes les 6h pour une sauvegarde plus fréquente.
Dans les paramètres, lancez le script suivant avec le chemin de fichier que vous aurez noté plus haut.

/bin/bash /var/services/homes/MonBelUserBackup/backup.sh

Sauvegardez, et dans les Paramètres du planificateur, enregistrez les résultats de la sortie dans le dossier des backups. ça vous permettra de vérifier si tout marche bien demain matin.

Ajouter un projet

Initialisez une sauvegarde automatique sur votre serveur client. Par exemple : mysqldump pour sauvegarder la base de données, copier le contenu d’un fichier wp-config, etc, via un crontab ou autre.
Notez le dossier du backup des bases de données, et le dossier de vos uploads. Votre code est normalement sauvegardé via git, non ? 😉
Si votre base comporte un nom spécifique au jour, mettez un script de suppression automatique des fichiers les plus anciens.
Créez un dossier dédié sur votre Syno pour ce client / projet.
Ajoutez au script sur votre Syno de nouvelles lignes pour chaque dossier que vous souhaitez sauvegarder automatiquement. ( on peut optimiser cette partie mais ça n’est pas le sujet )
Testez le script pour être sûrs que le backup se lance bien.
Testez le backup 🙂

Et maintenant ? On teste encore !

Si vous n’avez rien, créez un cahier de recette, même minimal. Ajouter des lignes fonctionnelles à vérifier lors de vos tests. Par exemple : On accède à la page d’accueil sans erreur visible. On peut se connecter avec un login / password. Un formulaire de contact envoie bien un mail à l’adresse voulue. Etc.
Des tests fonctionnels et unitaires, c’est le top. Mais qui a le temps ? #troll
Préparez un plan de reprise d’activité simplifié. Simulez plusieurs problèmes type, imaginez des solutions, et testez les régulièrement.
Surveillez l’espace disque. Le synology c’est magique, car il vous avertit, mais sait-on jamais.

Je me sers de ces backups pour travailler en local sur le projet afin de vérifier de première main si tout fonctionne. Via mon activité freelance, j’ai une prestation de maintenance WordPress qui comprend le déroulé ponctuel d’un cahier de recettes sur un site et un backup, ce qui permet d’être sûr de pouvoir s’y retrouver en cas de souci.

Grâce à Todoist, j’ai des tâches récurrentes qui me permettent de vérifier ponctuellement si tout va bien, sans y penser. ( Et je backup aussi Todoist à part, merci la paranoia )

N’hésitez pas à me signaler dans les commentaires si vous avez besoin d’un éclaircissement ou si j’ai dit une bêtise, cet article me servira également de documentation pour le futur, donc autant vous faire bosser un peu 😉

Photo par Alex Cheung sur Unsplash.