Stockage BSU OUTSCALE : volumes, IOPS et snapshots

Le BSU (Block Storage Unit) est le stockage bloc d’OUTSCALE — l’équivalent d’EBS chez AWS — pour les disques attachés aux VMs. Le choix du type de volume (standard, gp2, io1) et le dimensionnement des IOPS déterminent directement la performance applicative ressentie. Cette page détaille les trois types disponibles, la mécanique des snapshots pour la sauvegarde, et les patterns d’attachement aux VMs. Page tagguée pour les piliers Reliability (sauvegardes, durabilité), Performance (IOPS adaptés), Cost (taille et type bien dimensionnés).

Ce que vous allez apprendre

Distinguer les trois types de volumes BSU (standard, gp2, io1) et choisir selon le profil.
Calculer les IOPS nécessaires pour un volume io1 (ratio 300 IOPS/GiB, max 13 000 IOPS).
Créer un volume, l’attacher à une VM avec le bon DeviceName.
Sauvegarder par snapshot et restaurer.
Copier un snapshot entre sous-régions (au sein de la même région).
Repérer les antipatterns : volume mal dimensionné, snapshots oubliés, taille fixée à vie.

Prérequis

Avoir créé au moins une VM (cf. Calcul — instances TINA et sizing).
Connaître les notions de Net + Subnets multi-AZ — un volume est lié à une sous-région.
oapi-cli configuré.

Le BSU en deux phrases

Un volume BSU est un disque virtuel attaché à une VM, comme un disque dur attaché à un serveur physique. Il vit dans une sous-région précise, et seule une VM dans la même sous-région peut l’attacher.

OUTSCALE expose trois types de volumes (standard, gp2, io1) qui se distinguent par leur technologie sous-jacente (magnétique vs SSD), leurs performances en IOPS, et leur prix au GiB. Le bon choix dépend du profil de charge.

Les trois types de volumes

Type	Technologie	Performance	Cas d’usage typique
`standard`	Magnétique (HDD)	Faible IOPS, latence variable	Archives, logs froids, charges peu sensibles à la latence
`gp2`	SSD à performance générale	IOPS proportionnels à la taille du volume	Défaut moderne : bases de données légères, applications web, stockage applicatif général
`io1`	SSD à IOPS provisionnés	IOPS garantis (que vous spécifiez)	Bases de données critiques, charges OLTP, applications sensibles à la latence

`standard` — magnétique économique

Volume magnétique classique. Faible coût au GiB mais IOPS limités et latence imprévisible. À réserver à :

Stockage de logs anciens archivés sur disque local d’une VM.
Volumes secondaires servant de swap ou de cache temporaire non critique.
Charges batch occasionnelles sans contrainte de temps.

`gp2` — SSD à usage général

SSD général qui offre des IOPS proportionnels à la taille du volume. C’est le bon défaut moderne pour la plupart des charges :

Le volume racine des VMs (système et applications).
Les bases de données légères (PostgreSQL, MongoDB sur charge modérée).
Les applications web et API métier standards.

Performance et coût sont équilibrés — pas de surcoût pour la latence stable d’un SSD, et pas besoin de provisionner explicitement les IOPS.

`io1` — SSD à IOPS provisionnés

SSD haut de gamme où vous spécifiez le nombre d’IOPS au moment de la création. Garantit une performance prévisible sur des charges sensibles :

Bases de données OLTP à fort taux de transactions.
Charges critiques où la latence p99 doit rester stable.
Applications financières ou temps réel avec SLA stricts.

Coût plus élevé que gp2, mais justifié quand la prévisibilité de performance est critique.

Limites techniques

Taille maximale d’un volume : 14 901 GiB (~14,5 TiB).
IOPS maximum sur io1 : 13 000 IOPS par volume.
Ratio IOPS/GiB sur io1 : maximum 300 IOPS par GiB. Pour 13 000 IOPS, il faut donc un volume d’au moins 44 GiB.

Calcul des IOPS pour un volume `io1`

La règle du ratio 300 IOPS/GiB est ce qui contraint le sizing d’un volume io1.

Exemple : vous voulez 5 000 IOPS sur une base de données.

IOPS visés : 5 000.
Taille minimale exigée : 5 000 / 300 ≈ 17 GiB. Un volume plus petit ne pourra pas délivrer 5 000 IOPS.
En pratique, on dimensionne souvent un peu au-dessus du minimum pour avoir de la marge de stockage.

Exemple inverse : vous avez un volume de 50 GiB et vous demandez 20 000 IOPS.

Maximum autorisé : 50 × 300 = 15 000 IOPS, mais aussi plafonné à 13 000 IOPS par volume.
L’API rejettera la création — il faudra soit augmenter la taille (au-delà de 44 GiB pour atteindre 13 000), soit accepter une borne plus basse.

Lien fort entre volume et sous-région

Un volume BSU est rattaché à une sous-région au moment de sa création (paramètre SubregionName). Il ne peut être attaché qu’à une VM dans la même sous-région.

Conséquences :

Pas de migration directe d’un volume entre sous-régions — il faut passer par un snapshot que vous pouvez ensuite utiliser pour créer un nouveau volume dans une autre sous-région.
Architecture multi-AZ : pour répartir une base de données sur plusieurs sous-régions, vous créez un volume par sous-région et la réplication se fait au niveau applicatif (replica set MongoDB, streaming replication PostgreSQL, etc.).

Snapshots — sauvegarde et duplication

Un snapshot est une image du contenu d’un volume à un instant T. C’est le mécanisme principal pour :

Sauvegarder un volume avant une opération risquée.
Dupliquer un volume pour créer un environnement à l’identique.
Migrer un volume entre sous-régions ou copier vers une autre région.
Récupérer des données après une suppression accidentelle.

Caractéristiques

Incremental : seuls les blocs modifiés depuis le snapshot précédent sont stockés. Le premier snapshot d’un volume est complet ; les suivants sont rapides.
Stocké hors du volume : un snapshot survit même si le volume d’origine est supprimé.
Source pour créer un nouveau volume : CreateVolume --SnapshotId <snap-xxxxx> produit un volume avec le contenu du snapshot.

Patterns d’usage

Sauvegarde quotidienne : snapshot automatisé tous les soirs sur les volumes critiques (à scripter avec oapi-cli ou Terraform).
Snapshot avant maintenance : avant une mise à jour applicative ou un changement de schéma, un snapshot manuel donne un point de restauration immédiat.
Image dorée : un volume préparé une fois (système + dépendances installés), snapshot, puis création de N volumes identiques pour N nouvelles VMs.

Créer et utiliser un volume BSU via `oapi-cli`

Créer un volume

CreateVolume exige SubregionName (sauf si on part d’un snapshot). Size est requis si pas de snapshot. VolumeType par défaut standard — toujours préciser explicitement pour éviter les défauts non voulus.

# Volume gp2 (SSD général) de 100 GiB en eu-west-2a
oapi-cli CreateVolume \
  --SubregionName "eu-west-2a" \
  --Size 100 \
  --VolumeType "gp2"
# Réponse : VolumeId (par exemple "vol-abc12345")

# Volume io1 (SSD provisionné) de 50 GiB avec 5000 IOPS
oapi-cli CreateVolume \
  --SubregionName "eu-west-2a" \
  --Size 50 \
  --VolumeType "io1" \
  --Iops 5000

Tagger ensuite le volume via CreateTags (env, project, tier, cost-center).

Attacher un volume à une VM

LinkVolume exige VolumeId, VmId et DeviceName. Le DeviceName doit suivre le format /dev/sdX ou /dev/xvdX (où X est entre b et z). Le périphérique racine de la VM est /dev/sda1 (à ne pas réutiliser).

oapi-cli LinkVolume \
  --VolumeId "vol-abc12345" \
  --VmId "i-xxxxxxxx" \
  --DeviceName "/dev/sdb"

Formater et monter le volume côté VM

Une fois attaché, le volume apparaît dans la VM mais doit être formaté et monté (sauf s’il provient d’un snapshot d’un volume déjà formaté).

# Sur la VM, en SSH
sudo lsblk                            # Vérifier que le device est visible
sudo mkfs.ext4 /dev/xvdb              # Formater (uniquement la première fois)
sudo mkdir /data
sudo mount /dev/xvdb /data            # Monter manuellement
echo '/dev/xvdb /data ext4 defaults,nofail 0 2' | sudo tee -a /etc/fstab

L’option nofail dans /etc/fstab évite que la VM soit bloquée au démarrage si le volume n’est pas attaché.

Créer un snapshot

# Snapshot d'un volume existant
oapi-cli CreateSnapshot \
  --VolumeId "vol-abc12345" \
  --Description "Sauvegarde quotidienne app-prod 2026-04-28"
# Réponse : SnapshotId (par exemple "snap-deadbeef")

Tagger le snapshot avec la date et le volume source pour un audit ultérieur.

Restaurer depuis un snapshot

# Créer un nouveau volume depuis un snapshot existant
oapi-cli CreateVolume \
  --SubregionName "eu-west-2a" \
  --SnapshotId "snap-deadbeef" \
  --VolumeType "gp2"
# La taille hérite du snapshot ; le type est librement choisi

Le nouveau volume contient les données du snapshot. L’attacher ensuite à une VM avec LinkVolume.

Bonnes pratiques (par pilier Well-Architected)

1. `gp2` par défaut, `io1` quand justifié — piliers Performance + Cost

Le bon défaut pour la majorité des charges est gp2 : performance SSD honorable sans surcoût d’IOPS provisionnés. Passer en io1 uniquement quand :

vous avez mesuré un besoin d’IOPS qui dépasse ce que gp2 offre ;
la latence p99 doit rester stable sous charge variable ;
le SLA applicatif justifie le surcoût.

Réserver standard aux usages d’archive ou de log froid.

2. Snapshots quotidiens automatisés — pilier Reliability

Toute base de données ou volume critique en production doit avoir un snapshot quotidien automatisé. La règle minimale :

Snapshot quotidien sur les 7 derniers jours.
Snapshot hebdomadaire sur les 4 dernières semaines.
Snapshot mensuel sur les 12 derniers mois.

Cette politique de rétention équilibre profondeur de récupération et coût de stockage.

3. Tester la restauration trimestriellement — pilier Reliability

Un snapshot non testé n’est pas une sauvegarde. Discipline minimale : tester la restauration au moins chaque trimestre :

Créer un volume depuis le snapshot le plus récent.
L’attacher à une VM de test.
Vérifier que les données sont intègres et que l’application redémarre correctement.

Sans ce test, vous découvrirez les problèmes le jour où vous en aurez vraiment besoin.

4. Tagging des snapshots — piliers Operational Excellence + Cost

Un compte qui accumule des snapshots non tagués finit avec des centaines de snapshots dont personne ne sait à quoi ils servent, et qu’on n’ose pas supprimer. Discipline : taguer immédiatement chaque snapshot avec :

Date de création dans Description.
Volume source ou base de données d’origine.
env, project, cost-center.

Cela permet le cleanup automatisé des snapshots anciens et l’imputation FinOps.

5. Volume root séparé du volume data — pilier Operational Excellence

Pour les bases de données et applications avec données persistantes, séparer :

Le volume racine (/dev/sda1) qui contient l’OS et l’application — petit, sans données métier critiques, recréable depuis l’OMI.
Un volume data (/dev/sdb) attaché à un point de montage applicatif (/data) — celui qui contient les données et qui est sauvegardé.

Cette séparation simplifie les mises à jour OS (recréer la VM avec une OMI à jour, réattacher le volume data) et la gestion du cycle de vie des données.

6. Right-sizing des volumes — pilier Cost

Comme pour les VMs, un volume sur-dimensionné par inertie coûte cher inutilement. Audit régulier (par exemple trimestriel) :

Volumes non attachés depuis longtemps → candidat à la suppression (après vérification).
Volumes largement sous-utilisés (par exemple 1 To utilisés sur 5 To provisionnés) → migrer vers une taille plus juste si possible.
Volumes io1 dont les IOPS provisionnés sont bien supérieurs à la consommation réelle → revenir à gp2.

Antipatterns à éviter

Antipattern	Conséquence	Discipline correcte
`io1` partout par sécurité	Surcoût important sans bénéfice	`gp2` par défaut, `io1` uniquement quand mesuré nécessaire
Snapshots manuels uniquement	Oublis, données perdues lors d’un incident	Snapshots automatisés + politique de rétention
Snapshots non testés en restauration	Découverte tardive d’un problème	Test trimestriel de restauration
Snapshots sans tags	Impossibilité de faire le ménage	Tagging dès la création
Volume root et data confondus	Mise à jour OS difficile, sauvegardes compliquées	Volume root + volume data séparés
Volume oublié non attaché	Coût mensuel pour rien	Audit régulier des volumes orphelins
`pas de nofail` dans `/etc/fstab`	VM bloquée au démarrage si volume détaché	Toujours `nofail` pour les volumes secondaires

BSU sous l’angle Well-Architected

Reliability — durabilité et restauration

Le BSU contribue au pilier Reliability par deux mécanismes :

Durabilité du stockage — les volumes sont gérés par OUTSCALE en haute disponibilité au sein d’une sous-région, ce qui protège contre les pannes individuelles de disque.
Snapshots — le mécanisme central pour la continuité : sauvegarde régulière, restauration testée, point de récupération avant toute opération risquée.

Les questions clés du pilier Reliability adressées par le BSU :

Que se passe-t-il si un volume est corrompu ? — restauration depuis le dernier snapshot.
Combien de temps pour revenir en marche après une perte ? — RTO mesuré sur un test trimestriel de restauration.
Combien de données peut-on perdre dans le pire cas ? — RPO = fréquence des snapshots automatisés.

Performance — IOPS adaptés

Le pilier Performance sur le BSU se joue principalement sur le choix du type et le sizing des IOPS :

standard accepte la latence — bon pour les charges occasionnelles.
gp2 offre une performance SSD prévisible adaptée à la majorité des cas.
io1 permet de garantir un seuil d’IOPS pour des charges sensibles.

Le sizing doit être basé sur des mesures réelles (taux d’IOPS observé sur la VM via iostat, iotop ou métriques applicatives), pas sur des estimations.

Cost Optimization — type et taille bien choisis

Le pilier Cost sur le BSU repose sur trois leviers :

Choix du type — pas de io1 quand gp2 suffit, pas de gp2 quand standard suffit pour des archives.
Sizing juste — pas de volume de 1 To quand 200 GiB suffisent.
Cycle de vie — supprimer les volumes orphelins, faire le ménage des snapshots anciens.

À retenir

Le BSU est le stockage bloc d’OUTSCALE, équivalent EBS, attaché à une sous-région précise.
Trois types : standard (magnétique économique), gp2 (SSD général, défaut moderne), io1 (SSD à IOPS provisionnés, max 13 000 IOPS, ratio 300 IOPS/GiB).
Taille maximale d’un volume : 14 901 GiB.
Les snapshots sont incrémentaux, stockés hors du volume, source pour créer de nouveaux volumes.
Snapshots quotidiens automatisés + test trimestriel de restauration sont la base de toute stratégie de sauvegarde.
nofail dans /etc/fstab évite que la VM soit bloquée au boot si le volume n’est pas attaché.
Volume root et volume data séparés simplifient les mises à jour OS et la gestion des données.

Prochaines étapes

Stockage — OOS, versioning, lifecycle Le stockage objet S3-compatible pour archives, médias, exports, backups.

Sauvegardes — RPO/RTO/PRA Stratégie de sauvegarde 3-2-1, politiques de rétention, plan de reprise.

Calcul — instances TINA et sizing Choisir le bon type de VM auquel attacher les volumes.

Outils CLI OUTSCALE oapi-cli pour scripter la création de volumes et de snapshots.