Я не думаю, что вы найдете подробную документацию о том, как реализованы снимки; это не то, с чем я сталкивался. У них есть документация для «Затраты на проектирование». Однако, я думаю, если вы знаете, как это работает, вы можете интуитивно понять счет и почувствовать себя более комфортно с ним.
Обратите внимание, что эти снимки не"инкрементны", как мы, возможно, поняли этот термин в операционной системе DOS. В DOS бит «архив» был установлен при изменении файла, а «инкрементная» резервная копия копировала только те файлы, для которых был установлен бит «архив». В процессе резервного копирования атрибут архива будет очищен, поэтому при дальнейшем редактировании файла его резервное копирование будет выполняться «постепенно».
При создании снимков каждый блок тома помечается, если он изменяется. Это не делается для каждого файла отдельно. После первого снимка резервное копирование выполняется только для блоков, помеченных как измененные, точно так же, как «инкрементные» резервные копии в DOS. Но на этом сходство заканчивается, потому что с каждым блоком , который ему не нужно копировать , он не просто пропускает его, он записывает указатель на то, где находится последняя (неизмененная) копия данных.
Первый снимок, который вы делаете для тома, данные разбиты на блоки. Из Amazon: « Данные тома разбиваются на куски перед их передачей в Amazon S3. Хотя размер кусков может измениться в результате будущих оптимизаций, число [...] можно оценить путем деления размера данных который изменился с момента последнего снимка на 4 МБ."
Следующий сделанный вами снимок состоит из данных только для тех блоков, которые изменились, и указателей на блоки, которые не изменились. Эти указатели указывают на блоки данных в предыдущем снимке.
Следующий снимок (n) создается путем записи данных каждого блока, измененного с момента предыдущего снимка (n-1), а также указателей для блоков, которые не изменились с момента предыдущего снимка (n-1). Эти указатели указывают на соответствующие блоки в предыдущем снимке, которые могут содержать данные, или другой указатель на его предыдущий снимок. В конце концов, каждый указатель заканчивается блоком реальных данных (который не изменился с момента создания этого снимка).
Теперь предположим, что вы решили удалить снимок (x). Снимок (x) имеет снимки, сделанные до (x-1) и после него (x + 1). Amazon заменяет указатели в снимке (x + 1) указателями и данными из снимка (x) (удаляемого). В результате любые фактические данные в моментальном снимке (x) копируются в моментальный снимок (x + 1), если в нем нет собственной копии более свежих данных для этого блока.
Вот как работают снимки, где хранятся данные, и почему размер снимков является управляемым. Отсюда вы можете понять, что удаление снимка уничтожит только вашу способность вернуть том, каким он был в тот момент, когда был создан этот снимок, без ущерба для возможности использования других снимков. В отличие от простых, традиционных «инкрементных» резервных копий, в которых не используются указатели, снимки, которые не удаляются, обновляются по мере необходимости, чтобы сохранять свою полезность при удалении одного из его зависимых снимков. Вот почему имеет смысл, что Amazon платит больше за интеллектуальное хранение снимков, чем за простые копии томов EBS. Наконец, понятно, что трудно предсказать, сколько будет стоить хранилище снимков, так как оно очень динамично.