Un support de 2 To suffit-il ? Dimensionner une sauvegarde avec To, Tio, évolution et rétention

Une destination annoncée à 2 To n'a pas la même capacité que 2 Tio. L'écart passe facilement inaperçu lorsque le système d'exploitation, le logiciel de sauvegarde, la facture cloud et la fiche du support n'emploient pas les mêmes unités. Autre erreur courante : dimensionner la destination à partir du volume utilisé aujourd'hui sans compter les données modifiées qui resteront dans les points de restauration.

Ce guide étudie un cas hypothétique : 1,6 Tio sont actuellement utilisés, 25 Gio de modifications uniques restent conservées chaque jour, les points de restauration quotidiens sont gardés 14 jours et une marge de 15% est choisie explicitement. Il ne s'agit pas de reproduire le moteur d'un produit précis. Le but est d'établir un contrôle de capacité transparent avant de comparer des supports ou des offres.

Ramener toutes les entrées au même système d'unités

Les préfixes décimaux du SI suivent des puissances de 1 000, tandis que les préfixes binaires de l'IEC suivent des puissances de 1 024. Le NIST donne 1 GB pour 1 000 000 000 octets et 1 GiB pour 1 073 741 824 octets. La norme actuelle IEC 80000-13:2025 précise les noms, symboles, définitions et facteurs de conversion employés en informatique, y compris les préfixes binaires. Ces définitions sont consultables dans la référence du NIST sur les préfixes binaires et la présentation de l'IEC 80000-13:2025.

Les symboles ne sont pas interchangeables. Un Tio vaut environ 1,0995 To et un To environ 0,9095 Tio. Il faut choisir une unité de travail commune, par exemple le Gio ou l'octet, et noter l'unité de chaque valeur. Le convertisseur de stockage Calquio distingue GB, TB, GiB et TiB dans ses sélecteurs ; la version française de l'interface affiche les libellés localisés. Cette séparation empêche d'introduire un « giga » sans définition dans le calcul.

Écrire les hypothèses avant de calculer

La capacité maximale du disque source ne suffit pas. Une première estimation utile doit consigner au moins les éléments suivants :

• Le volume réellement utilisé à la source, et non la seule capacité maximale du disque.
• Les données modifiées conservées chaque jour, c'est-à-dire le volume unique censé continuer à occuper la sauvegarde compte tenu du fonctionnement connu du produit.
• La durée de rétention, pendant laquelle ces changements restent représentés dans les points de restauration.
• La marge de planification, choisie et documentée pour absorber l'incertitude et la croissance proche.
• L'unité et la capacité utilisable de la destination, car l'étiquette ne correspond pas toujours à l'espace disponible pour les sauvegardes.

Ces variables se retrouvent dans des outils réels. Pour estimer Azure Backup, Microsoft demande notamment le volume utilisé, le taux de modification prévu et la politique de rétention, tout en distinguant plusieurs types de sauvegarde. Cette documentation justifie le choix des entrées ; elle ne signifie pas que la formule simplifiée ci-dessous reproduit le calcul Azure. Voir la documentation Microsoft Learn en français, dont la version source a été mise à jour le 19 septembre 2025.

Dans cet exemple, « 25 Gio par jour » désigne 25 Gio de données modifiées qui occupent de l'espace supplémentaire pendant toute la fenêtre de 14 jours. Ce n'est ni le total des écritures de l'application, ni le trafic réseau, ni un taux universel. Les 15% constituent aussi une hypothèse choisie, pas une recommandation générale.

Reproduire le calcul sur 14 jours

Le Gio sert d'unité de travail commune.

1. Convertir le volume actuel : 1,6 Tio × 1024 = 1638,4 Gio.
2. Calculer les modifications conservées : 25 Gio/jour × 14 jours = 350 Gio.
3. Additionner le volume actuel et les modifications : 1638,4 + 350 = 1988,4 Gio.
4. Calculer la marge choisie : 1988,4 × 15% = 298,26 Gio.
5. Ajouter la marge : 1988,4 + 298,26 = 2286,66 Gio.

La formule complète est donc :

capacité requise = (volume utilisé + modification quotidienne conservée × jours de rétention) × (1 + marge)

Avec les entrées retenues :

(1638,4 Gio + 25 Gio × 14) × 1,15 = 2286,66 Gio

Le résultat équivaut à 2,2331 Tio ou 2,4553 To. Conserver les valeurs intermédiaires permet de remplacer clairement la durée de rétention, le taux mesuré ou la marge. Cela évite aussi de comparer directement 2,2331 Tio à une étiquette décimale de 2 To.

Comparer 2 To et 3 To sur la même base

Chaque capacité nominale décimale est convertie en Gio avant d'être comparée au besoin de 2286,66 Gio.

L'option 2 To échoue avant même de compter le système de fichiers, le catalogue de sauvegarde, les métadonnées, l'espace réservé ou la zone de travail temporaire. Une destination nominale de 3 To dépasse le besoin simplifié, mais ce n'est pas une garantie d'achat. Il faut vérifier qu'après formatage et réserves, le produit expose toujours au moins le nombre d'octets requis.

Pour un service cloud, il faut aussi déterminer ce que « données stockées » signifie pour la facturation et les quotas. Le service peut compter les données logiques, les données compressées, les blocs modifiés, les instantanés, les copies répliquées ou plusieurs de ces éléments. La conversion d'unités est exacte ; le modèle de stockage dépend du produit.

Tester la sensibilité aux données modifiées

En gardant 1,6 Tio à la source, 14 jours de rétention et la marge choisie de 15%, on voit l'effet du volume modifié chaque jour :

Ce tableau est une analyse de sensibilité, pas trois prévisions. Il faut mesurer les modifications pendant des journées normales et des pointes connues, et non retenir la ligne qui correspond au support préféré. Si le scénario initial à 25 Gio par jour passe de 14 à 30 jours de rétention, l'estimation simplifiée monte à 2746,66 Gio, soit environ 2,9492 To, avant les surcoûts propres au produit. La rétention peut donc absorber la marge apparente sans croissance du volume initial.

Vérifier les limites avant de choisir

Le modèle suppose que les 25 Gio de chaque journée occupent un espace supplémentaire jusqu'à leur expiration. Il peut surestimer un système qui déduplique ou compresse efficacement. À l'inverse, il peut sous-estimer un produit qui crée régulièrement des copies complètes, conserve des métadonnées, réserve une zone de travail, réplique les données ou attend avant de supprimer les points expirés. Les fichiers chiffrés ou déjà compressés peuvent aussi se comporter autrement que des documents ordinaires.

Avant de retenir une destination :

1. Lire les définitions du produit pour les sauvegardes complètes, incrémentielles et différentielles, les instantanés et le stockage retenu.
2. Mesurer le volume source utilisé et les modifications avec des unités explicites.
3. Recalculer avec la fenêtre de restauration exigée et une marge documentée.
4. Comparer le résultat à la capacité utilisable, pas seulement à l'étiquette commerciale.
5. Effectuer une sauvegarde et une restauration représentatives, puis rapprocher la consommation observée de l'estimation.

Le dimensionnement répond à la question « cette destination est-elle vraisemblablement assez grande ? ». Il ne prouve pas que la sauvegarde est complète, isolée, restaurable ou sûre. La configuration et la restauration doivent être testées dans le système choisi.

Sources

• NIST — Préfixes pour les multiples binaires (définitions des unités ; consulté le 3 août 2026)
• IEC — IEC 80000-13:2025, Grandeurs et unités : science et technologies de l'information (publié le 11 février 2025 ; consulté le 3 août 2026)
• Microsoft Learn — Estimer et comprendre la tarification Azure Backup (source mise à jour le 19 septembre 2025 ; consultée le 3 août 2026)