Rsync vs S3 sync : stratégie backup pour petits budgets

On va être honnête deux secondes.
Quand on parle backup, la plupart des gens pensent à un disque dur externe, un dossier « sauvegarde_finale_v7 », et un jour, bim, le disque fait un bruit bizarre.

Sauf que si tu gères un petit VPS, un NAS maison, un site WordPress, des projets clients, ou même juste tes dossiers de boulot… tu as besoin d’un truc un peu plus carré. Mais pas forcément d’un truc cher.

Et c’est là que la question arrive, souvent très concrète :

Tu fais du rsync vers un autre serveur, simple et efficace… ou tu fais une sync vers un stockage objet type S3 (AWS S3, Backblaze B2 S3, Wasabi, Scaleway Object Storage, etc.) ?

Je vais comparer les deux de façon pratique, en mode « petit budget », avec des choix réalistes et des pièges à éviter. Et oui, on peut faire un truc propre sans claquer 200 euros par mois.

Le vrai besoin : ce que tu veux vraiment protéger

Avant de parler outils, pose ça à plat. Parce que rsync et S3 ne répondent pas exactement aux mêmes menaces.

En général tu veux couvrir :

• panne disque (classique)
• erreur humaine (rm -rf, mauvaise manip)
• piratage (ransomware, compte compromis)
• bug applicatif (WordPress plugin qui casse tout)
• sinistre (machine volée, incendie, dégât des eaux… oui même pour un petit setup)

Et tu veux aussi :

• pouvoir restaurer vite
• garder de l’historique (versions)
• ne pas exploser ton budget
• automatiser, sinon tu vas oublier

Si tu lis souvent Le Blog Tech Pro de Samyn-Antoy ABASSE sur https://monblog-sa-abasse.blogspot.com, tu sais que j’aime bien l’approche « build, scale, sell ». Le backup c’est exactement ça. Tu build un système simple, tu le scales quand tu grandis, et tu évites de tout perdre avant de vendre ou livrer.

Rsync : le bon vieux couteau suisse

Rsync, c’est un peu le réflexe Linux. Et pour de bonnes raisons.

Ce que rsync fait très bien

• copie incrémentale efficace (delta)
• facile à scripter
• marche partout
• ultra rapide sur réseau local ou VPS vers VPS
• pas besoin de réinventer la roue

Typiquement :

bash rsync -avz --delete /var/www/ backup@serveur-backup:/data/backups/www/

Tu peux aussi faire plus propre avec exclusions :

bash rsync -avz --delete
--exclude='cache/'
--exclude='tmp/'
/home/samyn/ backup@serveur-backup:/data/backups/home/

Là où rsync commence à montrer ses limites

Rsync tout seul, ce n’est pas un système de sauvegarde complet. C’est une synchronisation.

Deux gros risques :

1. si tu supprimes localement, tu supprimes aussi côté backup (avec --delete)
2. si tu te fais chiffrer par un ransomware, rsync va gentiment synchroniser les fichiers chiffrés vers ton serveur backup

Donc rsync c’est top… mais il faut lui ajouter une notion d’historique, ou au minimum une stratégie d’instantanés.

Option petit budget qui change tout : rsync + snapshots

Le combo classique :

• rsync pousse les données
• le serveur de backup fait des snapshots (ZFS, btrfs, LVM, ou même hardlinks type rsnapshot)

Exemple avec rsnapshot (simple, vieux mais efficace). Tu obtiens des dossiers du style :

• daily.0
• daily.1
• weekly.0

Et tu peux restaurer un fichier supprimé hier sans pleurer.

S3 sync : stockage objet, autre philosophie

Quand on dit « S3 », on parle souvent du protocole et du modèle objet, pas forcément d’AWS.
Et la philosophie est différente : tu envoies des objets dans un bucket, avec une couche de durabilité très élevée, et des options comme le versioning, la rétention, le chiffrement, etc.

Ce que S3 fait très bien

• durabilité énorme (selon le provider)
• stockage hors de ton infra (donc meilleur contre sinistre local)
• versioning possible
• lifecycle policies (archivage, suppression auto)
• accès simple depuis n’importe où

Pour synchroniser, tu peux utiliser :

• aws cli (même avec un provider S3 compatible)
• rclone
• s3cmd

Exemple avec aws cli :

bash aws s3 sync /data/ s3://mon-bucket-backup/data/ --delete

Exemple avec rclone (souvent plus agréable) :

bash rclone sync /data remoteS3:mon-bucket-backup/data --progress

Le point que beaucoup ratent : la facture

S3 peut être pas cher… ou surprenant.

Tu payes potentiellement :

• le stockage (Go/mois)
• les requêtes (PUT, GET, LIST)
• l’egress (sortie de données) chez certains providers
• parfois des frais minimums

Donc pour « petits budgets », S3 est génial si :

• tu compresses avant d’envoyer
• tu évites de faire 10 millions de petits fichiers
• tu utilises un outil qui limite les listes inutiles
• tu actives une politique de cycle de vie

Sur un WordPress avec 200 000 mini fichiers dans uploads, ça peut piquer côté requêtes selon le fournisseur.

Comparaison directe : rsync vs S3 sync (sans blabla)

1) Coût

Rsync

• coût du serveur de backup (un petit VPS, un mini PC, un NAS)
• coût du disque
• coût du trafic réseau (souvent inclus)

S3 sync

• paiement à l’usage
• souvent imbattable pour stocker beaucoup sur la durée
• mais attention aux requêtes et à l’egress

Petit budget typique :

• si tu as déjà deux machines ou un NAS, rsync est presque gratuit
• si tu veux de l’offsite sans gérer un serveur, S3 est souvent plus simple

2) Résilience (sinistre, incendie, vol)

Rsync : dépend de où est ton serveur backup. Si c’est dans le même rack, même appartement, même bureau… ce n’est pas vraiment offsite.
S3 : offsite par défaut, donc meilleur sur ce point.

3) Historique et versions

Rsync : à construire (snapshots, rsnapshot, borg, restic, etc.)
S3 : versioning du bucket possible, très simple à activer, mais ça augmente le stockage

4) Restauration

Rsync : restauration très rapide si le serveur backup est proche, et tu récupères un système de fichiers normal.
S3 : plus lent si tu dois rapatrier beaucoup, et tu es dépendant du réseau. Mais tu peux restaurer depuis n’importe où.

5) Sécurité et ransomware

Les deux peuvent être bons, mais il faut configurer.

• rsync vers un serveur accessible en SSH : si ton serveur principal est compromis, l’attaquant peut tenter d’accéder au serveur backup
• S3 avec des clés d’accès : si les clés sont sur la machine compromise, pareil, danger

Ce qui aide beaucoup :

• accès en écriture limité
• stockage immuable (object lock) si dispo
• backups chiffrés côté client (restic, borg, duplicity)

Le vrai match : synchronisation simple vs backup réel

Une phrase à garder en tête :

« sync n’est pas backup ».

Rsync et S3 sync sont des sync.
Tu veux un backup. Donc tu veux au moins une de ces protections :

• historique de versions
• snapshots
• rétention
• immutabilité
• chiffrement
• tests de restauration

Donc en pratique, le débat devient :

• rsync + snapshots vs S3 + versioning
  ou
• mieux, un outil de backup (restic/borg) vers disque ou S3

Mais bon. On reste sur le sujet, et on garde l’angle « petits budgets ».

Stratégies concrètes, petit budget, qui marchent vraiment

Stratégie 1 : rsync vers un second serveur + snapshots (le classique robuste)

Bon pour :

• VPS, petits serveurs Linux
• infra que tu contrôles
• restauration rapide

Setup :

• Machine A : production
• Machine B : backup (idéalement autre datacenter, ou au moins autre lieu)
• rsync en push ou pull
• snapshots journaliers + hebdo

Points d’attention :

• sur le serveur backup, mets des permissions strictes
• idéalement, fais du pull (le serveur backup vient récupérer)
  comme ça, la machine de prod n’a pas de credentials d’écriture vers le backup

Exemple pull (sur serveur backup) :

bash rsync -avz --delete
prod@ip-prod:/var/www/ /data/backups/prod/www/

Stratégie 2 : S3 sync + versioning + lifecycle (offsite facile)

Bon pour :

• données froides (archives, exports)
• backups compressés (tar.gz, zst)
• offsite simple

Setup :

• tu fabriques un fichier backup (ex : tar + dump SQL)
• tu l’envoies dans S3
• tu actives versioning
• tu mets une règle de cycle de vie : suppression des anciennes versions au bout de X jours

Exemple WordPress simple :

bash tar -I 'zstd -3' -cf wp-content.tar.zst /var/www/wp-content mysqldump -u root -p dbname | zstd -3 > db.sql.zst

Puis upload :

bash aws s3 cp wp-content.tar.zst s3://bucket/wp/$(date +%F)/wp-content.tar.zst aws s3 cp db.sql.zst s3://bucket/wp/$(date +%F)/db.sql.zst

Tu limites le nombre de fichiers, donc moins de requêtes, et tu simplifies les restores.

Stratégie 3 : hybride (souvent le meilleur plan)

Honnêtement, c’est celle que je recommande le plus souvent.

• rsync local ou proche : restauration rapide
• S3 offsite : assurance catastrophe

Tu fais par exemple :

• tous les jours : rsync vers serveur backup proche + snapshots
• toutes les semaines : export compressé vers S3

Ça reste petit budget, et tu dors mieux.

Et si on veut rester simple, mais pas naïf

Voilà une approche « minimaliste mais correcte » :

Pour un VPS unique

• un second VPS à 5 euros ou 6 euros par mois avec gros disque
• rsync en pull
• snapshots (rsnapshot ou ZFS si tu sais faire)

En plus, une fois par semaine :

• tar.zst + dump SQL
• upload vers un bucket S3 compatible pas cher (Backblaze B2 S3, Wasabi, Scaleway… à comparer selon ta région et tes besoins)

Pour un laptop + un NAS maison

• rsync vers NAS en local (rapide)
• puis NAS vers S3 (offsite)

Ou même, plus simple :

• laptop vers S3 pour les dossiers critiques uniquement (documents, projets)

Quelques pièges classiques (et oui, je les ai déjà vus)

« Je fais rsync avec --delete donc c’est clean »

C’est clean, mais dangereux si tu n’as pas d’historique.
Un dossier supprimé par erreur et c’est terminé.

« J’ai un bucket S3 donc c’est bon »

Non, si tu n’as pas :

• versioning
• ou au minimum une rétention

Sinon un script buggé peut tout effacer. Ou des clés compromises aussi.

« Je chiffre côté serveur »

Ça ne suffit pas toujours.
Le chiffrement côté provider protège contre certains scénarios, mais pas contre un compte compromis. Le chiffrement côté client, lui, garde une barrière.

« Je n’ai jamais testé la restauration »

Le backup non testé, c’est juste une collection de fichiers que tu espères utiles un jour.
Il faut restaurer pour de vrai, même une fois par mois. Même vite.

Tableau récapitulatif (simple)

Critère	rsync	S3 sync
Coût initial	faible à moyen (serveur + disque)	faible (pay as you go)
Offsite	pas garanti	oui
Versioning	à ajouter	intégré via versioning
Restauration rapide	excellente	variable
Complexité	faible	faible à moyenne (politiques, coûts)
Risque sync destructive	oui	oui, mais versioning aide

Ma recommandation « petits budgets » (pratique, sans dogme)

Si tu n’as pas d’offsite aujourd’hui, fais simple :

1. un backup rsync + snapshots (local ou second serveur)
2. un export compressé hebdo vers S3 (ou S3 compatible)

Ça te donne :

• vitesse de restore
• historique
• offsite
• coût raisonnable

Et si tu veux aller plus loin, à ce moment-là tu peux basculer sur restic ou borg, parce que là tu passes de « sync » à « vrai backup outillé ».

Je publierai probablement un guide plus pas à pas (scripts + cron + rétention) sur Le Blog Tech Pro de Samyn-Antoy ABASSE sur https://monblog-sa-abasse.blogspot.com, donc si tu suis le blog pour la partie Linux, admin et productivité, garde ça dans tes onglets. C’est typiquement le genre de sujet où un template prêt à l’emploi fait gagner une soirée.

Conclusion : rsync ou S3, le bon choix dépend de ce que tu refuses de perdre

Rsync, c’est le bon outil quand tu veux du rapide, du simple, du contrôle.
S3 sync, c’est le bon outil quand tu veux de l’offsite, de la durabilité, et moins de gestion infra.

Mais la vraie réponse pour un petit budget, c’est souvent un mix.
Un système qui pardonne tes erreurs. Parce que tu vas en faire, moi aussi. On en fait tous.

Et si tu dois retenir une seule règle :
fais un backup que tu peux restaurer en 30 minutes, un soir de stress. Pas un backup « parfait » que tu ne comprends plus dans 6 mois.

Questions fréquemment posées

Quelles sont les principales menaces que doit couvrir une bonne stratégie de sauvegarde ?

Une stratégie de sauvegarde efficace doit protéger contre plusieurs risques : panne disque, erreur humaine (comme une suppression accidentelle), piratage (ransomware ou compte compromis), bug applicatif (par exemple un plugin WordPress qui casse tout) et sinistre (vol, incendie, dégât des eaux).

Pourquoi rsync est-il souvent choisi pour les sauvegardes sur des petits serveurs ou VPS ?

Rsync est très populaire car c'est un outil Linux fiable, rapide et facile à scripter. Il réalise des copies incrémentales efficaces, fonctionne partout et est ultra rapide sur réseau local ou entre VPS. C'est un 'couteau suisse' pratique pour synchroniser ses données simplement.

Quels sont les risques d'utiliser rsync seul pour la sauvegarde ?

Rsync seul n’est pas un système de sauvegarde complet mais une synchronisation. Si vous supprimez un fichier localement avec l’option --delete, il sera aussi supprimé dans la sauvegarde. De plus, en cas de ransomware, rsync peut synchroniser les fichiers chiffrés vers le serveur backup, rendant la restauration impossible.

Comment améliorer rsync pour en faire une solution de sauvegarde fiable et économique ?

La solution petit budget consiste à combiner rsync avec des snapshots sur le serveur de backup (via ZFS, btrfs, LVM ou outils comme rsnapshot). Cela permet de conserver des versions historiques (daily.0, daily.1...) et de restaurer facilement des fichiers supprimés ou corrompus sans exploser le budget.

Quelles sont les avantages du stockage objet type S3 par rapport à rsync ?

Le stockage objet S3 offre une durabilité très élevée grâce à la redondance multi-régions, protège mieux contre les sinistres locaux en étant hors de votre infrastructure, propose le versioning natif, des politiques automatisées de cycle de vie (archivage, suppression), ainsi qu’un accès simple depuis n’importe où via Internet.

Comment choisir entre une sauvegarde rsync + snapshots et une solution S3 sync ?

Le choix dépend du besoin réel : si vous avez un petit budget et souhaitez une solution rapide à mettre en place avec contrôle total sur vos données locales, rsync + snapshots est idéal. Pour une protection renforcée contre sinistres majeurs, historique automatique et accessibilité globale sans gérer d’infra physique, le stockage objet S3 est préférable.