🇫🇷 Storage Systems — Chapitre 23 : Scaleway Storage

lsblk
sudo mkfs.xfs /dev/sdb
sudo mkdir -p /data
sudo mount /dev/sdb /data
df -h /data
iostat -x 1

# After resize
sudo growpart /dev/sdb 1
sudo xfs_growfs /data

• Séparer OS, data, logs et backups.
• Nommer volumes : app-env-role-index.
• Tags owner, env, data_class, backup_policy.
• Snapshots avant opérations risquées.
• Restore drill avant production.

• Backup souverain : restic/borg/rclone/Veeam vers S3.
• Assets web : images, documents, vidéos.
• Data lake : raw/curated Parquet/JSON.
• Logs : compression quotidienne + lifecycle.
• Artefacts CI/CD : builds, releases, ML models.

aws --endpoint-url https://s3.fr-par.scw.cloud s3 ls
aws --endpoint-url https://s3.fr-par.scw.cloud s3 cp backup.tar.gz s3://my-bucket/backups/
rclone sync ./data scaleway:my-bucket/data --progress
mc alias set scw https://s3.fr-par.scw.cloud ACCESS_KEY SECRET_KEY
mc ls scw/my-bucket

C14 Cold Storage est l’ancienne identité produit autour du stockage froid Scaleway. Les documents Scaleway expliquent que Glacier est désormais une classe de stockage d’Object Storage, intégrée au lifecycle management et accessible via API S3-compatible.

1. Classer les données par température et obligation.
2. Compresser et chiffrer si nécessaire.
3. Créer manifest, checksums, owner, date, rétention.
4. Appliquer lifecycle vers Glacier.
5. Tester restauration sur échantillon.
6. Documenter délai et procédure.

• Block Storage si un seul serveur/pod écrit.
• Object Storage si l’application accepte API objet.
• NFS autogéré si besoin très spécifique.
• Kubernetes storage open-source si cluster dédié.

• Valider statut du service et SLA.
• Tester metadata performance.
• Définir UID/GID/permissions.
• Prévoir backup hors file storage.
• Surveiller capacité et latence.

• Catalogue moins vaste que AWS/Azure/GCP.
• Services enterprise parfois moins profonds.
• Disponibilité des features selon région.
• Besoin de valider SLA/support pour production critique.
• Écosystème partenaires plus restreint que les hyperscalers.

• Chiffrement fort et gouvernance des clés.
• Segmentation réseau et bastions.
• Logs d’accès exhaustifs.
• Backups immuables et DR testés.
• Conformité contractuelle et audit régulier.
• Observabilité sécurité et exploitation 24/7.

• Choisir région par souveraineté/latence.
• Réseaux privés pour flux internes.
• Object Storage pour backups hors instance.
• Terraform pour reproductibilité.

fio --name=scw-block --filename=/data/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --direct=1 --runtime=120 --time_based --group_reporting
rclone copy ./bench scaleway:bucket/bench --progress
iostat -x 1

• Tester dans la région cible.
• Tester workload réel, pas uniquement fio.
• Mesurer p95/p99 latence.
• Valider coût/perf avec instance choisie.

Do not store:
- S3 access key in Git
- database password in Docker image
- backup key on the same server
- admin credentials in CI logs

Use:
- environment secrets
- vault/secrets manager
- short-lived credentials where possible
- separate backup credentials

1. Choisir une application.
2. Restaurer VM/volume/DB dans environnement isolé.
3. Vérifier cohérence métier.
4. Mesurer RTO/RPO.
5. Corriger runbook.

• Définir par application, pas globalement.
• Tester restore base + fichiers + secrets.
• Prévoir DNS et réseau.
• Documenter ordre de redémarrage.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-postgres
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: scw-bssd
  resources:
    requests:
      storage: 100Gi

• PVC sans restore testé.
• Volume bloc utilisé comme RWX.
• Snapshots non cohérents DB.
• Bucket S3 utilisé comme filesystem transactionnel.

• WAL/binlog archiving.
• Backups natifs DB.
• Snapshots seulement en complément.
• Monitoring fsync/latency.
• PITR testé.

• Datasets en Object Storage.
• Cache local rapide pour training.
• Versionner modèles et datasets.
• Lifecycle pour vieux checkpoints.
• Chiffrement pour données sensibles.

Le positionnement français/européen est stratégique pour des datasets sensibles, santé, recherche, secteur public ou industrie.

1. Inventaire données et dépendances.
2. Choix cible : block/file/object/archive.
3. Transfert initial.
4. Sync delta.
5. Cutover.
6. Validation checksum/performance.
7. Rollback temporaire.

Standardiser endpoints, variables, secrets et modules Terraform pour éviter une infra manuelle impossible à auditer.

• Minimisation.
• Chiffrement.
• Journalisation.
• Rétention.
• Droits d’accès.
• Suppression vérifiable.

• Tags owner/app/env.
• Budgets par projet.
• Lifecycle object.
• Expiration snapshots.
• Stop GPU hors jobs.
• Revue ressources orphelines.

• Volume > 80/90/95%.
• Backup failed.
• Bucket public.
• Snapshot trop ancien.
• GPU running idle.
• Coût anormal.

Combiner monitoring Scaleway, Prometheus, logs applicatifs, checks backup, scripts FinOps et alertes externes.

• Scaleway : souveraineté française, dev, Kubernetes, IA.
• OVHcloud : private cloud, hébergement, bare metal, souveraineté EU.
• Hyperscalers : catalogue PaaS/data/IA massif.

• Buckets sans owner.
• Volumes unattached.
• GPU idle.
• Backups sur même serveur.
• Restauration jamais testée.

1. Vérifier endpoint/région.
2. Vérifier access key/secret.
3. Vérifier bucket policy.
4. Tester awscli/rclone/mc.
5. Rotation si fuite suspectée.

1. Identifier objet/version.
2. Lancer restore depuis Glacier.
3. Attendre disponibilité.
4. Copier vers Standard si besoin.
5. Vérifier checksum.

1. kubectl describe pvc.
2. Vérifier StorageClass.
3. Vérifier quota/projet.
4. Vérifier CSI logs.
5. Tester volume manuel.

• Buckets non publics par défaut.
• Secrets hors Git.
• Backup isolé.
• Chiffrement applicatif si données sensibles.
• Logs accès et alertes.