Vous avez supprimé une VM mais souhaitez conserver — et contrôler — ses sauvegardes ? Voici une méthode pas‑à‑pas pour monter les points de restauration, mesurer la taille réellement facturée, et chiffrer l’économie mensuelle côté « compute » tout en gardant le stockage.
Sommaire
Contexte et objectif
Après la suppression d’une machine virtuelle, deux enjeux dominent : préserver l’intégrité des sauvegardes et réduire la facture. Concrètement, vous voulez (1) garder vos sauvegardes existantes, (2) les monter localement pour vérifier ce qui est conservé, et (3) quantifier l’économie obtenue par l’arrêt du « compute » (CPU/RAM/OS) en continuant à payer uniquement le stockage.
Ce guide livre une approche opérationnelle et un modèle chiffré pour estimer la baisse de coûts, avec des scripts de mesure, des tableaux d’aide à la décision et des optimisations rapides qui ne compromettent pas la restauration.
Plan d’action en trois volets
- Assurer la conservation et la traçabilité : figer la politique de rétention, étiqueter les jeux de sauvegarde, consigner les dates de fin de conservation obligatoires.
- Monter et contrôler : attacher une copie read‑only à une station de vérification (locale ou « sandbox » cloud) pour inventorier les données et valider les RPO/RTO.
- Chiffrer l’économie : calculer l’arrêt du compute, projeter la ligne « stockage » avec rétention/tiering/déduplication, puis comparer avant/après.
Ce qui change réellement après suppression d’une VM
- Compute : la facturation à la minute/heure de la VM disparaît (vCPU, RAM, licence OS s’il y a lieu). Attention : si vous avez des engagements type réservations ou « savings plans », l’économie effective dépend de la réallocation de ces engagements.
- Disques et snapshots : si vous conservez des disques gérés ou snapshots indépendants de la VM, ils continuent d’être facturés. Vérifiez l’absence de ressources orphelines.
- Sauvegardes gérées : la ligne « stockage » perdure selon la taille facturée après compression et déduplication, la rétention et la classe de stockage.
- Réseau et opérations : les restaurations ponctuelles et transferts sortants (egress) peuvent générer des frais additionnels.
Monter les sauvegardes localement en toute sécurité
Bonnes pratiques de montage
- Travaillez sur une copie (snapshot/clône) et montez-la en lecture seule.
- Isolez le réseau si vous démarrez une VM « bac à sable » pour inspection (pas de trafic sortant par défaut).
- Consignez l’empreinte (hash) des volumes avant/après pour tracer l’intégrité.
Cas Linux (image disque ou volume)
# 1) Identifier l'image
ls -lh /mnt/backups
# 2) Associer un loop device
sudo losetup -fP /mnt/backups/backup-vm.img
losetup -a # repérer /dev/loopX
# 3) Lister les partitions détectées
sudo partprobe /dev/loopX
lsblk /dev/loopX
# 4) Monter en lecture seule (ex: partition 1)
sudo mkdir -p /mnt/restore
sudo mount -o ro,noload /dev/loopXp1 /mnt/restore
# 5) Mesurer le volume logique
sudo du -sh /mnt/restore Cas Windows (VHD/VHDX ou volume attaché)
# PowerShell (élevé)
Mount-DiskImage -ImagePath "D:\Backups\backup-vm.vhdx" -ReadOnly
Get-Disk | Where-Object IsOffline -Eq $true | Set-Disk -IsOffline $false -IsReadOnly $true
Get-Partition | Get-Volume
# Mesure du contenu
Get-ChildItem X:\ -Recurse | Measure-Object -Sum Length
Cas « cloud snapshot » (générique)
- Créer un disque à partir du snapshot dans la même région.
- Attacher ce disque à une petite VM de test (burstable), en lecture seule.
- Monter le filesystem et lancer l’inventaire (hash/du/Get‑ChildItem).
- Arrêter/détacher/supprimer la VM de test dès la vérification terminée pour éviter des frais inutiles.
Mesurer pour estimer : les 5 leviers qui expliquent la facture
| Étape | Élément à mesurer | Pourquoi c’est déterminant ? |
|---|---|---|
| 1 | Volume total occupé par les sauvegardes (taille logique / taille effectivement facturée après déduplication et compression) | Base du coût de stockage, exprimé en Go‑mois. |
| 2 | Politique de rétention (nb de points de restauration, durée de conservation) | Plus la rétention est longue, plus le volume stocké augmente dans le temps. |
| 3 | Fréquence des sauvegardes (quotidienne, hebdo, mensuelle) | Impact direct sur la croissance ; moins de points = facture plus basse à volume égal. |
| 4 | Barème du fournisseur (tier chaud, cool/archivage, frais d’opérations, changement de tier) | Chaque classe a un prix/Go‑mois et des coûts d’accès différents. |
| 5 | Coûts d’exploitation supplémentaires (bande passante, CPU des jobs de sauvegarde/restauration) | Parfois marginaux, mais certains clouds facturent l’E/S réseau ou des instances temporaires. |
Formule simplifiée
Économie mensuelle ≈ (Coût VM compute précédent)
+ (Coût stockage sauvegardes AVANT optimisation)
– (Coût stockage sauvegardes APRÈS optimisation)
Tableau de modélisation (à copier dans Excel/Sheets)
| Paramètre | Symbole | Valeur (exemple) | Unité | Comment l’obtenir |
|---|---|---|---|---|
| Coût compute VM (moyenne mensuelle) | CVM | 95 | €/mois | Historique de facturation |
| Taille logique totale sauvegardée | L | 2 000 | Go | du -sh ou PowerShell |
| Facteur de dédup/compression | R | 4 | ratio | Rapports de sauvegarde |
| Taille facturée (approx.) | F = L / R | 500 | Go | Calcul |
| Prix/Go‑mois (tier chaud) | Phot | 0,020 | €/Go‑mois | Barème fournisseur |
| Prix/Go‑mois (tier archive) | Parc | 0,004 | €/Go‑mois | Barème fournisseur |
| Part des données en archive | α | 0,60 | ratio | Politique de rétention |
| Coût stockage AVANT optimise | S0 | 10,0 | €/mois | F × Phot |
| Coût stockage APRÈS optimise | S1 | 6,4 | €/mois | F×[(1−α)×Phot + α×Parc] |
| Économie mensuelle estimée | Δ | 98,6 | €/mois | CVM + S0 − S1 |
Remarque : adaptez les prix/Go‑mois à votre région et votre fournisseur. Si vous payez des engagements « réservés », tenez compte de leur réaffectation.
Exemple chiffré pas‑à‑pas (réaliste)
- Situation initiale : VM 4 vCPU/16 Go, coût compute moyen 95 €/mois. Sauvegardes quotidiennes incrémentielles + un full hebdo, rétention 12 mois. Taille logique 2 To, dédup/compression 4:1 → facturée ≈ 500 Go en tier « chaud ». Coût stockage ≈ 10 €/mois.
- Suppression de la VM : compute à 0 €. Les sauvegardes restent.
- Optimisations appliquées : rétention de 12→6 mois (incrémentiels) et tiering automatique qui archive 60 % des points >90 jours.
- Nouveau coût stockage :
500×(0,4×0,020 + 0,6×0,004)=6,4 €/mois. - Économie mensuelle :
95 + 10 − 6,4 = 98,6 €, hors coûts ponctuels de restauration.
Mesurer rapidement la taille réelle
- Station Linux :
du -sh /mnt/restorepour le volume logique ; ajoutez--apparent-sizepour une estimation sans sparse. - PowerShell :
Get-ChildItem -Recurse | Measure-Object -Sum Lengthpour la somme des tailles. - Comparer avec « facturé » : utilisez vos rapports de sauvegarde (ex. Azure Backup Reports), vos exports de coûts (AWS Cost Explorer, Google Cloud Usage Export) pour la taille après déduplication.
Outils d’estimation et alertes
- Calculettes officielles : saisissez Go, classe de stockage et région pour obtenir une projection.
- Alertes budgétaires : configurez des seuils sur le stockage et le réseau (egress) pour capter rapidement tout rebond.
- Étiquetage (tags) : ajoutez
project=legacy-vm,owner=team-x,retention=6mpour suivre précisément la ligne de coûts.
Optimisations rapides sans toucher aux données
- Baisser la rétention : passer de 12→6 mois peut réduire le stockage de ~40 % si les sauvegardes sont incrémentielles (à valider par vos rapports).
- Tiering automatique : déplacer les points les plus anciens vers un tier « cool » ou « archive » dès que les RTO le permettent.
- Déduplication côté sauvegarde : activez/comparez les moteurs (ex. dédup globale + compression).
- Nettoyage des snapshots orphelins : supprimez les instantanés hors politique.
Classes de stockage : comment arbitrer
| Tier | Cas d’usage | Prix/Go‑mois (tendance) | Coûts d’accès | Risques/Remarques |
|---|---|---|---|---|
| Chaud | Restauration fréquente (RTO courts) | Le plus élevé | Faibles | Conserver les 30–90 derniers jours |
| Cool | Accès occasionnels | Moyen | Moyens | Pénalités de suppression anticipée possibles |
| Archive | Conservation longue durée | Le plus bas | Élevés (récupération + délai) | Planifier la restauration (heures/jours) |
Coûts cachés & points de vigilance
- Restauration ponctuelle depuis l’archive : frais de lecture/réhydratation + éventuelle migration vers « chaud ».
- Egress : toute sortie vers on‑premise ou une autre région/zone peut être facturée au Go.
- Clés KMS/HSM : les coffres et opérations de chiffrement ont un coût résiduel.
- Licences BYOL : si des licences (OS/SQL) sont hors compute et encore allouées, recensez-les.
- Engagements réservés : réaffectez-les pour matérialiser l’économie côté compute.
Scripts prêts à l’emploi
Linux : inventaire et taille par répertoire
#!/usr/bin/env bash
TARGET="/mnt/restore"
echo "Date: $(date)"
echo "Apparent size:"
du -sh --apparent-size "$TARGET"
echo "Filesystem used:"
df -h "$TARGET"
echo "Top 20 répertoires:"
du -h --max-depth=1 "$TARGET" | sort -hr | head -n 20
PowerShell : taille logique et top dossiers
$path = "X:\"
$sum = (Get-ChildItem $path -Recurse -ErrorAction SilentlyContinue | Measure-Object -Sum Length).Sum
"{0:N2} Go" -f ($sum/1GB)
Get-ChildItem $path -Directory |
ForEach-Object {
$size = (Get-ChildItem $_.FullName -Recurse | Measure-Object -Sum Length).Sum
[PSCustomObject]@{ Dossier = $_.Name; Go = [math]::Round($size/1GB,2) }
} | Sort-Object Go -Descending | Select-Object -First 20
Actions, impact et risque
| Action | Gain potentiel | Risque | Mesure de contrôle |
|---|---|---|---|
| Réduire la rétention | ★★★☆ | Perdre des points anciens | Validation métier + sauvegarde légale séparée |
| Tiering vers archive | ★★★★ | RTO plus long | Documenter les délais + test de restauration |
| Nettoyage snapshots orphelins | ★★★☆ | Suppression par erreur | Liste d’exclusion + double validation |
| Déduplication avancée | ★★★☆ | CPU/temps de job | Fenêtres de sauvegarde adaptées |
| Compression agressive | ★★★☆ | Latence à la restauration | Tester les charges de prod typiques |
Suivi KPI et alertes
- Taille facturée (Go‑mois) par coffre/bucket.
- Taux de déduplication et ratio chaud/archivé.
- Coût par point de restauration (
€/restore point). - Fréquence des restaurations et coût moyen par restauration.
- Orphelins : # snapshots/disques sans attache.
Règle d’alerte type : « si la croissance sur 7 jours du Go‑mois > 10 % OU si le ratio archive < 50 % après 90 jours ⇒ ouvrir un ticket d’investigation ».
FAQ rapide
Q : Puis‑je supprimer la VM et garder toutes les sauvegardes ?
R : Oui, si vos sauvegardes sont gérées indépendamment de la ressource VM. Vérifiez les dépendances (coffre, clés, rôles d’accès) avant la suppression.
Q : Comment prouver que mes sauvegardes sont lisibles ?
R : Réalisez un test de restauration sur sandbox : clône/snapshot → montage en RO → calcul d’empreinte → contrôle d’applicatifs (bases, fichiers).
Q : Quelle unité utiliser pour mon modèle ?
R : Les clouds facturent en Go‑mois (ou GiB‑month). Soyez cohérent (Go vs GiB) et précisez la région.
Q : Et si j’ai des réservations de capacité ?
R : L’arrêt du compute ne se matérialise pleinement que si la réservation est réaffectée à d’autres charges ou résiliée à l’échéance.
Checklist opérationnelle
- Exporter la dernière facture et isoler la ligne compute de la VM.
- Étiqueter les sauvegardes existantes (
retention,tier,owner). - Créer un snapshot/clône de test et le monter en lecture seule.
- Mesurer taille logique (
du/PowerShell) et taille facturée (rapports backup/cost). - Établir la politique cible : rétention, tiering, fenêtre de restauration acceptable.
- Simuler le coût avant/après avec votre barème et valider avec l’équipe métier.
- Activer alertes budgétaires et rapports mensuels.
Modèle de calcul minimaliste (copier/coller)
# Entrées
C_VM = 95 # €/mois
L = 2000 # Go logiques
R = 4 # ratio dédup+compression
P_hot = 0.020 # €/Go-mois
P_arc = 0.004 # €/Go-mois
alpha = 0.60 # part archivée
# Calculs
F = L / R
S0 = F * P_hot
S1 = F * ((1 - alpha) * P_hot + alpha * P_arc)
Eco = C_VM + S0 - S1
print(f"Économie mensuelle ≈ {Eco:.2f} €") Conclusion
Supprimer une VM sans perdre ses sauvegardes est un excellent levier d’optimisation : l’arrêt du compute produit la majeure partie du gain, tandis que la maîtrise du stockage (rétention, tiering, déduplication) verrouille une facture minimale et prévisible. En appliquant le plan d’action ci‑dessus — montage en RO, mesures précises, modélisation avant/après, optimisations à faible risque — vous obtenez (1) un chiffrage clair du coût résiduel, (2) une mécanique reproductible pour faire évoluer la politique, et (3) des pistes concrètes pour réduire encore les coûts sans compromettre la capacité de restauration.
Annexe — Informations utiles en un coup d’œil
- Mesurer la taille réelle :
du -sh(Linux),Get-ChildItem | Measure-Object -Sum Length(PowerShell), puis comparer avec les rapports du fournisseur. - Outils d’estimation : calculettes officielles (prix/Go‑mois par région et par tier), exports de coût.
- Optimisations rapides : baisser la rétention, tiering automatique, activer la déduplication, supprimer les snapshots orphelins.
- Coûts cachés : egress, réhydratation depuis archive, KMS/HSM, engagements réservés.