Passer au contenu 
J'automatise mon rsync backuppour éviter les pannes et planifier les restaurations. Avec des Travaux CronAvec le transport SSH et les exécutions incrémentielles, je sécurise efficacement les serveurs web, les bases de données et les configurations.
Points centraux
- Automatisation: Les tâches programmées réduisent les erreurs et les efforts.
- Efficacité: Le transfert delta permet d'économiser de la bande passante et de la mémoire.
- Sécurité: SSH, gestion des clés et cibles hors site.
- Stratégie: conservation du CCR et objectifs RPO/RTO clairs.
- Transparence: journalisation, surveillance et tests de restauration.
Pourquoi j'automatise les sauvegardes
Je sécurise systématiquement les systèmes productifs, car une seule panne peut stopper des projets entiers et je Disponibilité de l'entreprise. Une exécution de sauvegarde planifiée à 2 heures du matin remplace le travail manuel, sujet aux erreurs, et garantit des niveaux de données propres. Je définis des objectifs clairs pour chaque serveur : Quelle est la perte de données acceptable (RPO) et à quelle vitesse la restauration doit avoir lieu (RTO). Ces objectifs influencent le calendrier, la cible de stockage et les options, afin que je puisse sécuriser l'exploitation de manière fiable. Pour les serveurs web en particulier, je réduis ainsi à un minimum calculable les risques liés aux défaillances matérielles, aux ransomwares ou aux suppressions accidentelles.
rsync en bref : fonctionnement et points forts
rsync ne transfère que les modifications, utilise une méthode efficace Transfert delta et évite les copies inutiles. Cela réduit considérablement les temps d'exécution, la charge réseau et les IO sur le système cible. Je travaille en mode archive (-a) pour que les droits, les heures, les propriétaires et les liens symboliques restent cohérents. Avec -delete, je garde les miroirs à jour, mais je fais attention à l'utilisation prévue et je le combine avec des répertoires séparés pour le versionnement. Pour le transport, je mise sur SSH, pour les tâches locales sur des chemins directs, et j'ajoute si nécessaire la compression (-z) et la limite de bande passante (-bwlimit).
Automatisation avec Cron : étape par étape
Je commence par un script simple, parce que des Bases peuvent être développés ultérieurement. Tout d'abord, j'installe rsync s'il manque, et je crée un répertoire de travail sécurisé pour les logs et les statuts. Ensuite, j'écris un script avec les sources, la destination et les options utiles, y compris les exclusions. Le cronjob s'exécute tous les jours ou toutes les heures selon le RPO et écrit des fichiers log pour l'évaluation et les alertes. Un dry-run (-n) avant la première exécution productive empêche les suppressions indésirables.
# Installation (Debian/Ubuntu)
sudo apt-get install rsync
# Exécution minimale en local
rsync -a /data/www/ /backup/www/
# Miroir distant via SSH avec suppressions
rsync -a --delete -e "ssh -i /root/.ssh/backup_key" /data/www/ backup@backuphost:/srv/backups/www/
# Cron : tous les jours à 02h00
0 2 * * * /usr/local/bin/rsync-backup.sh >> /var/log/rsync-backup.log 2>&1
Mettre en place des sauvegardes SSH en toute sécurité
J'utilise des clés SSH avec des droits limités parce que Gestion des clés réduit la surface d'attaque. Sur le système cible, je limite les commandes par authorized_keys et j'utilise un utilisateur de sauvegarde séparé. Fail2ban, des règles de pare-feu et des options SSH restrictives (par ex. PasswordAuthentication no) augmentent la sécurité. Je fixe la clé d'hôte pour que Man-in-the-Middle n'ait aucune chance. Ceux qui cherchent un démarrage structuré trouveront des idées éprouvées dans la pratique sous Automatiser les sauvegardes.
Pull plutôt que Push : les avantages de la sécurité dans la pratique
Dans la mesure du possible, je laisse le Mise en mémoire tampon du serveur de sauvegarde au lieu de pousser le serveur de production. Ainsi, les systèmes de production restent sans clé sortante et un serveur web compromis ne peut pas supprimer les sauvegardes hors site. Sur la cible, je limite la clé dans authorized_keys avec des options restrictives et une commande forcée.
# Exemple authorized_keys sur la destination de sauvegarde
from="10.0.0.10",no-agent-forwarding,no-pty,no-port-forwarding,no-X11-forwarding,command="/usr/local/bin/rsync-serve-backups"
/home/backup/.ssh/authorized_keys
Le script appelé autorise uniquement les appels au serveur rsync et définit des limites de chemin. J'obtiens ainsi un Principe des droits minimauxLe système de gestion de la qualité de l'entreprise permet de réduire les coûts sans compliquer l'utilisation.
Versionnement et conservation avec des liens en dur
Pour plusieurs stands, je construis avec -link-dest des dossiers quotidiens, hebdomadaires et mensuels, car Liens en dur Économiser de la mémoire et simplifier les restaurations. Chaque génération fait référence à des fichiers identiques et non modifiés de la sauvegarde précédente, les fichiers nouveaux ou modifiés atterrissent physiquement dans le nouveau dossier. J'obtiens ainsi de nombreux points de restauration avec une consommation de mémoire modérée. Je supprime les anciennes générations à l'aide d'un simple script de rotation, sans risquer de perdre la cohérence des données. Un calendrier fixe (par exemple 7 jours, 4 semaines, 6 mois) permet de maintenir une planification de stockage claire et transparente.
Contrôler les ressources : Bande passante, CPU et E/S
Je limite le débit de données avec -bwlimit pour que Charge productive reste stable et que les utilisateurs ne ressentent pas de perte. Avec nice et ionice, je réduis les priorités des processus de sauvegarde. Sur les réseaux lents, j'active la compression (-z), sur les supports locaux rapides, je la laisse de côté. Pour les fichiers volumineux, je choisis -partial pour pouvoir reprendre les transferts interrompus. Pour les miroirs locaux, j'utilise souvent -whole-file, car l'algorithme delta n'y présente aucun avantage.
Des états de données cohérents : snapshots et bases de données
Pour obtenir des sauvegardes cohérentes malgré les fichiers ouverts, j'utilise Instantanés ou des hooks d'applications. Les systèmes de fichiers comme LVM, ZFS ou Btrfs permettent des snapshots rapides que j'utilise comme source pour rsync. Ainsi, je gèle logiquement l'état des données sans bloquer longtemps les services.
# Exemple : snapshot LVM comme source cohérente
lvcreate -L 10G -s -n data_snap /dev/vg0/data
mount /dev/vg0/data_snap /mnt/data_snap
rsync -a --delete /mnt/data_snap/www/ backup@host:/srv/backups/www/
umount /mnt/data_snap
lvremove -f /dev/vg0/data_snap
Pour Bases de données je sépare la logique et les fichiers. Je sauvegarde MySQL/MariaDB via un dump ou des solutions Percona/Xtra, PostgreSQL avec pg_dump ou basebackups. L'ordre est important : d'abord créer un dump cohérent, puis transférer le chemin du dump par rsync. J'évite ainsi les fichiers à moitié écrits dans la sauvegarde.
Les sources d'erreur typiques et comment les éviter
La pierre d'achoppement la plus fréquente est la barre oblique à la fin d'un chemin, c'est pourquoi je vérifie Indications du chemin double : /src/ vs /src. Je teste les exclusions avec -dry-run et -itemize-changes pour voir l'effet. Je cite correctement les modèles avec des espaces et je conserve le fichier exclude dans le référentiel. Avant -delete, je contrôle les montages, car une cible non montée peut entraîner une suppression non souhaitée. Enfin, je consigne les codes de retour et j'active les alarmes afin de voir immédiatement les erreurs.
Stratégie de sauvegarde : GFS et objectifs de restauration
Je détermine d'abord le RPO/RTO, parce que des Objectifs guider toute décision concernant la fréquence, le lieu de stockage et la rétention. Un schéma courant est GFS : quotidiennement différentiel, hebdomadairement complet ou fusionné via des liens en dur, mensuel à long terme. Les exigences de conformité influencent la durée de conservation, c'est pourquoi je sépare les données opérationnelles à courte durée de vie des archives à long terme. Pour les systèmes critiques, je prévois des sauvegardes hors site en plus des copies locales. Cette combinaison protège contre les pannes de site et permet des restaurations rapides et à distance.
Cron ou systemd-timer : une planification fiable
Cron est simple et robuste. Pour les hôtes qui dorment ou redémarrent occasionnellement, j'utilise en plus systemd-timer avec des dépendances et une gestion des exécutions manquées. Je m'assure ainsi qu'aucune exécution ne tombe en panne après un redémarrage et que l'ordre est correct (par ex. après la restauration du réseau).
# /etc/systemd/system/rsync-backup.service
[Unit]
Description=Sauvegarde Rsync
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/local/bin/rsync-backup.sh
Nice=10
IOSchedulingClass=meilleur-effort
IOSchedulingPriority=7
# /etc/systemd/system/rsync-backup.timer
[Unit]
Description=Temporisateur de sauvegarde Rsync quotidienne
[Timer]
OnCalendar=02:00
Persistent=true
[Install]
WantedBy=timers.target
Tableau : Options rsync importantes au quotidien
J'utilise peu de moyens, mais ils sont efficaces. Optionsque je documente par tâche et que je versionne dans le Repo. Le mode archive constitue la base et réduit les erreurs de configuration. Avec -delete, je garde les miroirs propres, mais je ne l'utilise qu'avec une vérification correcte de la cible. Pour le versionnement, je combine -link-dest avec un plan de rotation. Le tableau suivant montre les principaux commutateurs et leur utilisation.
| Option | Objectif | Remarque |
|---|---|---|
| -a | Mode archive | Reprend les droits, les temps, les propriétaires pour Consistance |
| -z | Compression | Utile pour le WAN, souvent à laisser de côté en local |
| -delete | Supprime les anciens fichiers | Utiliser uniquement pour les miroirs, avant Dry-Run |
| -bwlimit=KBPS | Réduire la bande passante | Protège Systèmes productifs contre les pics de charge |
| -link-dest=DIR | Versionnement via des liens en dur | Générations économiques avec des dossiers séparés |
| -e "ssh ..." | Transport sécurisé | Clés, clés hôte, utilisateurs restrictifs |
| -n / -dry-run | Essai sans changement | Indique les actions planifiées à l'avance |
Tester la restauration : exercices de restauration
Je teste régulièrement la restauration, car une sauvegarde sans restauration ne fait que Billet est de faire. Pour les échantillons, je restaure des fichiers individuels ainsi que des webroots entiers dans des environnements de staging. Je sauvegarde les bases de données séparément par dump et je les importe à titre d'essai pour vérifier la cohérence. Les sommes de contrôle m'aident à confirmer l'intégrité et à détecter les erreurs de bits silencieuses. Après chaque test, j'adapte la documentation, les scripts et les playbooks afin que le prochain cas d'urgence se déroule plus rapidement.
Sauvegardes bare-metal et système : spécificités
Pour les sauvegardes système ou bare metal, j'élargis les options de rsync afin de ACLs, xattrs et hardlinks à emporter avec soi. Sur Linux, -aAXH et -numeric-ids ont fait leurs preuves. J'exclue les pseudo-systèmes de fichiers tels que /proc, /sys, /run, /dev/pts et je sécurise les fichiers de démarrage et de configuration en les documentant séparément.
# Sauvegarde proche du système (exemple)
rsync -aAXH --numeric-ids \\
--exclude={"/proc/*","/sys/*","/run/*","/dev/pts/*","/tmp/*"} \
/ root@backup:/srv/backups/hostA/current/
# Restauration (simplifiée, à partir du support live)
rsync -aAXH --numeric-ids /srv/backups/hostA/current/ /mnt/target/
chroot /mnt/target update-initramfs -u
grub-install /dev/sda && update-grub
Je prévois plus de temps pour de telles restaurations, je documente l'ordre et je garde les étapes du bootloader à portée de main. Cela réduit considérablement le stress en cas d'urgence.
Intégration de Plesk : combiner intelligemment les jobs de panel
Je combine les tâches Plesk avec rsync pour que Sauvegardes du tableau de bord et les copies hors site se combinent. Les crochets post-sauvegarde transfèrent immédiatement les sauvegardes récentes vers un stockage externe. Les horaires correspondent aux fenêtres de maintenance afin que les déploiements et les sauvegardes n'interfèrent pas entre eux. La rotation des logs dans le tableau de bord et sur le système cible empêche la croissance des répertoires de logs. Une bonne aide pour commencer est fournie par Meilleures pratiques Plesk en se concentrant sur les processus répétables.
Intégration de cPanel : homedirs et bases de données
Je transfère ensuite les sauvegardes de cPanel sur un hôte externe via rsync, de sorte que Protection hors site sans charge supplémentaire. La structure des répertoires facilite les restaurations sélectives de comptes individuels. Pour les grandes configurations de revendeurs, je planifie des exécutions différentielles pendant la nuit et des états complets le week-end. En combinaison avec les quotas et les rotations, je garde les besoins de stockage transparents. Un complément pratique sont les indications sur Sauvegardes cPanel pour un fonctionnement quotidien solide.
Échelle et structure : gérer proprement de nombreuses tâches
Lorsque les environnements se développent, je structure les sources et les exclusions de manière centralisée. Avec -files-from je soumets des listes que je versionne dans le Repo. Cela me permet de modifier des phrases sans toucher aux scripts et de maintenir la cohérence des sites.
# Exemple de files-from
/etc/backup/www.list
/data/www/
/etc/nginx/
/var/www/html/
rsync -a --delete --files-from=/etc/backup/www.list / backup@host:/srv/backups/www/
J'évite les chevauchements en séparant clairement les responsabilités de chemin (par exemple, Webroot séparé des logs). Pour les grands ensembles, je planifie consciemment le parallélisme - je préfère un petit nombre de tâches bien synchronisées plutôt que des douzaines de processus concurrents.
Robustesse en fonctionnement : verrouillage, retraits, timeouts
Pour éviter les chevauchements, j'utilise flock ou des fichiers de verrouillage. J'intercepte les problèmes de réseau avec Retries et -partial. Avec -timeout, je termine proprement les connexions suspendues et je donne l'alerte.
# /usr/local/bin/rsync-backup.sh (extrait)
#!/usr/bin/env bash
set -euo pipefail
exec 9> /var/lock/rsync-backup.lock
flock -n 9 || { echo "Sauvegarde déjà en cours" ; exit 1 ; }
LOG=/var/log/rsync-backup.log
SRC=/data/www/
DST=backup@backuphost:/srv/backups/www/
for i in {1..3} ; do
if rsync -a --delete --partial --timeout=600 -e "ssh -i /root/.ssh/backup_key" "$SRC" "$DST" ; then
echo "OK" ; exit 0
fi
echo "Retry $i" | tee -a "$LOG"
sleep 60
done
echo "Erreur après retries" >> "$LOG" ; exit 1
Options pour les cas spéciaux : ACLs, xattrs, sparse et atomicité
J'adapte rsync en fonction du type de données. Pour les chemins d'accès web et système, je sauvegarde ACLs et xattrs avec -A -X. Les fichiers volumineux et peu utilisés (images de VM, bases de données) bénéficient de l'option -sparse. Avec -delay-updates et -delete-delay je minimise les états intermédiaires et j'obtiens des mises à jour quasi-atomiques sur la cible. Pour les données délicates, j'évite d'utiliser -inplace pour que les transferts défectueux n'écrasent pas la dernière bonne copie.
# Exemple de métadonnées étendues
rsync -aAXH --sparse --delete-delay --delay-updates SRC/ DST/
Si j'ai besoin de répertoires absolument atomiques (par exemple pour le staging), je synchronise dans une cible temporaire et cours puis le déplacer par mv vers le répertoire live.
Limites d'effacement sûres et contrôles de plausibilité
Pour éviter les catastrophes dues à une mauvaise configuration, je mets -max-delete que Guardrail. Je vérifie également les montages, la mémoire libre et les inodes avant l'exécution. Je fais consigner la dernière sauvegarde réussie et j'avertis en cas de dérives (taux de suppression ou de modification extrêmes).
# Protection contre l'effacement en masse
rsync -a --delete --max-delete=5000 SRC/ DST/
# Contrôle de plausibilité (simple)
df -h /srv/backups
df -i /srv/backups
En bref, je résume : Voici comment je procède
Je définis d'abord le RPO/RTO, parce que des Priorités guider chaque choix technique. Ensuite, j'écris un script léger, je le teste avec -dry-run et j'enregistre chaque exécution. Avec des clés SSH, une limite de bande passante et un versionnement, je sécurise de manière efficace et compréhensible. Les destinations hors site complètent les copies locales et les exercices de restauration réguliers confirment l'adéquation. Ainsi, ma sauvegarde rsync reste fiable, rapide et toujours prête à l'emploi.
