[{"data":1,"prerenderedAt":233},["ShallowReactive",2],{"seo-verification":3,"blog-tester-restauration-sauvegarde-vps-client-agence-procedure-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-tester-restauration-sauvegarde-vps-client-agence-procedure-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":183,"ctaBody":184,"ctaButton":185,"ctaUrl":186,"relatedPosts":187},523,"tester-restauration-sauvegarde-vps-client-agence-procedure",{"fr":10,"en":12,"ar":13,"es":14},"test-client-vps-backup-restore-agency-procedure","اختبار-استعادة-نسخة-احتياطية-vps-عميل-وكالة-إجراء","probar-restauracion-copia-seguridad-vps-cliente-agencia-procedimiento","Tester la restauration d'une sauvegarde client : procédure agence","Procédure trimestrielle pour restaurer un site client sur un VPS jetable, mesurer le RTO et le RPO constatés, puis remettre un journal de test daté au client.",11,0,false,"2026-10-28T00:00:00+00:00","2026-10-29T03:10:23+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Ftester-restauration-sauvegarde-vps-client-agence-procedure-poster.svg","Une sauvegarde qui existe n'est pas une sauvegarde qui se relit, et la différence se découvre un jour d'incident, devant le client. Ce guide s'adresse aux agences qui gèrent un portefeuille de sites et doivent pouvoir répondre à « prouvez que vous savez restaurer ». Il décrit un exercice complet, humain et trimestriel, sur un VPS de test jetable : restauration depuis le dépôt réel, chronomètre du RTO, calcul du RPO constaté, puis journal daté remis au client. Le contrôle automatique par fichier sentinelle est traité ailleurs ; ici, on produit la preuve.",[35,39,49,52,83,86,126,157,167,170,174,177,180],{"type":36,"title":37,"body":38},"h2","Ce test n'est pas le test automatique : ce qu'il ajoute","Le guide sur la stratégie 3-2-1 avec Restic et S3 décrit un contrôle automatique : un fichier sentinelle restauré chaque semaine, qui alerte quand la chaîne de sauvegarde casse. C'est utile et il faut le garder. Mais il répond à la question « le dépôt se lit-il ? », pas à « le site du client repart-il, et en combien de temps ? ». Restaurer un fichier de quelques octets ne dit rien d'une base de données, des fichiers téléversés, de la version de PHP attendue ou des secrets absents.\n\nL'exercice de ce guide restaure un site entier, à la main, sur une machine neuve, et en tire trois mesures : une durée, un âge des données et une liste d'anomalies. Les deux dispositifs ne se concurrencent pas. Le contrôle automatique détecte la panne chaque semaine ; l'exercice trimestriel prouve la reprise, avec une signature et une date. C'est cette preuve qu'un client, un appel d'offres ou un audit finit par demander.\n\nÀ ne pas confondre non plus avec le contrôle de restauration de la checklist d'audit mensuel d'un VPS client : celui-là vérifie chaque mois qu'un fichier ou une base se restaure ; l'exercice trimestriel de ce guide remet en route un site entier, chronomètre en main.",{"type":40,"title":41,"items":42},"ul","Ce que l'exercice prouve et que la sauvegarde seule ne prouve pas",[43,44,45,46,47,48],"**Le dépôt se lit sans le serveur d'origine** — la restauration part du dépôt distant, avec des secrets conservés ailleurs, jamais du disque du site.","**Le site redémarre vraiment** — la page d'accueil, la connexion à l'administration et le dernier contenu en base répondent sur la machine neuve.","**Le RTO est mesuré, pas supposé** — une durée constatée remplace l'estimation « à peu près une heure ».","**Le RPO tient sa promesse** — l'écart entre l'incident simulé et le snapshot restauré se compare à ce que le contrat annonce.","**Les accès sont entre les bonnes mains** — le test révèle qui détient réellement le mot de passe et les clés du dépôt.","**Une preuve existe** — un journal daté et signé, remis au client, sert d'argument de vente et de protection en cas de litige.",{"type":36,"title":50,"body":51},"Préparer le test : périmètre, machine jetable, effort","Choisissez un site par client et par trimestre, en alternant les profils : un site adossé à une base de données, un autre aux fichiers téléversés volumineux, un troisième avec des tâches planifiées. Avant de commencer, rassemblez trois éléments hors du serveur du site : l'accès au dépôt, le mot de passe ou la clé qui l'ouvre, et la liste des secrets de l'application.\n\nLouez ensuite un VPS de test jetable, avec le même système que la production, et prévoyez de le détruire en fin de séance. Pour l'effort, comptez à titre d'ordre de grandeur éditorial une demi-journée par trimestre pour un site type, davantage pour un dépôt volumineux, moins quand la procédure est rodée. Notez l'heure de début avant la première commande, jamais après.",{"type":53,"title":54,"steps":55},"steps","La procédure en neuf étapes",[56,59,62,65,68,71,74,77,80],{"title":57,"body":58},"Fixer l'incident simulé","Notez l'heure précise de l'incident simulé, par exemple la dernière écriture connue sur le site, et le périmètre à restaurer : fichiers, base de données, configuration. Cette heure sert au calcul du RPO.",{"title":60,"body":61},"Créer le VPS de test","Créez une machine neuve avec le même système d'exploitation que la production. Aucun fichier du site n'y arrive depuis le disque d'origine. Notez l'heure de début : c'est le départ du chronomètre du RTO.",{"title":63,"body":64},"Installer l'outil et ouvrir le dépôt","Installez seulement l'outil de sauvegarde et la pile du site (serveur web, PHP, base). Récupérez les accès dans votre coffre de mots de passe, jamais sur le serveur sinistré. `restic -r \u003Cdépôt> snapshots` doit lister les points de restauration.",{"title":66,"body":67},"Choisir le snapshot","Retenez le dernier snapshot antérieur à l'incident simulé et notez son identifiant et son horodatage. C'est lui qui fixe le RPO constaté.",{"title":69,"body":70},"Restaurer les fichiers","`restic -r \u003Cdépôt> restore \u003Cid> --target \u002Fsrv\u002Frestauration`\nPuis déplacez le contenu vers le répertoire web. Avec Borg, placez-vous d'abord dans le dossier cible, car l'extraction écrit dans le répertoire courant : `cd \u002Fsrv\u002Frestauration && borg extract \u003Cdépôt>::\u003Carchive>`.",{"title":72,"body":73},"Restaurer la base de données","`pg_restore --create --dbname=postgres sauvegarde.dump`\nPour un dump texte, `psql -f sauvegarde.sql`. Comptez ensuite les lignes d'une table témoin (`SELECT count(*) FROM commandes;`) et comparez avec la valeur relevée en production avant le test.",{"title":75,"body":76},"Reconstituer la configuration","Remettez en place le fichier `.env`, les secrets, le vhost et les tâches planifiées depuis le coffre, puis alignez les versions de PHP et de la base sur celles de la production.",{"title":78,"body":79},"Vérifier l'application","Ouvrez la page d'accueil, connectez-vous à l'administration et repérez la dernière commande ou le dernier article en base. Sans toucher au DNS : `curl -k --resolve votre-domaine.com:443:\u003CIP_DU_VPS_DE_TEST> https:\u002F\u002Fvotre-domaine.com\u002F`.",{"title":81,"body":82},"Arrêter le chronomètre et détruire la machine","Arrêtez à la première requête applicative réussie, pas à la fin de la commande de restauration. Calculez le RTO et le RPO, remplissez le journal, puis détruisez le VPS de test.",{"type":36,"title":84,"body":85},"Le chronomètre : RTO et RPO constatés","Le RTO constaté est l'heure de fin de restauration vérifiée moins l'heure de début du test. Le RPO constaté est l'écart entre l'heure de l'incident simulé et l'horodatage du snapshot restauré. Prenons un exemple fictif : incident simulé à 14 h 00, dernier snapshot pris à 03 h 00 le même jour, soit 11 heures de données perdues. Si le contrat promet 24 heures, c'est conforme ; s'il en promet 4, c'est non conforme, et le journal doit l'écrire tel quel.\n\nUn RTO mesuré en test reste un plancher optimiste : machine neuve, personne n'attend, aucune pression. Il vaut pourtant mieux qu'un calcul de coin de table, surtout quand le dépôt est volumineux : sur un débit modeste, le temps de téléchargement suffit à rendre un RTO théorique irréaliste. Mesurez le débit réel au moment de la restauration et notez-le dans le journal.",{"type":87,"title":88,"headers":89,"rows":93},"comparison","Le journal de test : champs à remplir",[90,91,92],"Champ","Ce qu'on y note","Exemple",[94,98,102,106,110,114,118,122],[95,96,97],"Date et site","Jour du test et site client restauré","JJ\u002FMM\u002FAAAA, site de démonstration",[99,100,101],"Outil et snapshot","Outil de sauvegarde, identifiant et horodatage du snapshot","Restic, identifiant court, horodatage complet",[103,104,105],"Durée et RTO","Heure de début, heure de fin vérifiée, durée constatée","Début 09 h 00, fin 10 h 40, RTO 1 h 40",[107,108,109],"RPO constaté","Écart entre l'incident simulé et le snapshot, comparé à la cible","11 h constatées pour 24 h promises",[111,112,113],"Anomalies","Tout ce qui a bloqué ou ralenti la reprise","Dossier d'uploads absent du périmètre",[115,116,117],"Correctif et échéance","Action, responsable et date de réalisation","Ajouter le dossier au dépôt, avant le prochain test",[119,120,121],"Signataire","Personne qui atteste le test","Nom, fonction, signature",[123,124,125],"Hors périmètre","Ce qui n'a pas été testé","E-mails, DNS, certificats, services tiers",{"type":87,"title":127,"headers":128,"rows":132},"Commandes de référence par outil",[129,130,131],"Outil","Lister les points de restauration","Restaurer et contrôler",[133,137,141,145,149,153],[134,135,136],"Restic","`restic -r \u003Cdépôt> snapshots`","`restic -r \u003Cdépôt> restore \u003Cid> --target \u002Fsrv\u002Frestauration`",[138,139,140],"Restic, intégrité du dépôt","`restic -r \u003Cdépôt> check`","`check` vérifie la structure ; `--read-data` relit tout le dépôt, `--read-data-subset=10%` une part au hasard",[142,143,144],"Borg","`borg list \u003Cdépôt>`, puis `borg list \u003Cdépôt>::\u003Carchive>`","`borg extract --list \u003Cdépôt>::\u003Carchive>` depuis le dossier cible ; `--dry-run` lit et vérifie sans écrire",[146,147,148],"PostgreSQL, dump custom","`pg_restore --list sauvegarde.dump`","`pg_restore --create --dbname=postgres sauvegarde.dump`, puis comptage d'une table témoin",[150,151,152],"PostgreSQL, dump texte","Vérifier la taille et la date du fichier","`psql -f sauvegarde.sql`, puis comptage d'une table témoin",[154,155,156],"Fichiers uploadés","Comparer le nombre de fichiers du dépôt à la production","`find \u002Fsrv\u002Frestauration -type f | wc -l` puis ouverture de trois fichiers au hasard",{"type":40,"title":158,"items":159},"Pièges de restauration, avec leur symptôme",[160,161,162,163,164,165,166],"**Clé du dépôt stockée sur le serveur sinistré** — la machine neuve n'ouvre pas le dépôt et affiche `wrong password or no key found` ; gardez la clé dans un coffre séparé, avec deux détenteurs.","**Base restaurée, fichiers uploadés absents** — le site s'affiche mais les images et pièces jointes répondent 404 ; le périmètre ne couvrait que la base ou que le code.","**Version de PHP ou de base différente** — page blanche, erreur de syntaxe ou de migration ; relevez les versions de chaque site dans le journal.","**Secrets et `.env` non sauvegardés** — l'application démarre mais ne joint plus la base, le serveur de courrier ni les API tierces.","**Dépôt trop volumineux pour la bande passante** — le RTO théorique paraît bon, le RTO réel dépasse la promesse ; mesurez le débit avant de promettre.","**Dump tronqué** — le nombre de lignes de la table témoin ne correspond pas à la production ; relancez la sauvegarde et contrôlez sa taille.","**Tâches planifiées non recréées** — le site répond mais n'envoie plus de courriels ni de rappels ; inventoriez les crons avant le test.",{"type":36,"title":168,"body":169},"Dépannage : les erreurs vues pendant un exercice","**`Fatal: wrong password or no key found`** — Restic ne trouve aucune clé qui s'ouvre avec le mot de passe fourni. Causes fréquentes à écarter une à une : mot de passe saisi avec des caractères spéciaux altérés par le shell, mot de passe lu sur l'entrée standard, URL de dépôt S3 au mauvais style, fichier de clé abîmé. Essayez `--password-file` ou la variable `RESTIC_PASSWORD`, vérifiez l'URL du dépôt puis `restic key list`. Si le mot de passe est réellement perdu, les données du dépôt sont perdues avec lui : inscrivez-le en anomalie critique.\n\n**Aucun point de restauration récent** — `restic snapshots` ne liste rien de la semaine : le job de sauvegarde s'arrête en silence. Corrigez le timer et ajoutez une alerte.\n\n**`pg_restore` se termine avec des erreurs ignorées** — par défaut, il continue et affiche un décompte à la fin. Rejouez avec `--exit-on-error` pour vous arrêter à la première erreur, et lisez-la avant de déclarer le test réussi.\n\n**Les fichiers sont là mais le site répond 403** — la restauration en root a laissé les fichiers au mauvais propriétaire. Rendez-les à l'utilisateur du serveur web.",{"type":171,"title":172,"body":173},"tip","Le mot de passe du dépôt ne vit jamais seul sur le serveur","Conservez-le dans un coffre d'équipe, avec une copie scellée chez un second responsable. L'exercice commence par ouvrir le dépôt depuis ce coffre : si quelqu'un doit se connecter au serveur du site pour retrouver le mot de passe, le test est déjà en échec, et c'est l'anomalie la plus utile qu'il puisse révéler.",{"type":36,"title":175,"body":176},"Le journal remis au client : une page, et ce qui n'a pas été testé","Le journal tient sur une page : en-tête avec client, site et date ; tableau des huit champs ; conclusion d'une phrase, conforme ou non aux cibles de RPO et de RTO ; plan correctif daté ; signature. Réservez un encart final « Non testé dans cet exercice » : boîtes e-mail et délivrabilité, DNS et délégation, certificats TLS, services tiers comme le paiement ou un CRM, et tout autre site du compte.\n\nUn journal qui n'écrit pas ses limites se lit comme « tout est sauvegardé », et c'est la promesse qu'on ne peut pas tenir. Conservez les journaux de chaque trimestre : un seul test prouve un jour, une série prouve une pratique. Relevez aussi les versions de PHP de chaque site, comme dans le guide sur l'inventaire des versions d'un parc de clients : c'est le piège le plus fréquent au moment de rejouer.",{"type":36,"title":178,"body":179},"Côté contrat : ce que la clause de sauvegarde doit nommer","Une clause utile nomme sept points : le périmètre (fichiers, bases, configuration), la fréquence, la rétention, les cibles de RPO et de RTO, la fréquence et la preuve des tests, la responsabilité si la restauration échoue, et la personne qui détient les accès au dépôt. Ce n'est pas un avis juridique : faites relire le texte par un juriste. Et ne promettez jamais ce que l'infrastructure sous-jacente ne garantit pas.\n\nSur ce point, les sauvegardes ServOrbit.com sont hebdomadaires en entrée de gamme, quotidiennes sur Pro et sur toutes les offres d'hébergement revendeur. Le RPO plancher se déduit de cette fréquence : jusqu'à sept jours avec une sauvegarde hebdomadaire, jusqu'à un jour avec une quotidienne. Un RPO de moins d'un jour exige donc une sauvegarde applicative propre à l'agence, en plus. Quant à la durée de restauration, aucun engagement ne se déduit d'une fréquence : elle se mesure, avec l'exercice ci-dessus.",{"type":36,"title":181,"body":182},"Rendre le test facturable : un argument de vente, pas une charge","L'objection est connue : le client ne le demande pas, et le temps n'est pas facturé. Deux réponses. Intégrez au forfait de maintenance une ligne « test de restauration trimestriel, journal remis », ou facturez la demi-journée à part. Et considérez le journal comme un livrable : en cas d'incident, il montre ce qui avait été testé et corrigé ; en phase de vente, il répond à « prouvez-le » avant que la question soit posée.\n\nPour tenir le rythme sur un portefeuille, prévoyez une rotation : un site par client et par trimestre, calendrier fixé en début d'année. Le VPS de test se loue et se détruit à la demande ; les conditions figurent sur la page de l'offre.","Un portefeuille de sites, des preuves à fournir","Une agence qui doit prouver ses restaurations a besoin d'un seul endroit pour son portefeuille : domaines, hébergements et VPS d'essai jetables. L'espace agence ServOrbit.com centralise les services et les expirations : vous gardez la relation client, nous tenons l'infrastructure.","Découvrir l'offre agences","\u002Fsolutions\u002Fagences",[188,203,218],{"id":189,"slug":190,"slugs":191,"title":195,"excerpt":196,"readTime":17,"views":18,"isPinned":19,"publishedAt":197,"updatedAt":198,"category":199,"categories":200,"featuredImage":30,"bgImage":31,"posterImage":202,"relatedSolution":30},347,"backup-vps-restic-s3-3-2-1",{"fr":190,"en":192,"ar":193,"es":194},"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é.","2026-09-10T00:00:00+00:00","2026-10-20T23:18:06+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[201],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fbackup-vps-restic-s3-3-2-1-poster.svg",{"id":204,"slug":205,"slugs":206,"title":210,"excerpt":211,"readTime":212,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":213,"category":214,"categories":215,"featuredImage":30,"bgImage":31,"posterImage":217,"relatedSolution":30},521,"checklist-audit-securite-mensuel-vps-clients-agence",{"fr":205,"en":207,"ar":208,"es":209},"monthly-security-audit-checklist-client-vps-agency","قائمة-تدقيق-أمان-vps-شهرية-للعملاء-للوكالات","auditoria-seguridad-mensual-vps-clientes-agencia-checklist","Audit sécurité mensuel d'un VPS client : checklist en 45 min","Sept contrôles à dérouler chaque mois sur un VPS client : mises à jour, noyau, comptes SSH, ports, certificats, sauvegardes, journaux. Rapport daté inclus.",10,"2026-10-29T03:10:22+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[216],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fchecklist-audit-securite-mensuel-vps-clients-agence-poster.svg",{"id":219,"slug":220,"slugs":221,"title":225,"excerpt":226,"readTime":17,"views":18,"isPinned":19,"publishedAt":227,"updatedAt":228,"category":229,"categories":230,"featuredImage":30,"bgImage":31,"posterImage":232,"relatedSolution":30},508,"inventaire-versions-php-parc-sites-clients-agence",{"fr":220,"en":222,"ar":223,"es":224},"php-version-inventory-for-client-sites-an-agency-method","جرد-إصدارات-php-لمواقع-العملاء-منهج-للوكالات","inventario-de-versiones-php-de-sitios-cliente-metodo-de-agencia","Inventaire des versions PHP du parc clients : méthode d'agence","Registre des versions PHP de vos sites clients chez plusieurs hébergeurs : paliers d'accès, scripts en lot, lots de priorité, message client et preuve datée.","2026-10-27T00:00:00+00:00","2026-10-27T23:58:39+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[231],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Finventaire-versions-php-parc-sites-clients-agence-poster.svg",1793251300777]