Résumé

  • Fly.io documente une fenêtre de 24 heures pour retrouver l’identifiant d’un volume supprimé. Un identifiant déjà conservé permet ensuite de rechercher ses snapshots tant qu’ils sont retenus.
  • Les snapshots sont gardés cinq jours par défaut, avec un réglage possible de un à soixante jours. Modifier ce réglage ne change pas la durée des snapshots existants.
  • Le retrait d’une ressource doit transmettre ses références et les échéances réelles de ses copies. La fin de la facturation du volume ne clôt pas automatiquement la conservation des snapshots.

Soixante jours, mais pour qui ?

Un réglage peut afficher une excellente nouvelle sans changer le sort des données que l’on cherche à sauver. Chez Fly.io, augmenter la rétention des snapshots profite aux nouveaux snapshots. Les anciens gardent leur durée d’origine.

Le détail est petit ; la décision qu’il commande l’est moins. Une équipe qui prépare la fermeture d’un service peut croire avoir acheté du temps en remplaçant cinq jours par soixante. Pour les copies déjà prises, le calendrier reste celui d’hier. La politique affichée décrit la production future. Elle ne rallonge pas le passé.

Une seconde horloge complique le départ. La documentation de récupération d’un volume supprimé indique que son identifiant peut être retrouvé pendant 24 heures après suppression. Si l’équipe l’a conservé, elle peut continuer à l’utiliser pour rechercher les snapshots dans leur période de rétention. Les données peuvent donc rester disponibles alors que la voie ordinaire pour retrouver leur référence s’est déjà refermée.

Le service conserve la boîte. Il vaut mieux garder l’étiquette.

Trois objets, trois fins possibles

Un Fly Volume est un stockage local persistant lié à une machine physique. Lorsqu’un client le détruit, il passe dans l’état pending_destroy pendant 24 heures avant suppression définitive. Lors d’une migration vers un autre hôte effectuée par Fly.io, l’ancien volume reste dans cet état pendant une semaine. Le déclencheur compte : la semaine du déménagement technique n’est pas un délai supplémentaire offert à toute suppression client.

Le snapshot a sa propre vie. Les captures quotidiennes automatiques sont activées par défaut ; leur rétention par défaut est de cinq jours et peut être réglée de un à soixante jours. Supprimer le volume ne donne pas cinq jours neufs aux copies déjà vieillissantes.

La récupération documentée consiste à utiliser l’identifiant du volume, à choisir un snapshot encore conservé et à créer un nouveau volume de taille au moins égale. L’ancienne ressource, sa référence retrouvable et la copie de son contenu ne sont donc pas trois noms pour un même objet.

Cette distinction protège aussi contre une autre facilité : prendre un accusé de programmation pour une copie finie. Une capture demandée passe par les états d’attente, d’exécution puis de création. Pour organiser une fermeture, il faut connaître celle qui a effectivement abouti. Une promesse en cours de fabrication fait une sortie de secours médiocre.

Le ménage a deux comptabilités

Fly.io facture les volumes au prorata horaire, y compris lorsqu’ils ne sont attachés à aucune Machine ou lorsque la Machine est arrêtée. Un volume dans l’état pending_destroy ne produit plus de frais de volume. Le stockage des snapshots est facturé séparément, au prorata horaire après déduction de la franchise, sur la base des données incrémentales conservées.

L’équipe peut donc arrêter un poste de coût tout en conservant une possibilité de récupération assortie de son propre stockage. Désactiver les prochaines captures quotidiennes ne supprime pas les anciennes : elles arrivent à leur échéance habituelle.

Ce fonctionnement appelle un choix explicite, pas une conservation éternelle par peur. Combien de temps le métier souhaite-t-il garder une marche arrière ? Quelle copie réelle couvre cette période ? Qui pourra la retrouver et l’utiliser ? Une réponse documentée permet de fermer les ressources et les coûts au moment voulu.

Sans ce relais, le nettoyage risque de récompenser la mauvaise mesure. La liste des volumes devient impeccable, tandis qu’une autre personne hérite de données encore stockées mais de références éparpillées. Le fournisseur vend du temps de conservation ; l’organisation doit laisser ce temps entre les mains de quelqu’un qui saura s’en servir.

Une référence n’est pas une clé universelle

Le petit dossier utile relie le volume à son application et à son organisation, conserve l’identifiant du snapshot retenu, sa date de capture, son état et sa durée réelle. Il doit rester accessible aux personnes autorisées à restaurer après la disparition de la ressource courante.

L’identifiant sert à localiser. L’accès reste soumis aux droits du compte, et une référence exacte ne démontre pas que les données répondront aux besoins de l’application. Créer le nouveau volume laisse encore le rattachement, le redémarrage et les vérifications métier à réaliser. Le délai de récupération doit englober ce travail.

Les captures quotidiennes peuvent en outre manquer les écritures postérieures à la dernière prise. Une rétention plus longue conserve davantage de passé ; elle n’ajoute pas les transactions qui n’ont jamais été capturées. Les choix de fréquence et de durée répondent à deux besoins différents.

La documentation ne fournit pas de garantie de récupération par le support lorsque l’identifiant n’a pas été conservé ; une telle garantie changerait le coût du risque. Le chemin public suffit à justifier la conservation des références avant le retrait du volume.

Le dernier fichier utile est parfois une ligne

L’identité du fournisseur peut être vérifiée dans le registre des membres du RIPE NCC, qui nomme Fly.io, Inc. Ce registre ne localise pas le volume d’un client. Une adresse d’entreprise, une région d’exécution et un identifiant de récupération répondent chacun à leur question. Les ranger ensemble ne les rend pas interchangeables.

Le point commercial est là : posséder une copie et disposer d’une option de retour utilisable exigent des éléments différents. Contenu survivant, référence survivante et autorisation doivent se rejoindre avant l’échéance.

Le départ mérite donc autant de soin que l’arrivée. Au lancement, la plateforme remet volontiers noms, états et coordonnées. À la fermeture, l’entreprise doit décider ce qu’elle transmet au prochain responsable. Quelques lignes peuvent protéger la valeur des jours déjà payés. Les oublier ne réduit pas la taille du snapshot ; cela réduit les chances de s’en servir à temps.

Sources officielles