Deux ans de photos de vacances, une thèse en cours, des projets perso accumulés depuis 2021. Tout ça, parti en fumée un dimanche matin à cause d’un rm -rf mal placé. Cette expérience traumatisante, que pas mal de linuxiens ont vécue au moins une fois, m’a poussé à creuser sérieusement la question des sauvegardes automatisées. Et la solution que j’aurais dû mettre en place depuis le début tient en un script bash et un outil qu’on sous-estime chroniquement : rsync couplé à cron.
À retenir
- Comment une simple erreur Linux peut effacer des années de données en secondes
- Un script bash minimaliste qui automatise vos sauvegardes sans effort quotidien
- Pourquoi les sauvegardes manuelles échouent et comment cron les rend invisibles mais fiables
Ce qui se passe dans ta tête juste après la catastrophe
Il y a un stade très particulier de panique froide quand tu réalises que le dossier a disparu. Tu relances ls trois fois comme si le terminal allait te mentir. Tu vérifies la corbeille, évidemment vide parce que t’as utilisé rm directement dans le terminal comme un grand. Puis vient l’étape des recherches frénétiques sur « récupérer fichiers supprimés Linux », avec les résultats qui varient entre « impossible » et « achète ce logiciel à 80€ ». La plupart du temps, sur un système ext4 moderne avec journalisation, les chances de récupération sans snapshot préalable sont proches de zéro.
Le vrai problème, c’est qu’on repousse tous la configuration des sauvegardes. C’est le truc chiant, invisible, qui « ne sert à rien » jusqu’au moment précis où ça sert à tout. Je me suis dit pendant des années que mes fichiers importants étaient sur plusieurs machines, que ça suffisait. Spoiler : ça ne suffit pas.
Le script qui change la donne
La beauté de la solution rsync + cron, c’est qu’elle tient en moins de 20 lignes et tourne en arrière-plan sans jamais te déranger. Rsync est installé par défaut sur à peu près toutes les distributions Linux, il fait des copies incrémentales (donc rapides après la première synchro), et il préserve les permissions, les liens symboliques, les timestamps. Bref, c’est une copie conforme, pas un vague duplicat.
Voici le script que j’utilise maintenant, que tu peux adapter à ta situation :
#!/bin/bash
# Script de sauvegarde rsync
DATE=$(date +%Y-%m-%d_%H-%M)
SOURCE="/home/tonuser/"
DEST="/media/disque-externe/backups/$DATE"
LOG="/var/log/backup_rsync.log"
rsync -av --delete \
--exclude='.cache/' \
--exclude='node_modules/' \
--exclude='.local/share/Trash/' \
"$SOURCE" "$DEST" >> "$LOG" 2>&1
echo "Backup terminé : $DATE" >> "$LOG"
Quelques explications sur les options : -a active le mode archive (conserve tout, récursif), -v rend le processus verbeux pour le log, et --delete supprime dans la destination les fichiers que tu as toi-même effacés à la source. Cette dernière option est à double tranchant selon le cas d‘usage, donc si tu préfères garder un historique complet, retire-la.
Les exclusions sont importantes. Le dossier .cache peut peser plusieurs gigaoctets d’inutilités, node_modules n’a jamais besoin d’être sauvegardé (il se régénère avec npm install), et la corbeille, autant ne pas l’archiver.
Automatiser avec cron : le vrai déclencheur
Un script qu’on lance manuellement, c’est un script qu’on oublie de lancer. La vraie puissance vient de l’automatisation via cron. Lance crontab -e dans ton terminal et ajoute cette ligne :
0 3 * * * /home/tonuser/scripts/backup.sh
Ça déclenche la sauvegarde tous les jours à 3h du matin, quand la machine tourne mais que toi tu dors. Si ton PC est éteint la nuit, adapte l’horaire à un moment où il est allumé : 12h30 pendant ta pause déjeuner, par exemple, ou à la connexion de ton disque externe via un trigger udev. Ce dernier point mériterait son propre article, mais en gros, udev permet d’exécuter automatiquement un script au branchement d’un périphérique USB.
Pour vérifier que tout fonctionne, rien de plus simple : cat /var/log/backup_rsync.log te donnera l’historique complet des sauvegardes avec horodatage. Un coup d’œil par semaine suffit pour dormir tranquille.
Aller plus loin : la règle 3-2-1 et pourquoi un seul disque externe ne suffit pas
La règle 3-2-1 est un classique de l’administration système : 3 copies de tes données, sur 2 supports différents, dont 1 hors site. Un disque externe chez toi, c’est la base. Mais si ta maison brûle ou si ton appartement est cambriolé (les voleurs prennent les disques durs aussi), tu perds tout de même. La complémentarité idéale associe un disque externe local et une solution cloud chiffrée.
Pour le cloud, rsync fonctionne parfaitement avec des serveurs distants via SSH. Si tu as un VPS ou un espace chez un hébergeur qui propose un accès SSH, la commande devient simplement :
rsync -avz -e ssh "$SOURCE" utilisateur@serveur.exemple.com:/backups/
Le -z active la compression à la volée, ce qui réduit la bande passante utilisée. Pour les fichiers vraiment sensibles, un outil comme Rclone combiné à un chiffrement côté client avant upload sur n’importe quel cloud grand public (Backblaze B2, un bucket S3, etc.) reste la meilleure approche.
Ce que cette mésaventure m’a appris au fond, c’est que la sécurité de ses données personnelles ressemble à une assurance : tu penses que tu en as besoin le moins du monde, jusqu’au sinistre. La différence avec une assurance, c’est qu’ici la prime, c’est une demi-heure de configuration une fois dans ta vie. La prochaine fois que je verrai quelqu’un se plaindre d’avoir perdu des fichiers, je lui enverrai ce script. Et je me demanderai combien de données dorment en ce moment sur des disques sans aucune sauvegarde, à quelques rm -rf du néant.