Кратко

  • Fly.io позволяет получить идентификатор удалённого тома в течение 24 часов после удаления. С уже известным ID можно искать его снимки, пока не закончился срок их хранения.
  • Автоматические ежедневные снимки включены по умолчанию и обычно хранятся пять дней. Допустимый диапазон — от одного до 60 дней; изменение действует на новые снимки.
  • В состоянии pending_destroy плата за том прекращается. Хранение снимков оплачивается отдельно, а восстановление создаёт новый том, который ещё нужно подключить и проверить в работе.

Самый дешёвый предмет в плане восстановления может оказаться самым неудобным для повторного получения. У Fly.io это идентификатор тома. Содержимое измеряется гигабайтами, расходы — часами, а ссылка на спасательную копию помещается в короткой записи. Тем не менее именно у этой записи есть собственный срок удобного поиска: 24 часа после удаления тома.

Снимки при этом могут продолжать существовать. Документация разрешает искать снимки удалённого тома по известному ID, пока остаётся срок их хранения. Получается вполне рыночный парадокс: клиент сохраняет оплачиваемую возможность восстановить данные, но для её использования должен вовремя забрать номерок. Гардероб работает, окно выдачи потерянных номерков уже закрыто.

У каждой вещи свой срок

В обычной конфигурации Fly.io делает автоматические снимки ежедневно и хранит их пять дней. Срок можно установить в пределах от одного до 60 дней. Эти цифры легко собрать в красивое обещание, которого система не давала: удалим том, а потом у нас будет ещё пять дней на раздумья.

Возраст снимка не обнуляется при удалении исходного тома. В распоряжении остаётся его собственный остаточный срок. Если нужная версия уже давно лежит в хранилище, времени после удаления будет соответственно меньше. Решение нужно принимать по существующему снимку и его датам, а не по общему названию политики.

Повышение срока хранения тоже не омолаживает старые копии. Допустим, команда меняет настройку с пяти на 60 дней. Это условный пример: новые снимки будут создаваться по новой политике, а ранее созданные сохранят прежние сроки. Число 60 на экране ещё ничего не говорит о том, сколько проживёт конкретная старая копия. Для этого нужен её собственный учёт.

С настройками Fly Launch действует похожая дисциплина чтения: правило, применяемое к новым томам при развёртывании, не переписывает автоматически свойства всего старого хозяйства. У администратора есть намерение, выраженное в конфигурации, и есть фактический набор объектов. Во время восстановления важен второй.

Запрос на копию — ещё не копия

Для снимка по требованию предусмотрены состояния waiting, running и created. Между первым запросом и последним состоянием идёт работа. Удалять исходный ресурс по одному факту отправки запроса — значит поставить хозяйственную аккуратность впереди готовности восстановиться.

Готовый снимок тоже не равен работающему приложению. При восстановлении создаётся новый том, равный исходному по размеру или больше. Затем его нужно подключить, запустить приложение и проверить, что нужные данные действительно доступны. Система хранения возвращает материал для работы; бизнесу ещё требуется вернуть саму работу.

ID участвует в этом процессе как указатель. Он не заменяет полномочия доступа, не доказывает полноту копии и не выдаёт права своему случайному обладателю. Полезная запись связывает идентификатор с приложением, снимком, временем создания и ответственным за восстановление. Такой набор должен пережить удаляемый ресурс. Иначе каталог аварийного выхода уезжает в мусор вместе с дверью.

В изученных открытых документах нет гарантии восстановления через поддержку при утерянном ID; появление такой гарантии изменило бы оценку зависимости от помощи после 24 часов. Пока документированный маршрут опирается на заранее сохранённый идентификатор и ещё существующие снимки.

Неделя из чужого сценария

В описании жизненного цикла томов есть и недельный срок, но он относится к другой операции. Пользовательское удаление переводит том в pending_destroy на 24 часа, после чего следует окончательное уничтожение. При переносе между хостами сама платформа удерживает исходный том в таком состоянии неделю.

Из недельного запаса при миграции нельзя составить недельную гарантию отмены клиентского удаления. Совпадение названия состояния не делает одинаковыми причины перехода и правила выхода. Это мелкая разница для беглого чтения и крупная для человека, который строит календарь восстановления.

Три временные линии поэтому надо вести отдельно: возможность получить ID удалённого тома, судьба самого тома и сроки каждого снимка. Они соприкасаются, но не превращаются в один общий льготный период. Если план восстановления написан одним словом «неделя», в нём ещё не выполнена самая полезная часть работы.

Счёт закончился не весь

За том Fly.io взимает пропорциональную почасовую плату, даже когда он отсоединён или связанная машина остановлена. В pending_destroy плата именно за том прекращается. Это даёт реальный стимул убирать ненужные ресурсы: выключенная машина не обязательно решает вопрос расходов на диск.

У снимков отдельный учёт хранения, также пропорциональный часам после применимой бесплатной квоты. Снимки инкрементальные: учитываются изменившиеся данные. Поэтому механическое умножение размера тома на число снимков не описывает их фактический объём, а прекращение платы за том не означает нулевой счёт за всё оставшееся хозяйство.

Оставшиеся расходы покупают дополнительное время выбора. Если позже понадобится вернуться к данным, копия ещё может оказаться доступной. Но опцион требует способа исполнения. Потерять ссылку на оплачиваемую копию — значит ухудшить полезность того, за что организация продолжает платить.

Долгая история не покупает свежести. Ежедневные снимки могут не содержать записи, сделанные после последней съёмки. А архитектура томов остаётся локальной: они привязаны к физическому оборудованию, приложение работает в рамках указанной связи тома с Machine. Создание fork даёт независимую копию; само действие не включает постоянную синхронизацию. Правильный выбор защиты начинается с того, сколько новых записей бизнес может потерять и как быстро способен вернуть приложение.

Первичный реестр RIPE NCC подтверждает организационную идентичность Fly.io, Inc. Операционные сроки взяты из собственных документов Fly.io; запись о членстве не устанавливает местонахождение клиентских данных. Для этой истории география уступает место учёту: важнее знать, где записан ID и сколько ещё живёт нужный снимок.

Первичные источники