Comment dimensionner une copie hors site : stockage de sauvegarde immuable, durée de transfert et coûts d’egress cloud

Les demandes de budget pour une sauvegarde externalisée achoppent généralement sur l’un de ces deux écueils : le stockage est dimensionné comme « une copie des disques », ou la facture d’egress du cloud est oubliée. Ces deux erreurs se révèlent des mois plus tard — lorsque la rétention remplit le bucket ou que la première facture arrive.

Ce guide présente les formules que nous utilisons pour dimensionner une copie hors site immuable — stockage, durée de transfert, egress et capacité de restauration —, avec un exemple de calcul à adapter à vos propres chiffres.

Les cinq paramètres indispensables

1. Données utilisées (D) — les données réellement stockées sur les disques protégés, et non leur taille provisionnée. Un disque de 4 To rempli à 40 % compte pour 1,6 To.
2. Taux de réduction des données (r) — compression et déduplication obtenues par le logiciel de sauvegarde ; un ratio de 1,3 à 2× est courant pour un parc de serveurs hétérogène.
3. Modifications quotidiennes (Δ) — blocs nouveaux ou modifiés chaque jour, après réduction. Mesurez-les à partir de la taille des incrémentielles de vos sauvegardes actuelles.
4. Politique de rétention — le nombre de points de restauration quotidiens, hebdomadaires et mensuels que vous conservez.
5. Croissance — l’augmentation attendue des données sur la durée du contrat, généralement 10 à 20 % par an.

Formule de stockage pour une rétention GFS

Avec des sauvegardes en mode incrémental permanent sur stockage objet, chaque point de restauration ne conserve que les blocs modifiés qu’il ne partage pas avec des points plus récents. D’où une estimation simple :

Stockage ≈ F + Nd × Δ + Nw × Δw + Nm × Δm + surcoût

F   = D / r        copie complète
Nd  = points quotidiens                     Δ  = modifications quotidiennes
Nw  = points hebdomadaires supplémentaires  Δw ≈ 2,5 × Δ
Nm  = points mensuels supplémentaires       Δm ≈ 6 × Δ
surcoût ≈ 10 % pour Object Lock et métadonnées

Les coefficients hebdomadaire et mensuel traduisent le fait que de nombreuses modifications quotidiennes réécrivent les mêmes blocs ; remplacez-les par des valeurs mesurées dès que vous disposez d’un mois d’historique. Exemple de calcul : 20 To de données utilisées, une réduction de 1,5× et 200 Go de modifications par jour.

La politique de rétention fait presque doubler la capacité. Fixez-la système par système : les systèmes de catégorie I exigent souvent 12 points mensuels, alors que 14 jours suffisent aux systèmes de test et auxiliaires.

Object Lock et surcoût lié à l’immuabilité

En mode conformité, Object Lock conserve chaque objet jusqu’à sa date de fin de rétention, même lorsque le logiciel de sauvegarde n’en a plus besoin. Les outils de sauvegarde prolongent donc les périodes de verrouillage par blocs de plusieurs jours (Veeam, par exemple, ajoute généralement jusqu’à dix jours), et les points expirés ne sont supprimés qu’à la fin du verrouillage. Prévoyez 10 à 15 % de plus que le calcul de rétention, et ne tablez jamais sur un stockage immuable rempli à 100 % : un bucket plein ne peut pas être purgé par anticipation.

Transfert initial : bande passante et durée

Le plus gros transfert est celui de la première copie complète : l’amorçage. Dimensionnez la liaison pour qu’il s’achève en deux semaines au plus, en gardant à l’esprit que seuls 80 % environ de la bande passante nominale sont exploitables sur de longues périodes :

Jours = Données (To) × 8 000 000 / (Débit (Mbit/s) × 0,8 × 86 400)

Les incrémentielles quotidiennes sont bien plus légères : 500 Go dans une fenêtre de huit heures exigent environ 140 Mbit/s, ou moins de 50 Mbit/s s’ils sont étalés sur 24 heures.

Coûts d’egress du cloud

Les données qui sortent d’un cloud public sont facturées au gigaoctet par le fournisseur cloud, et non par le prestataire de sauvegarde : ce poste doit donc figurer sur une ligne distincte de la demande budgétaire. Tarifs publics d’Azure pour l’egress Internet depuis l’Europe (acheminé via le réseau Microsoft) :

Dans l’exemple de calcul, le transfert initial de la copie complète de 13,3 To coûte environ 1 137 $, et 6 To de modifications mensuelles environ 513 $ par mois, soit 6 160 $ par an. Trois leviers permettent d’alléger la facture : la compression et la déduplication avant transfert, l’option moins chère « préférence de routage : Internet » (0,08 $ et 0,065 $ par Go sur les deux premières tranches), et les programmes de sponsoring ou de crédits, qui couvrent peut-être déjà l’abonnement.

Dimensionner la capacité de restauration

Les tests de restauration nécessitent du calcul et du disque à proximité du stockage de sauvegarde. Dimensionnez le pool pour le plus gros système à restaurer en une seule fois, et non pour un système moyen :

• Disque : les données utilisées du plus gros système, plus 20 % d’espace de travail.
• Calcul : assez de vCPU et de RAM pour faire tourner ses serveurs simultanément — par exemple deux VM de 8 vCPU et 32 Go chacune.
• Temps : tester l’ensemble des systèmes mobilise généralement le pool deux à quatre semaines par an.

Check-list de dimensionnement

• Mesurez les données utilisées par serveur et la taille des bases de données, pas les disques provisionnés.
• Relevez la taille des incrémentielles sur 30 jours dans vos sauvegardes actuelles pour obtenir le volume réel de modifications quotidiennes.
• Fixez la rétention par catégorie de système avant de demander des prix.
• Ajoutez 10 à 15 % pour l’immuabilité et 10 à 20 % pour la croissance.
• Dimensionnez la liaison d’amorçage pour 14 jours au plus, et la fenêtre quotidienne pour le pic de modifications.
• Inscrivez l’egress cloud sur une ligne distincte de la demande budgétaire.

Vous préférez ne pas faire le calcul vous-même ? Envoyez-nous vos paramètres : nous dimensionnons la réserve de sauvegarde externalisée souveraine et vous remettons une architecture budgétée.