Моментальные снимки диска GCP: потеря полного моментального снимка сделает инкрементные моментальные снимки бесполезными?

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

Что произойдет, если моментальный снимок выйдет из строя таким образом, что этот процесс не произойдет? Если первый снимок каким-то образом будет удален или поврежден, а данные не будут переданы второму снимку, сделает ли это все последующие снимки непригодными для использования, или GCP теперь будет обращаться к исходному диску и создавать первый снимок заново или просто делать новый полный снимок?

Если и исходный диск, и полный снимок каким-то образом будут повреждены, будет ли вам просто ужасно не повезло, если вы вообще не сможете восстановить диск?

Если только Google не выпустит фактический исходный код программного обеспечения и алгоритмы для своего программного обеспечения для моментальных снимков...

Снимки — это в основном системы копирования при записи, где каждый снимок представляет собой список указателей на копии измененных данных (блоки диска). Если программное обеспечение моментального снимка выйдет из строя, тип ошибки определит, возможно ли восстановление. Предположим, что все будет потеряно, и спланируйте это событие.

Реальные проекты резервного копирования никогда не доверяют только одному механизму резервного копирования, одному месту хранения резервных копий или одной копии резервной копии. Для ценных данных я всегда использую три формы резервного копирования плюс холодный резерв.

Региональное или мультирегиональное хранилище Google Cloud построено на репликации нескольких копий больших двоичных объектов внутри зоны, между зонами и между регионами. Теоретически, даже сгоревший дотла центр обработки данных приведет к очень незначительной потере данных. Снапшоты хранятся так и на некоторых типах дисков.

Снапшоты автоматически поддерживают по крайней мере один полный с инкрементными копиями. Насколько я могу судить, это нельзя контролировать с помощью API. Обычно я бы предпочел вариант полного восстановления для более простого восстановления, но если это может надежно выполнять добавочное восстановление с простым интерфейсом, это может сработать.

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

Если вы попытаетесь создать моментальный снимок с зонального постоянного диска и процесс создания снимка завершится неудачно, вы не сможете удалить исходный зональный постоянный диск, пока вы не очистите неисправный снимок. Эта отказоустойчивость помогает предотвратить случайное удаление исходные данные в случае неудачного резервного копирования.

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