Dimensionner le stockage d’un Backup cloud

Sur les projets de sauvegarde, la question revient souvent : combien de stockage faut-il prévoir pour ce client ?

La réponse ne se résume pas seulement au volume source. Le plan de sauvegarde, la durée de rétention et la nature des données à sauvegarder pèsent également dans la balance. Ce guide pose la méthode et fournit un calculateur pour chiffrer un projet en avant-vente.

1. RPO et RTO, le point de départ

Avant de choisir un plan, une fréquence ou une rétention, il faut poser une question simple au client : en cas d’incident, combien de temps d’indisponibilité et combien de données perdues est-il prêt à accepter ? Cette réponse se décline en deux indicateurs qui structurent toute la stratégie de sauvegarde.

RPO, Recovery Point Objective

Le RPO est la perte de données maximale acceptable, exprimée en temps. Si le RPO est de 24 heures, on accepte de perdre jusqu’à une journée de travail entre la dernière sauvegarde et l’incident. Si le RPO est de 1 heure, il faut une sauvegarde par heure. Le RPO pilote la fréquence des sauvegardes, et donc indirectement le volume cumulé : 24 sauvegardes par jour ne pèsent pas la même chose qu’une seule.

RTO, Recovery Time Objective

Le RTO est le temps maximum acceptable pour restaurer les données et redémarrer l’activité. Si le RTO est de 4 heures, la restauration complète doit tenir dans ce délai. Le RTO pilote le type de sauvegarde et la chaîne de restauration : plus la chaîne de sauvegardes à rejouer est longue, plus la restauration est lente.

L’enchaînement à retenir.

RPO et RTO sont définis par le client en fonction de son métier et de sa tolérance au risque. Ces deux objectifs déterminent ensuite le plan de sauvegarde, la fréquence et la rétention. Le volume de stockage à provisionner découle de ces choix. Sans cette discussion en amont, on construit un dimensionnement qui peut ne pas répondre au besoin réel.

Pour le même volume source, faire passer le RPO de 24 h à 1 h multiplie le nombre de sauvegardes par 24. Même avec une incrémentielle légère, 24 incréments par jour ajoutent du volume et surtout des points de restauration à conserver. À l’inverse, un RTO court oriente vers des plans avec des complètes plus fréquentes (donc plus de stockage), car une chaîne incrémentielle longue rallonge la restauration. Le dimensionnement du stockage découle donc d’une stratégie RPO / RTO, jamais l’inverse.

2. Les trois types de sauvegarde

Toute solution moderne, Le Backup unyc inclus, repose sur trois mécaniques combinables. Les comprendre est la première étape pour estimer correctement un stockage.

Sauvegarde complète (Full)

À chaque exécution, la sauvegarde copie l’intégralité de la source. Chaque point de restauration est autonome : une seule lecture suffit pour restaurer. C’est la méthode la plus simple, mais aussi la plus coûteuse en stockage et en bande passante. Pour une source de 100 Go conservée 30 jours en quotidien, on stocke 30 fois 100 Go, soit 3 To bruts avant compression.

Sauvegarde incrémentielle (Incremental)

L’incrémentielle ne sauvegarde que les blocs modifiés depuis la dernière sauvegarde, qu’elle soit complète ou incrémentielle. C’est la méthode la plus économe en stockage : avec un taux de change quotidien de 5 %, chaque incrément pèse 5 Go pour une source de 100 Go. En contrepartie, restaurer un point de restauration nécessite de relire la chaîne complète (1 full puis N incréments). Si un maillon est corrompu, la chaîne entière est compromise.

Sauvegarde différentielle (Differential)

La différentielle ne sauvegarde que les blocs modifiés depuis la dernière sauvegarde complète. La taille croît donc jusqu’au prochain full : à 5 % de change quotidien, 5 Go le jour 1, 10 Go le jour 2, environ 35 Go le jour 7. Avantage côté restauration : il suffit du full et d’un seul différentiel.

3. Schéma comparatif sur 7 jours

Hypothèse : source de 100 Go, taux de changement quotidien de 5 %, sauvegarde quotidienne. La visualisation interactive ci-dessous compare les trois plans jour par jour. Cliquez sur « Rejouer l’animation » pour faire défiler les 7 jours.

Le jour 1 est commun aux trois plans : c’est la complète de référence, sans laquelle aucun delta ne pourrait être interprété. Sur 7 jours, l’incrémentielle écrit environ 130 Go, la différentielle 205 Go, la complète 700 Go.

4. Les plans de sauvegarde du Backup

La solution de sauvegarde unyc propose plusieurs schémas natifs qui combinent les trois types avec des règles de rétention. Le choix du plan a un impact direct sur le stockage facturé.

5. Les paramètres du calcul

Au delà du type et du plan, plusieurs paramètres déterminent la taille réelle du stockage. Ce sont eux qui font la différence entre un dimensionnement crédible et un devis approximatif.

Volume source

Le volume réellement utilisé sur la machine, pas la taille du disque. Donnée non négociable. À demander en Go par machine, sinon en moyenne par typologie.

Nombre et type de machines

Postes de travail, serveurs virtuels, serveurs physiques, NAS. Chaque typologie a un comportement de change et de croissance différent.

Fréquence des sauvegardes

Le standard est une sauvegarde par jour. Les bases SQL et Exchange sortent souvent du lot avec 2 à 4 sauvegardes par jour pour réduire la perte potentielle de données.

Rétention

Combien de jours, semaines ou mois conserve-t-on les points de restauration ? C’est le levier le plus impactant. Une rétention de 30 jours en Toujours complète multiplie le stockage par 30. En Toujours incrémentielle, elle ne le multiplie que par 1 + 29 × taux de change.

Taux de changement quotidien

Le pourcentage de blocs modifiés chaque jour. Ordres de grandeur typiques :

Hypothèse prudente par défaut : 5 %.

Croissance annuelle

Le volume source ne reste pas figé. Selon le métier, prévoir 10 à 30 % de croissance par an. Hypothèse par défaut : 20 % par an. La croissance se compose : sur 3 ans, un volume de 1 To devient 1 × 1,2 puissance 3, soit environ 1,73 To.

Marge de sécurité

Les guides de dimensionnement évoquent souvent 15 à 20 % de marge. Sur des volumes modestes (quelques centaines de Go à 1 To), c’est défendable et l’absolu reste raisonnable. Sur des parcs de plusieurs téraoctets, 20 % se traduit vite par plusieurs centaines de Go de stockage facturés pour une marge théorique, qui devient difficile à justifier devant un client. La marge doit donc s’adapter à la taille du parc : 10 % constitue un bon compromis sur des parcs de quelques téraoctets, suffisant pour absorber les pics de changement, les échecs de purge des anciens points et les sauvegardes manuelles ponctuelles, sans gonfler artificiellement le quota. C’est la valeur retenue par défaut dans le calculateur.

6. La compression

Le ratio de compression à appliquer varie fortement selon le type de données.

La solution applique par défaut une compression de niveau « Normal ». La KB 16791 officielle de l’éditeur sur la compression d’archive ne s’engage volontairement sur aucun pourcentage : elle précise seulement que quatre niveaux existent (None, Normal, High, Maximum) et que le ratio réel dépend entièrement du type de données. Sur des fichiers déjà compressés (.jpg, .pdf, .mp3, .zip, .mp4), même le niveau Maximum n’apporte presque rien.

Pourquoi 20 % par défaut. Les tests éditeur sur données très compressibles peuvent monter à plus de 50 %, mais la réalité d’un parc client mixte (qui mélange bureautique, mais aussi PDF, images, vidéos, archives, exécutables) se situe plutôt autour de 15 à 30 %. Le calculateur retient donc 20 % par défaut, valeur prudente et défendable, avec la possibilité de monter (parc majoritairement bureautique ou bases de données non compressées) ou de descendre (parc majoritairement multimédia).

NdR : en cas de doute sur un parc précis, basez-vous sur une mesure réelle (test sur 10 % du parc, observation sur 1 semaine) plutôt que sur les ratios théoriques.

7. Trois exemples chiffrés

Trois scénarios types rencontrés en avant-vente, calculés avec compression 20 %, marge 10 %, croissance 20 % sur 12 mois, plan Toujours incrémentielle, rétention 30 jours.

Pour comparer, le même parc mixte en Toujours complète sur 30 jours donnerait environ 141 To bruts avant compression. Le choix du plan combiné à la compression ramène le quota à provisionner à un ordre de grandeur exploitable.

8. Contraintes opérationnelles à anticiper

Le calcul du stockage n’est qu’une partie de l’équation. Une fois le plan retenu, plusieurs contraintes opérationnelles doivent être anticipées dès l’avant-vente, car elles peuvent invalider un dimensionnement parfait sur le papier.

Fenêtres de sauvegarde

Une sauvegarde complète d’un volume conséquent prend du temps : compter plusieurs heures pour quelques téraoctets, même avec un agent performant. Si la fenêtre est trop courte, la sauvegarde déborde sur les heures ouvrées, ralentit les utilisateurs et risque de ne pas terminer avant la prochaine exécution. À caler en concertation avec le client : sauvegardes en heures creuses, fenêtres adaptées aux serveurs critiques.

Plafonnage CPU et ressources des agents

Les agents installés sur les machines consomment du CPU et de la mémoire pendant la sauvegarde. Sans limitation, ils peuvent ralentir les utilisateurs, particulièrement sur les postes de travail et les serveurs applicatifs. La solution permet de plafonner l’usage CPU des agents (généralement à 30 ou 50 %). Réflexe à appliquer systématiquement.

Bande passante internet

C’est souvent le point bloquant du déploiement BaaS. La première sauvegarde complète envoie l’intégralité du volume source vers le cloud. Quelques ordres de grandeur sur le débit montant :

• Fibre 100 Mbps : environ 100 Go en 2 à 3 heures, 1 To en 24 à 30 heures.
• SDSL 10 Mbps : environ 100 Go en 24 heures, 1 To en une dizaine de jours.
• ADSL 1 Mbps montants : environ 100 Go en 10 jours dans des conditions optimales.

Deux leviers à actionner : vérifier le débit montant réel du site avant tout engagement (pas seulement le descendant affiché par les FAI), et plafonner la bande passante consommée par l’agent en heures ouvrées pour ne pas saturer la connexion partagée avec les autres usages.

À retenir. Stockage, temps de sauvegarde et bande passante sont liés. Optimiser l’un peut dégrader les deux autres. Un plan GFS conservateur en stockage demande plus de complètes, donc plus de bande passante et des fenêtres plus longues. Une rétention courte économise du stockage mais multiplie les opérations.

9. La méthode de calcul en 6 étapes

10. Le calculateur en ligne

Pour aller plus loin

• Documentation Cyber Protection Service en français, source editeur
• unyc Académie, pour les parcours de formation (réservé aux partenaires unyc)
• KB 16791 — Archive Compression in Acronis Products
• KB 59296 — How to set up backup schedule
• KB 68304 — Retention rules