Summary

  • Fly.io documents a 24-hour window for retrieving a deleted volume’s ID. A known ID can still locate that volume’s snapshots while their retention lasts.
  • Automatic daily snapshots default to five days of retention, configurable from one to 60. Deleting a volume does not restart a snapshot’s clock; retention changes apply to new snapshots.
  • Volume charges stop in pending_destroy. Snapshot storage is billed separately, and restoring a snapshot creates a new volume that still needs to become a working application.

Cloud housekeeping has an excellent closing scene: the unused disk disappears, the expense stops, and somebody gets to mark the ticket done. Fly.io’s documentation supplies a less cinematic postscript. Keep the volume ID. After deletion, customers have 24 hours to retrieve that identifier. The snapshots may outlive the lookup window.

That is a peculiar arrangement for an asset bought partly to rescue people from mistakes. The copy can remain on the shelf after the convenient route to finding its shelf number closes. Fly.io documents how to find retained snapshots using a known volume ID. The customer who kept the number therefore has something operationally useful that the customer who merely remembers buying backups may lack.

The important purchase is an exercisable recovery option. Storage preserves the material. A reference, access and an executable procedure turn it into an option someone can actually use. A short line in an inventory can have more immediate value than another reassuring slide about resilience.

The receipt has a shorter office hour

The 24-hour rule appears in Fly.io’s volume-management documentation. It concerns retrieving the deleted volume’s ID. With the ID already in hand, the documented path to its snapshots remains available for their remaining retention period. Treating the first deadline as a universal end to recovery would misread the arrangement just as badly as ignoring it.

The identifier is a locator. It does not confer permission, prove that a snapshot contains every desired write, or start the application. A usable retirement record connects the ID to the application, the relevant snapshots, their capture times and the person authorised to restore them. That record needs a life independent of the volume being removed.

The public documents reviewed here offer no support-assisted recovery guarantee for customers who have lost the ID; such a guarantee would change the risk of relying on help after the lookup window. The documented customer-controlled route gives the inventory a deadline.

This is where the usual division of labour can become expensive. The person deleting an idle resource is rewarded for ending an expense. The person recovering it later needs context, permissions and references. “Deleted successfully” is a perfectly good answer to the first person’s question and an incomplete handover to the second.

Five days are already ticking

Automatic daily snapshots are enabled by default. Their default retention is five days, with settings from one to 60 days. Those numbers describe the lives of snapshots. Deleting the original volume does not award every surviving copy a fresh five-day holiday.

A snapshot has already aged by the time someone deletes its volume. Its remaining life, rather than the policy’s headline number, determines how much room the recovery team has. The date on the actual copy matters more than the administrator’s memory of the default.

Changing retention also leaves existing snapshots on their previous schedules. Consider a hypothetical change from five to 60 days. Future snapshots can receive the longer retention; older ones keep their earlier expiry. A configuration screen showing 60 days can therefore coexist quite legitimately with a useful copy nearing the end of its five-day life. The setting expresses future policy. The inventory describes the rescue material available now.

Fly Launch configuration has its own scope: changes governing new volumes created during deployment should be read as changes for those new volumes. They do not rewrite the history of every existing resource. An administrator can have the right intention, the right new setting and the wrong assumption about the old estate, all at once.

Turning off automatic snapshots leaves existing copies to expire on their own schedules. It stops future production; it does not instantly sweep the shelves. Here again, the policy switch and the stock of stored objects are different things.

A request is an optimistic piece of paper

An on-demand snapshot moves through waiting, running and created. The distinction becomes awkward only if somebody schedules deletion as though submitting the request had already produced a completed copy. A successful request is evidence that work was requested. The completed state is the more interesting receipt.

Recovery then creates a new volume of equal or greater size. Attaching it, starting the application and checking the business data remain work for the operator. The snapshot is an input to recovery, with a date and a state; the restored service is an outcome.

Long retention cannot improve the freshness of the last capture. Daily snapshots may miss writes made since that capture. Keeping a longer history and reducing the amount of recent work at risk are separate purchasing and engineering decisions. A company can buy plenty of the former while leaving the latter unresolved.

Fly.io’s volume architecture adds concrete constraints to that calculation. Volumes live on local hardware, with the documented one-Machine, one-volume relationship. Forking a volume produces an independent copy; the act of forking does not establish continuing synchronisation. These details determine what must be reconstructed. The comforting noun “backup” supplies none of them by itself.

Borrowing a week from the wrong procedure

The volume-state documentation contains a week-long retention period that deserves to stay in its own paragraph. When a user destroys a volume, it remains in pending_destroy for 24 hours before permanent destruction. When Fly.io migrates a volume between hosts, the platform retains the old source volume in that state for a week.

That week belongs to the provider’s migration procedure. Moving it into a customer-deletion plan manufactures an extra recovery entitlement. The state name is shared; the reason, duration and surrounding operation differ. Documentation can reuse a label more safely than a recovery plan can reuse its longest number.

There are consequently several clocks to track: the lookup window for the ID, the original volume’s destruction process and the remaining retention of each snapshot. Their overlap does not produce a single universal grace period. Whoever approves deletion needs to know which clock the proposed escape route uses.

The expense stops in instalments

Volume storage is charged proportionally by the hour, including for unattached volumes and when a Machine is stopped. In pending_destroy, volume charges cease. Deletion can therefore end an expense that merely stopping compute would leave behind.

Snapshot storage has separate hourly prorating after the applicable free allowance. Snapshots are incremental, reflecting changed data. Neither multiplying the nominal volume size by every snapshot nor assuming the whole account becomes free captures that arrangement. The precise financial point is simpler: ending volume charges and ending every charge for retained copies are different events.

The remaining storage expense buys time to change one’s mind. Keeping the identifier helps preserve a documented way to act on that change of mind. Paying for a copy while discarding its reference is an impressively modern form of renting a fire escape and mislaying the address.

RIPE NCC’s primary membership record identifies the organisation as Fly.io, Inc. It anchors the company identity here; Fly.io’s own operational documents supply the storage and billing rules. A membership address does not locate customer data. For the retirement decision, the more immediately valuable address is the one that leads back to the surviving snapshot.

Primary sources