Backup nocturne, auto-hébergé et green

Posté le 02. Janvier 2026  •  7 minutes  • 1446 mots  • Autres langues:  English

Suite à un déménagement, j’ai sorti du placard pas mal de vieux disques durs dormants et un peu de hardware.

Pourquoi ne pas réutiliser ce matériel fonctionnel pour avoir un backup supplémentaire à domicile ? Comment faire en sorte de consommer le moins d’électricité possible pour la planète et ma facture ? Comment déclencher ma sauvegarde en pleine nuit avec un serveur qui s’allume et s’éteint automatiquement ? Comment faire pour qu’un serveur distant puisse se sauvegarder de manière autonome à mon domicile et en toute sécurité ?

Il existe mille et une réponses à ces questions, mais j’ai choisi de vous partager ce que j’ai mis en place.

Une architecture simple et sécurisée

Mes objectifs pour l’architecture étaient les suivants :

• Pas d’ouverture de port sur ma box (NAT)
• Gérer une contrainte d’IP dynamique sur ma connexion internet personnelle
• Faire passer le trafic dans un tunnel sécurisé VPN
• Utiliser BorgBackup pour les sauvegardes
  • Utiliser BorgMatic côté client
  • Utiliser BorgWarehouse pour gérer les repositories BorgBackup du serveur de backup

Pour les trois premières contraintes, je vais y répondre aisément avec Wireguard. J’avais d’ailleurs fait un article en 2022 avec un petit benchmark de perf (vs OpenVPN) si ça vous intéresse.

WireGuard va me permettre plusieurs choses :

• Encapsuler le trafic réseau dans un tunnel chiffré entre mes serveurs dans le datacenter et mon serveur de backup à domicile.
• Initier la connexion VPN uniquement depuis mon domicile vers les endpoints de mes serveurs
  • Et par conséquent m’éviter d’ouvrir un port chez moi, de faire du NAT ou même de connaître mon IP publique

Voici le schéma simplifié que j’ai réalisé :

Je ne vous fais pas le détail de configuration VPN Wireguard entre les serveurs, c’est simple à mettre en œuvre et la documentation est très bien faite .

La solution de sauvegarde : le robuste BorgBackup

Côté serveur client, je vais partir sur une configuration de l’excellent Borgmatic . Sa documentation est bien faite et permet de configurer finement beaucoup d’options. Je déclencherai la sauvegarde depuis le client la nuit, sur un créneau sur lequel mon serveur de backup sera allumé.

Côté serveur de sauvegarde à domicile, je vais utiliser un conteneur Docker BorgWarehouse . Comme je passe par un tunnel VPN pour les sauvegardes, alors je vais paramétrer mon repository en mode LAN afin d’avoir une auto-configuration simple qui correspond à mon réseau Wireguard.

Enfin, je vais activer le mode append-only de BorgBackup côté serveur et désactiver la suppression de repository par le paramétrage de la variable d’environnement. Ceinture et bretelle, tout est prêt côté BorgBackup !

Le démarrage et l’extinction automatique du serveur de backup

J’ai épluché pas mal de documentations et j’ai retenu la solution du paquet rtcwake comme la plus adaptée à mon cas d’usage. C’est un paquet disponible sur plusieurs distributions Linux et qui, d’après son manuel fait exactement ce que je recherche : “Il utilise des interfaces Linux multiplateformes pour mettre le système en veille et ne pas l’y laisser au-delà d’une date indiquée. N’importe quel environnement de pilote d’horloge matérielle (RTC) prenant en charge les attributs de réveil normalisés peut être utilisé.”. Évidemment, il faudra qu’un module RTC soit présent sur votre machine, avec une pile fonctionnelle.

rtcwake dispose de plusieurs options très utiles mais je m’arrêterai uniquement sur les modes d’arrêt disponibles. Au nombre de 9, les seules options de mode qui peuvent m’intéresser sont :

• standby : Correspond à ACPI S1 avec l’alimentation toujours en service ainsi que les périphériques, mais le CPU est arrêté, en pause. Le retour à l’état normal est quasi instantané mais la consommation électrique est similaire à l’idle, donc ce mode ne m’intéresse pas.
• freeze : Ce mode ne correspond pas à un état ACPI. Je n’ai pas poussé les recherches mais ça semble être un mode du kernel Linux, l’activité électrique est semblable au standby. Ce mode ne correspond pas à mon usage.
• disk : Correspond à ACPI S4 (Suspend-to-disk) avec l’alimentation coupée, et le déchargement de la RAM sur les disques. Ce mode me correspond pour l’activité électrique proche du 0 constant. Cependant, il suffit d’une recherche sur le net pour voir que ce mode peut être instable pour un usage sur un serveur avec une recherche de stabilité et de sécurité.
• off : Correspond à ACPI S5, c’est un poweroff, il ne correspond pas à mon usage car mon serveur de backup a des partitions chiffrées nécessitant une intervention manuelle s’il est totalement coupé.
• mem : Correspond à ACPI S3 (Suspend-to-RAM) et parle de lui-même : “Cet état permet de réaliser d’importantes économies d’énergie, car tous les composants du système sont mis en veille, à l’exception de la mémoire, qui est placée en mode d’auto-rafraîchissement afin de conserver son contenu.” C’est le mode qu’il me faut !

Choix de l’horaire et mise en place d’une cron

Dans mon cas, j’ai un contrat d’électricité avec un système d’heures creuses (HC) et d’heures pleines (HP). Autrement dit, je paye mon électricité :

• 0,1635€/KWh de 00h32 à 6h32 et de 15h02 à 17h02
• 0,2081€/KWh en dehors des créneaux précédents

Je place donc le réveil de mon serveur à 1h du matin, et sa veille à 07h :

1

0 7 * * * root /usr/local/bin/rtcwake-safe.sh -m mem -t $(date +\%s -d "tomorrow 01:00")

Le backup de mon serveur client se déclenche à 01h05 chaque jour, et la tranche horaire de réveil de mon serveur de backup permet d’assurer les gros transferts de volumétrie mais aussi les éventuelles opérations de maintenance système automatiques (mise à jour, synchro RAID…).

La création d’un script supplémentaire à rtcwake

Vous l’avez remarqué sur la ligne de la cron ci-dessus, je n’exécute pas directement rtcwake. En fait, j’ai créé un petit script pour effectuer quelques vérifications avant la mise en veille :

• Une opération sur le RAID MDADM de mon serveur ne doit pas être en cours
• La sauvegarde dans BorgWarehouse doit être terminée (je check les process du conteneur)

Je vous partage mon travail, n’hésitez pas à l’adapter à vos usages ! Ce script est prévu pour Debian avec un raid MDAM et BorgWarehouse dans un conteneur Docker.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

#!/bin/sh

MAIL_TO="email@email.test"
HOSTNAME=$(hostname)
DATE=$(date)
DOCKER_CONTAINER="borgwarehouse"
BORG_COMMANDS="borg\s+(serve|prune|check|create|extract|list)"

# Notify func for email and logger
notify() {
    local MESSAGE="$1"
    echo -e "$MESSAGE" | /usr/bin/mail -s "[INFO] rtcwake blocked ($HOSTNAME)" "$MAIL_TO"
    logger -t rtcwake-safe "$MESSAGE"
}

# Check mdadm status
/usr/bin/grep -Eq '(resync|recovery|reshape|check)' /proc/mdstat && {
    STATUS=$(/bin/cat /proc/mdstat)
    notify "rtcwake cancelled\n\nServer : $HOSTNAME\nDate : $DATE\n\nRAID status :\n$STATUS"
    exit 1
}

# Check borg status in borgwarehouse container
docker exec -i "$DOCKER_CONTAINER" ps auxww | grep -P "$BORG_COMMANDS" | grep -v grep >/dev/null 2>&1 && {
    BORG_RUNNING=$(docker exec -i "$DOCKER_CONTAINER" ps auxww | grep -P "$BORG_COMMANDS" | grep -v grep)
    notify "rtcwake cancelled\n\nServer : $HOSTNAME\nDate : $DATE\n\nA Borg process is running in the container '$DOCKER_CONTAINER' :\n$BORG_RUNNING"
    exit 1
}

# Launch rtcwake
exec /usr/sbin/rtcwake "$@"

La consommation électrique et le coût

Si vous lisez ce blog, vous savez que j’utilise Home Assistant pour ma domotique et ça me permet notamment de connaître la consommation électrique de ma maison et des appareils que j’ai. On voit donc que l’état ACPI S3 consomme entre 0 et 1W. À vrai dire, ma prise n’a même pas la précision suffisante tellement la consommation dans ce mode S3 est ridicule.

On voit également que le mode idle de mon serveur de backup est en moyenne de 32W. Sur le graphique, on aperçoit la sauvegarde, incrémentale pour ce jour, et donc très rapide. Je pourrais réduire drastiquement la fenêtre d’allumage de mon serveur pour encore en optimiser la consommation. À voir dans les prochaines semaines, j’étudierai les temps de sauvegarde et les graphiques de consommation pour m’adapter.

D’après mes calculs et sur la base de mon abonnement d’électricité (HC/HP), voici les consommations suivant 3 scénarios :

L’économie est donc énorme en termes de consommation, avec l’avantage d’avoir des données sauvegardées chez soi, en toute sécurité.

Bon self-hosting à vous!

Si vous appréciez mes articles et projets, soutenez-moi sur Liberapay .