Назад | Перейти на главную страницу

Снимки состояния AWS EC2 - как долго они должны храниться?

Как долго следует хранить ежедневные снимки состояния EC2, поддерживаемые EBS? Мы используем ec2-автоматизация резервного копирования для резервного копирования (ежедневно) двух томов EBS - ОС и данных - относящихся к веб-приложению. Если я понял, в случае сбоя мы могли бы создать новые экземпляры из самых последних снимков.

Однако я считаю, что эти снимки являются инкрементными, и хотя каждый из них указан (в консоли AWS) и имеет размер, равный размеру тома EBS, из которого они были созданы, я думаю, что они просто записывают изменения, это правильно ?

Это определенно то, где мое понимание снимков падает, поскольку я не понимаю, как, если мы удалим старые снимки, мы сможем быть уверены в сохранении всех необходимых данных, и поэтому я не знаю, как долго мы должны держаться за эти снимки. .

ОБНОВИТЬ Несколько мгновений спустя я обнаружил этот, что наводит на мысль, что я могу безнаказанно удалить буквально все, кроме самых последних. Если это так и кажется, что это может быть полезно для других, я могу ответить на этот вопрос сам, или, если это слишком очевидно, не стесняйтесь закрыть это.

Я могу безнаказанно удалить буквально все, кроме самых последних

Предполагая, что вам не нужны данные, которые уже были удалены или перезаписаны на томе, когда вы сделали последний снимок, это правда.

Снимки EBS логически инкрементальный - нет физически инкрементальный. Вот умение, объясняющее разницу:

Моментальные снимки томов EBS технически не содержат данных ... они содержат списки указателей на резервные копии блоков данных, которые EBS хранит в S3 от вашего имени (и выставляет вам счет за хранение). При каждом новом снимке, если на томе встречаются блоки, которые не изменились по сравнению с предыдущим снимком и, таким образом, уже сохранены в S3 с тем же содержимым, они больше не сохраняются - новый снимок просто ссылается на блоки, уже сохраненные другим. работа с моментальным снимком ... вот почему у вас, вероятно, нет диковинного счета за хранение.

Это то, что я имею в виду под «логически» инкрементальным. Новые (с момента последнего снимка) измененные блоки сохраняются в S3, но на самом деле они не находятся «в» последнем снимке - они ссылаются на него и на любой будущий снимок, сделанный до тех пор, пока они не изменятся.

Моментальные снимки EBS полностью независимы от файловой системы. Они понятия не имеют о как блоки используются, только то, что они менялись между снимками. Моментальные снимки представляют собой операцию на уровне блоков (не на уровне файлов), поэтому, независимо от степени детализации блоков, ¹ если была изменена только часть большого файла на месте (без перемещения файла на диск), то только измененный часть файла будет создана заново. (Простым примером может быть постоянно растущий файл журнала).

Когда вы удаляете снимки, блоки, на которые ссылаются эти снимки, удаляются из хранилища S3 (прекращая выставление счетов за хранение этих блоков) если и только если никакие другие снимки не ссылаются на них. В противном случае, конечно, они сохраняются, потому что они еще нужны.

Если вы удалите все, кроме самого последнего снимка, все блоки, хранящиеся в S3, которые не нужны для восстановления этого единственного снимка, будут очищены, поэтому размер вашего оплачиваемого хранилища моментальных снимков будет точно равен размеру тома, потому что только эти блоки останутся в хранилище S3. (Технически он должен быть меньше, поскольку EBS, по-видимому, использует алгоритм обратимого сжатия для моментальных снимков, но подробности не являются общедоступными, но, в принципе, том 8 ГБ с ровно одним снимком ссылается ровно на 8 ГБ блоков моментальных снимков).

Вот почему размеры моментальных снимков всегда показывают размер тома в консоли и API, а не какой-то «инкрементный» размер - снимок не «содержит» никаких данных, но содержит указатели на ровно столько блоков данных резервного копирования, чтобы заполнить том с содержимым, идентичным тому, что существовало на томе при запуске задания моментального снимка. И вот тут-то и проявляется ваша «безнаказанность».

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

Из-за риска удаления, перезаписи файлов и т. Д. В течение некоторого периода времени до того, как проблема может быть замечена ... кажется разумным оставить более одного дня, но это рассуждение не связано с тем, как работают моментальные снимки EBS.

Моя политика, реализованная с помощью внутренней автоматизации, заключается в том, чтобы ежедневно хранить моментальные снимки в течение нескольких дней, сокращая их до еженедельного хранения моментальных снимков в течение нескольких недель и, наконец, сохранять ежемесячный моментальный снимок для каждого тома навсегда или меньше, в зависимости от срока хранения. политики. (Моя автоматизация использует "волшебные" теги на томах, чтобы настроить срок хранения и время на уровне тома, но эта политика по умолчанию используется на большинстве томов.)

Кстати, говоря о S3, вероятно, стоит уточнить, что EBS является «клиентом» S3 в этой настройке, а не вы - вот почему вы не можете видеть эти данные резервного копирования в S3.


¹ "независимо от степени детализации блоков" - Под этим я подразумеваю размер «резервного блока» с точки зрения EBS. Этот размер, насколько мне известно, недокументирован, но я предполагаю, что «блок» в этом контексте почти наверняка больше, чем «размер блока» устройства, представленного операционной системе, поскольку размер резервного блока составляет однозначный KiB приведет к неуклюже большому число блоков для манипулирования, отслеживания, хранения и перезагрузки.