[{"data":1,"prerenderedAt":178},["ShallowReactive",2],{"seo-verification":3,"blog-backup-vps-restic-s3-3-2-1-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-backup-vps-restic-s3-3-2-1-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"category":21,"categories":27,"featuredImage":29,"bgImage":30,"posterImage":31,"relatedSolution":29,"intro":32,"sections":33,"ctaTitle":122,"ctaBody":123,"ctaButton":124,"ctaUrl":125,"relatedPosts":126},347,"backup-vps-restic-s3-3-2-1",{"fr":10,"en":12,"ar":13,"es":14},"restic-s3-3-2-1-backup-strategy-vps","restic-s3-3-2-1-backup-strategy-vps-ar","estrategia-3-2-1-backup-vps-restic-s3","Stratégie 3-2-1 pour votre VPS avec Restic et S3","Construisez une stratégie 3-2-1 complète sur votre VPS : Restic vers Backblaze B2 ou Cloudflare R2, timer systemd, rétention et test de restauration automatisé.",11,0,false,"2026-09-10T00:00:00+00:00",{"id":22,"name":23,"slug":24,"color":25,"icon":26},8,"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[28],{"id":22,"name":23,"slug":24,"color":25,"icon":26},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fbackup-vps-restic-s3-3-2-1-poster.svg","Activer les snapshots de votre hébergeur ne constitue pas une stratégie 3-2-1 : c'est une seule copie, sur un seul support, chez un seul fournisseur. Si la VM disparaît, votre compte est compromis, ou le datacenter subit un incident, vos données partent avec. La règle 3-2-1 répond à ce risque : trois copies, sur deux supports distincts, dont une hors du fournisseur et chiffrée avant de quitter le serveur. Ce guide couvre la mise en œuvre complète avec Restic, un timer systemd, une politique de rétention calibrée et un test de restauration automatisé qui échoue si la sauvegarde est corrompue.",[34,38,49,52,84,112,116,119],{"type":35,"title":36,"body":37},"h2","Pourquoi les snapshots hébergeur ne suffisent pas : trois limites concrètes","Un snapshot hébergeur est pratique, mais il partage le même plan de défaillance que votre VM. Première limite : si la VM est supprimée — par erreur, par votre fournisseur, ou suite à un impayé — les snapshots associés disparaissent avec elle. Deuxième limite : si un attaquant compromet votre compte hébergeur, il peut supprimer snapshots et VM en quelques secondes via l'API ou le tableau de bord. Troisième limite : les snapshots de datacenter ne testent jamais la restauration. Un snapshot « cohérent » peut contenir un système de fichiers corrompu ou une base de données dans un état incohérent ; vous ne le saurez qu'au moment où vous en aurez besoin.",{"type":39,"title":40,"items":41},"ul","Ce qu'une stratégie 3-2-1 garantit, et ce qu'un snapshot ne garantit pas",[42,43,44,45,46,47,48],"**Trois copies** : l'originale sur disque local, une sur les snapshots hébergeur, une hors du fournisseur sur S3 — aucun point de défaillance unique ne peut tout effacer.","**Deux supports distincts** : le disque NVMe de votre VPS et le stockage objet d'un autre fournisseur sont physiquement et logiquement séparés.","**Chiffrement avant le transfert** : Restic chiffre côté client avec AES-256 ; le fournisseur de stockage S3 ne voit que des blobs opaques, illisibles sans votre clé.","**Test de restauration** : une sauvegarde non testée est une promesse, pas une garantie. Un timer systemd peut vérifier automatiquement qu'un fichier sentinelle est restaurable.","**Indépendance du fournisseur** : votre bucket B2 ou R2 n'est pas effaçable depuis le tableau de bord de votre hébergeur VPS.","Un snapshot hébergeur ne chiffre pas avant le transfert : les données sont lisibles par le fournisseur.","Un snapshot hébergeur ne vérifie jamais la cohérence applicative de vos bases de données.",{"type":35,"title":50,"body":51},"Les trois copies expliquées : locale, hébergeur, off-site","La règle 3-2-1 n'est pas une recette rigide — c'est un principe de diversification des risques.\n\n**Copie 1 — disque local de votre VPS.** C'est votre première ligne : l'originale, sur le disque NVMe. Elle sert les restaurations rapides d'un fichier effacé par erreur sans aucune latence réseau.\n\n**Copie 2 — snapshots hébergeur.** La sauvegarde automatique gérée par votre fournisseur VPS couvre les accidents de configuration et les suppressions accidentelles au niveau du système. C'est votre filet de sécurité sur site.\n\n**Copie 3 — stockage objet off-site, chiffré avec Restic.** C'est le maillon que la plupart des équipes oublient, et le seul qui résiste à la perte complète du compte hébergeur. Restic chiffre les données avant tout transfert, les déduplique pour minimiser les coûts et les envoie sur un bucket S3-compatible chez un fournisseur tiers. C'est cette troisième copie que ce guide construit.",{"type":53,"title":54,"headers":55,"rows":59},"comparison","Backblaze B2 vs Cloudflare R2 : choisir votre backend S3",[56,57,58],"Critère","Backblaze B2","Cloudflare R2",[60,64,68,72,76,80],[61,62,63],"Stockage","tarif public par Go, sans quota gratuit","Gratuit jusqu'à 10 Go\u002Fmois, puis tarif public par Go",[65,66,67],"Egress (sortie réseau)","Gratuit vers Cloudflare et certains partenaires CDN ; facturable hors partenaires","Gratuit sans limite — aucun coût de sortie",[69,70,71],"Compatibilité S3","API S3-compatible native ; endpoint `s3.us-west-004.backblazeb2.com`","API S3-compatible native ; endpoint `\u003Caccount>.r2.cloudflarestorage.com`",[73,74,75],"Variable `RESTIC_REPOSITORY`","`s3:https:\u002F\u002Fs3.us-west-004.backblazeb2.com\u002Fnom-du-bucket`","`s3:https:\u002F\u002F\u003Caccount>.r2.cloudflarestorage.com\u002Fnom-du-bucket`",[77,78,79],"Clés d'accès","Application Key B2 (Key ID + Application Key)","API Token R2 avec permissions Object Read & Write",[81,82,83],"Cas d'usage recommandé","Volume élevé avec egress limité ou depuis infrastructure Cloudflare","Egress fréquent ou tests de restauration réguliers depuis n'importe où",{"type":85,"title":86,"steps":87},"steps","Mise en œuvre complète : Restic + S3 sur votre VPS",[88,91,94,97,100,103,106,109],{"title":89,"body":90},"Exporter les variables d'environnement dans un fichier sécurisé","Créez `\u002Froot\u002F.restic-env` avec les variables nécessaires. Pour Backblaze B2 :\n\n```bash\nexport RESTIC_REPOSITORY=\"s3:https:\u002F\u002Fs3.us-west-004.backblazeb2.com\u002Fvotre-bucket\"\nexport RESTIC_PASSWORD=\"votre-mot-de-passe-depot\"\nexport AWS_ACCESS_KEY_ID=\"votre-b2-key-id\"\nexport AWS_SECRET_ACCESS_KEY=\"votre-b2-application-key\"\n```\n\nPour Cloudflare R2, remplacez l'URL du dépôt et les clés :\n\n```bash\nexport RESTIC_REPOSITORY=\"s3:https:\u002F\u002F\u003Caccount-id>.r2.cloudflarestorage.com\u002Fvotre-bucket\"\nexport RESTIC_PASSWORD=\"votre-mot-de-passe-depot\"\nexport AWS_ACCESS_KEY_ID=\"votre-r2-access-key-id\"\nexport AWS_SECRET_ACCESS_KEY=\"votre-r2-secret-access-key\"\n```\n\nRestreignez immédiatement les droits sur ce fichier : `chmod 600 \u002Froot\u002F.restic-env`. Ce fichier ne doit jamais être commité dans un dépôt Git ni inclus dans une sauvegarde accessible sans authentification.",{"title":92,"body":93},"Initialiser le dépôt Restic sur S3","Chargez l'environnement, puis initialisez le dépôt chiffré sur votre bucket :\n\n```bash\nsource \u002Froot\u002F.restic-env\nrestic init\n```\n\nRestic crée la structure du dépôt et scelle le chiffrement avec votre mot de passe. L'opération produit un identifiant de dépôt — notez-le. **Conservez le mot de passe du dépôt en dehors du VPS** : dans un gestionnaire de mots de passe, un coffre chiffré sur une machine distincte, ou un secret manager. Sans lui, aucune restauration n'est possible, même si vous disposez du bucket complet.",{"title":95,"body":96},"Lancer une première sauvegarde vers S3","Testez le chemin complet avec une sauvegarde manuelle :\n\n```bash\nsource \u002Froot\u002F.restic-env\nrestic backup \u002Fetc \u002Fvar\u002Fwww \u002Fopt\u002Fdocker-data\n```\n\nPour les bases de données, générez un dump avant la sauvegarde ou utilisez le mode stdin. Exemple pour PostgreSQL :\n\n```bash\npg_dump -U postgres mabase | restic backup --stdin --stdin-filename mabase.sql\n```\n\nVérifiez que le snapshot est bien créé : `restic snapshots`.",{"title":98,"body":99},"Définir la politique de rétention","La commande `forget` supprime les références aux anciens snapshots ; `--prune` libère physiquement les blocs orphelins dans le backend :\n\n```bash\nrestic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 3 --prune\n```\n\n**Justification des valeurs.** Sept quotidiens couvrent une semaine entière — suffisant pour détecter une corruption silencieuse qui n'apparaît que quelques jours après l'incident. Quatre hebdomadaires offrent une fenêtre d'un mois pour détecter un problème applicatif lent (données manquantes progressivement). Trois mensuels permettent une restauration à un état antérieur au trimestre — utile après une migration de base de données ratée. `--prune` est indispensable : sans lui, `forget` marque les snapshots pour suppression mais ne libère pas l'espace dans le bucket, et la facture de stockage continue de croître.",{"title":101,"body":102},"Distinguer restic check et restic check --read-data","Ces deux commandes ne vérifient pas la même chose.\n\n`restic check` valide les **métadonnées du dépôt** — structure des packs, cohérence des index, intégrité des pointeurs. Rapide (quelques secondes à quelques minutes selon la taille du dépôt). À lancer après chaque `forget --prune`.\n\n```bash\nrestic check\n```\n\n`restic check --read-data` télécharge et vérifie **chaque blob de données** en les comparant à leur hash cryptographique. Lent (proportionnel au volume du dépôt) et coûteux en egress si votre fournisseur facture les sorties. À réserver à une vérification mensuelle ou après un doute sur l'intégrité du bucket.\n\n```bash\nrestic check --read-data\n```\n\nUne vérification hebdomadaire des métadonnées suffit pour détecter les corruptions courantes sans surcoût de transfert.",{"title":104,"body":105},"Créer l'unité systemd de sauvegarde (.service)","Créez `\u002Fetc\u002Fsystemd\u002Fsystem\u002Frestic-backup.service` :\n\n```bash\n[Unit]\nDescription=Restic backup vers S3\nAfter=network-online.target\nWants=network-online.target\n\n[Service]\nType=oneshot\nEnvironmentFile=\u002Froot\u002F.restic-env\nExecStartPre=\u002Fbin\u002Fsh -c 'curl -sf --max-time 10 https:\u002F\u002Fone.one.one.one > \u002Fdev\u002Fnull || exit 1'\nExecStart=\u002Fusr\u002Fbin\u002Frestic backup \u002Fetc \u002Fvar\u002Fwww \u002Fopt\u002Fdocker-data\nExecStartPost=\u002Fusr\u002Fbin\u002Frestic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 3 --prune\nExecStartPost=\u002Fusr\u002Fbin\u002Frestic check\nStandardOutput=journal\nStandardError=journal\n```\n\n`ExecStartPre` vérifie la connectivité réseau avant de tenter le backup — si le VPS est isolé ou si le bucket est inaccessible, le service échoue proprement avec un statut exploitable plutôt que de pendre ou d'écrire dans les logs une erreur silencieuse. `EnvironmentFile` charge `\u002Froot\u002F.restic-env` sans exposer les clés dans la définition de l'unité.",{"title":107,"body":108},"Créer l'unité systemd de planification (.timer)","Créez `\u002Fetc\u002Fsystemd\u002Fsystem\u002Frestic-backup.timer` :\n\n```bash\n[Unit]\nDescription=Timer quotidien pour restic-backup.service\n\n[Timer]\nOnCalendar=*-*-* 03:00:00\nPersistent=true\nRandomizedDelaySec=900\n\n[Install]\nWantedBy=timers.target\n```\n\n`Persistent=true` garantit que si le VPS est éteint à 03h00, le backup s'exécutera au prochain démarrage. `RandomizedDelaySec=900` étale le déclenchement sur une fenêtre de quinze minutes — évite les pics de charge si vous avez plusieurs serveurs avec le même timer. Activez et démarrez :\n\n```bash\nsystemctl daemon-reload\nsystemctl enable --now restic-backup.timer\n```\n\nVérifiez l'état du timer : `systemctl status restic-backup.timer` et les logs du dernier run : `journalctl -u restic-backup.service`.",{"title":110,"body":111},"Créer un test de restauration automatisé avec fichier sentinelle","Un backup dont la restauration n'a jamais été testée ne prouve rien. Créez un fichier sentinelle dans votre sauvegarde, puis un service systemd qui restaure et vérifie ce fichier.\n\nPremièrement, créez le fichier sentinelle et incluez-le dans votre sauvegarde :\n\n```bash\necho \"sentinel-$(date +%s)\" > \u002Fopt\u002Frestic-sentinel.txt\n```\n\nAssurez-vous que `\u002Fopt` est inclus dans votre commande `restic backup`.\n\nEnsuite, créez `\u002Fetc\u002Fsystemd\u002Fsystem\u002Frestic-restore-test.service` :\n\n```bash\n[Unit]\nDescription=Test de restauration Restic\nAfter=network-online.target\n\n[Service]\nType=oneshot\nEnvironmentFile=\u002Froot\u002F.restic-env\nExecStart=\u002Fbin\u002Fsh -c '\n  rm -rf \u002Ftmp\u002Frestic-test-restore && \\\n  restic restore latest --target \u002Ftmp\u002Frestic-test-restore && \\\n  test -f \u002Ftmp\u002Frestic-test-restore\u002Fopt\u002Frestic-sentinel.txt && \\\n  echo \"Restauration OK : $(cat \u002Ftmp\u002Frestic-test-restore\u002Fopt\u002Frestic-sentinel.txt)\" || \\\n  (echo \"ECHEC restauration sentinelle\" && exit 1)\n'\nStandardOutput=journal\nStandardError=journal\n```\n\nCréez le timer hebdomadaire `\u002Fetc\u002Fsystemd\u002Fsystem\u002Frestic-restore-test.timer` :\n\n```bash\n[Unit]\nDescription=Test hebdomadaire de restauration Restic\n\n[Timer]\nOnCalendar=Sun 04:00:00\nPersistent=true\n\n[Install]\nWantedBy=timers.target\n```\n\nActivez : `systemctl enable --now restic-restore-test.timer`. Le dimanche à 04h00, le service restaure le dernier snapshot et échoue avec exit 1 si le fichier sentinelle est absent — ce qui produit un log exploitable et un statut failed visible dans `systemctl status`.",{"type":113,"title":114,"body":115},"tip","Secrets Restic : fichier .env isolé, jamais en dur dans le service","Ne placez jamais `RESTIC_PASSWORD`, `AWS_ACCESS_KEY_ID` ou `AWS_SECRET_ACCESS_KEY` directement dans la définition d'une unité systemd, dans un script versionné ou dans un Dockerfile. Le fichier `\u002Froot\u002F.restic-env` avec `chmod 600` est la bonne pratique : il est chargé par `EnvironmentFile=` sans jamais apparaître dans `systemctl show` ni dans les logs. Ajoutez `\u002Froot\u002F.restic-env` à votre `.gitignore` ou `.dockerignore` si votre répertoire `\u002Froot` est versionné. Pour un environnement multi-utilisateurs, préférez un secret manager ou les secrets systemd (`LoadCredential=`) plutôt qu'un fichier plat.",{"type":35,"title":117,"body":118},"Dépannage : quatre erreurs courantes","**`Fatal: unable to open config file` au `restic init` ou au premier `restic backup`.** Cette erreur indique que Restic ne peut pas accéder au bucket. Vérifiez d'abord que les variables sont bien chargées (`echo $RESTIC_REPOSITORY`) et que les identifiants sont corrects. Ensuite, vérifiez les permissions IAM de votre clé B2 ou R2 : elle doit disposer au minimum des droits de lecture, écriture et liste sur le bucket. Sur B2, une Application Key restreinte à un bucket spécifique doit explicitement inclure `listBuckets` pour que Restic puisse vérifier son existence. Sur R2, le token doit avoir les permissions `Object Read` et `Object Write` sur le bucket cible.\n\n**Bucket S3 : permissions insuffisantes.** Si `restic init` réussit mais que `restic backup` échoue avec une erreur d'autorisation, c'est souvent une politique de bucket qui surcharge les permissions de la clé. Sur B2, vérifiez qu'aucune règle de bucket `denyUpload` n'est active. Sur R2, vérifiez que le bucket n'est pas en mode public avec restrictions en écriture.\n\n**Timer systemd qui ne se déclenche pas.** Diagnostiquez en trois commandes : `systemctl status restic-backup.timer` (état actif ou inactif), `systemctl list-timers --all | grep restic` (prochaine exécution planifiée), `journalctl -u restic-backup.service --since today` (logs du dernier run). Si le timer est actif mais le service n'a pas tourné, vérifiez que `OnCalendar` est syntaxiquement valide : `systemd-analyze calendar '*-*-* 03:00:00'` doit renvover une date de prochain déclenchement.\n\n**`restic check --read-data` trop lent.** Sur un dépôt de plusieurs dizaines de Go, `--read-data` peut prendre plusieurs heures et générer des coûts d'egress significatifs sur B2. Utilisez `--read-data-subset=10%` pour vérifier un échantillon aléatoire à chaque run hebdomadaire, et réservez la vérification complète à une maintenance mensuelle planifiée hors des heures de pointe.",{"type":35,"title":120,"body":121},"Plan de reprise : combien de temps pour restaurer depuis B2 ou R2 ?","La durée de restauration dépend de trois facteurs : le volume de données, la bande passante disponible entre votre VPS et le bucket, et les éventuels coûts d'egress.\n\nPour estimer : un dépôt Restic de 20 Go sur B2 (données déjà dédupliquées et compressées) se restaure en environ 15 à 30 minutes avec une connexion de datacenter standard à 1 Gbps. Sur R2, l'egress est gratuit — vous n'avez pas de pression financière à étaler la restauration. Sur B2, si votre VPS est hors du réseau partenaire Backblaze, les premiers Go sont gratuits puis facturés ; une restauration complète d'un gros dépôt peut engendrer des coûts non nuls.\n\nDeux pratiques réduisent le temps de reprise : d'abord, maintenir une liste de vos répertoires critiques séparée de vos répertoires de cache ou de logs (ne sauvegardez pas `\u002Ftmp`, `\u002Fproc`, les volumes Docker inutilisés) — un dépôt plus petit se restaure plus vite. Ensuite, tester régulièrement la restauration partielle d'un seul répertoire (`restic restore latest --target \u002Ftmp\u002Ftest --include \u002Fetc`) pour calibrer le temps réel sur votre infrastructure, plutôt que de découvrir la durée le jour d'un incident. La commande `restic stats` donne la taille du dépôt et permet de planifier.","Un VPS conçu pour les stratégies de sauvegarde sérieuses","Accès root, stockage local, snapshots automatiques et bande passante sortante incluse : un VPS ServOrbit est le point de départ de toute stratégie 3-2-1.","Obtenir un VPS avec accès root","\u002Fvps-cloud",[127,142,157],{"id":128,"slug":129,"slugs":130,"title":134,"excerpt":135,"readTime":136,"views":18,"isPinned":19,"publishedAt":137,"category":138,"categories":139,"featuredImage":29,"bgImage":30,"posterImage":141,"relatedSolution":29},113,"sauvegardes-restic-vps",{"fr":129,"en":131,"ar":132,"es":133},"automate-your-vps-backups-with-restic","أتمتة-نسخ-خادمك-vps-الاحتياطية-باستخدام-restic","copias-de-seguridad-vps-con-restic","Automatiser les sauvegardes de votre VPS avec Restic","Automatisez les sauvegardes de votre VPS avec Restic : snapshots chiffrés, déduplication et envoi vers S3 ou tout backend objet.",3,"2026-02-27T00:00:00+00:00",{"id":22,"name":23,"slug":24,"color":25,"icon":26},[140],{"id":22,"name":23,"slug":24,"color":25,"icon":26},"\u002Fblog\u002Fcovers\u002Fsauvegardes-restic-vps-poster.svg",{"id":143,"slug":144,"slugs":145,"title":149,"excerpt":150,"readTime":151,"views":18,"isPinned":19,"publishedAt":152,"category":153,"categories":154,"featuredImage":29,"bgImage":30,"posterImage":156,"relatedSolution":29},114,"backups-borgbackup-vps",{"fr":144,"en":146,"ar":147,"es":148},"encrypted-vps-backups-with-borgbackup","نسخ-خادم-vps-الاحتياطية-المشفرة-باستخدام-borgbackup","copias-de-seguridad-vps-con-borgbackup","Sauvegardes chiffrées de VPS avec BorgBackup","Sauvegardez votre VPS avec BorgBackup : déduplication puissante, chiffrement authentifié et compression. Guide complet et comparatif Restic.",4,"2026-02-26T00:00:00+00:00",{"id":22,"name":23,"slug":24,"color":25,"icon":26},[155],{"id":22,"name":23,"slug":24,"color":25,"icon":26},"\u002Fblog\u002Fcovers\u002Fbackups-borgbackup-vps-poster.svg",{"id":158,"slug":159,"slugs":160,"title":164,"excerpt":165,"readTime":166,"views":167,"isPinned":19,"publishedAt":168,"category":169,"categories":175,"featuredImage":29,"bgImage":30,"posterImage":177,"relatedSolution":29},126,"sauvegardes-serveur-jetbackup",{"fr":159,"en":161,"ar":162,"es":163},"server-backups-jetbackup-explained","نسخ-الخوادم-الاحتياطية-شرح-jetbackup","copias-seguridad-servidor-jetbackup","JetBackup sur cPanel\u002FWHM : installation et restauration","Comment installer JetBackup sur WHM, configurer des destinations S3 ou SFTP, planifier les sauvegardes et restaurer un compte, une base ou un e-mail isolément.",9,1,"2026-02-18T00:00:00+00:00",{"id":170,"name":171,"slug":172,"color":173,"icon":174},7,"Self-hosting","self-hosting","bg-indigo-500\u002F10 text-indigo-400","cloud",[176],{"id":170,"name":171,"slug":172,"color":173,"icon":174},"\u002Fblog\u002Fcovers\u002Fsauvegardes-serveur-jetbackup-poster.svg",1789046101332]