Aujourd'hui, après avoir décrit l'installation et la configuration d'un serveur domotique avec mon exemple personnel, parlons sauvegardes et accès à distance.

Je commence avec ce message fort, bien connu dans la communauté des aficionados de NAS et d'auto-hébergement en général : faire du RAID ne dispense pas de faire des sauvegardes.

En effet, il ne faut pas oublier que si vous avez un serveur, son point faible est le disque dur : c'est sans doute l'élément le plus embêtant à changer, car il faut tout réinstaller.
Pour ma part, l'OS de mon serveur tourne sur un simple SSD (pas de RAID) : s'il rend l'âme un jour, je devrai trouver un remplaçant (ça c'est facile, des disques durs de faible capacité, ça ne coûte pas cher), réinstaller l'OS dessus, puis réinstaller tous les services applicatifs.

Je gère la première étape manuellement : télécharger le dernier ISO de Ubuntu Server, le mettre sur une clé USB, dérouler l'installation.
La deuxième étape se fait par des playbooks Ansible.

Pour gagner du temps sur ces deux étapes, vous pouvez également mettre en place du RAID, mais ça ne vous évite pas les pires catastrophes, qui à mon avis sont : le vol, et les dégâts physiques (feu, surtension, inondation, etc.).

Architecture des sauvegardes

Je planifie généralement trois types de sauvegardes :

Locales (données applicatives), principalement pour revenir en arrière en cas de problème suite à une mise à jour ou à une fausse manipulation. Concrètement, je mets en place un script de sauvegarde hebdomadaire, en crontab :

0 3 * * 0 /bin/bash /home/hugues/saveScript.sh >>/var/log/saveScript.sh 2>&1

Dans lequel on y trouve du chiffrement GPG à la volée, une compression, et un stockage des copies dans un répertoire dédié.
Pour faire court, je ne vous montre ici que le backup des applications certbot et lexicon, dont on parlera plus loin :

#!/bin/bash
passphrase="votre-passphrase-ici"

# creating archives 
cd /mnt/data
tar -zc certbot/ lexicon/ | gpg -c --batch --passphrase "$passphrase" -o certbot-lexicon.tar.gz.gpg
[...]

# moving files
mkdir -p backups
rm -f backups/*
mv *.gpg backups/
rclone -v copy backups/ aws:votre-stockage-aws-ici

À un instant donné, je n'ai donc qu'une seule sauvegarde de disponible en local : celle du dimanche précédent. L'archivage est géré par un stockage distant, qui est introduit par l'utilitaire de la dernière ligne : rclone.

Distantes (données applicatives) : rclone est un utilitaire en ligne de commande qui permet d'envoyer des fichiers sur différents clouds publics. Pour ma part, je m'en sers pour envoyer mes sauvegardes hebdomadaires sur AWS S3 (Simple Storage Service). Ça n'est pas gratuit, mais ça me revient à moins d'un euro par mois :

Ceci pour environ 8 Go de données à chaque sauvegarde, avec 3 semaines de rétention, soit un total de 24 Go stockés chez Amazon : c'est l'aspect archivage qui, en cas de sauvegarde corrompue (il peut arriver de sauvegarder une archive vide !), me permet de revenir en arrière.

Héberger des données personnelles chez une société privée pose des problèmes de confidentialité, c'est pour cela que je chiffre tout en GPG - ce qui limite fortement les risques.

Distantes (données media) : ces données sont les seules à être en RAID (ce qui résoud le problème de redondance locale), mais représentent environ 5 To : difficile donc de sauvegarder le tout sur un cloud, ça reviendrait trop cher.

Une solution élégante serait d'avoir un deuxième NAS de capacité équivalente, hébergé chez quelqu'un d'autre, ou dans une résidence secondaire, et d'effectuer des sauvegardes croisées.

Cependant, pour limiter les coûts, j'ai simplement fait le choix d'avoir des disques durs externes à mon bureau, et je fais manuellement mais régulièrement des sauvegardes avec rsync, ce qui permet de synchroniser le NAS avec ces disques durs : seuls les nouveaux fichiers sont sauvegardés.

Accès à distance

Une fois réglée la problématique des sauvegardes, une autre question majeure qui est soulevée est celle de l'accès à distance (depuis internet) : comment bien le faire, de façon sécurisée et simple ?

Il y a beaucoup d'approches différentes et bien documentées ailleurs, je ne vais donc que vous présenter la mienne. L'avantage est ici un contrôle total de la chaîne.

Acheter son nom de domaine : par simplicité, je loue le mien chez AWS Route 53. Un domaine en .net coûte généralement moins cher : je paie le mien 11€ par an environ. Dans l'onglet serveurs de noms de Route 53, j'indique ceux de Cloudflare.

Cloudfare est l'outil de résolution de mon alias DNS : c'est un mastodonte dans ce domaine. C'est ici que j'associe mon nom de domaine à mon adresse IP, mais en réalité c'est un outil qui le fait pour moi : Lexicon.

Lexicon est un utilitaire dédié à la manipulation d'entrées DNS. J'ai donc une crontab qui tourne une fois par jour et lance un conteneur Docker (mais vous pouvez le faire avec un simple script), où l'outil va s'authentifier sur Cloudflare et mettre à jour mon IP, si besoin.

L'accès à distance est désormais possible :

Une fois tout cela mis en place, il ne vous reste qu'à ouvrir les ports nécessaires sur votre routeur. Pour l'IPv6, c'est suffisant, et pour l'IPv4, il faudra ajouter des règles de NAT en plus.

Trouvez-vous également un guide pour générer un certificat TLS (avec de bons paramètres), par exemple avec certbot qui le fera pour vous, avec un renouvellement automatique :