Я много читал об aws ebs, и многие люди, кажется, поощряют людей замораживать файловую систему в течение снимок. Однако эта часть документации amazon должна отличаться:
Во время завершения на текущий моментальный снимок не влияют текущие операции чтения и записи в том.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
Почему многие люди замораживают файловую систему во время создания снимка, в то время как документация aws говорит, что на снимок не влияет ввод-вывод?
Что делать, если моя файловая система используется для ftp?
Что делать, если моя файловая система используется для базы данных?
Сами по себе снимки состояния Amazon небезопасны, если их делать во время работы системы. Они безопасны, если вы выключите систему перед созданием снимка. Любые данные файловой системы, которые кэшируются в буферах операционной системы или в буферах приложения (например, базы данных), не будут частью моментального снимка. Это может привести к неисправимым повреждениям.
И в Linux, и в Windows есть механизмы, обеспечивающие возможность заморозить систему (сообщить приложениям, чтобы они сбрасывали свои данные на диск). После этого выполняется оттаивание, позволяющее продолжить работу приложений. Между замораживанием и оттаиванием делается снимок. Примечание: большинство приложений не поддерживают замораживание / размораживание, а некоторые реализуют его неправильно. Внимательно изучите документацию поставщиков.
Еще один важный момент - проверить, где ваши приложения хранят свои данные. Базы данных в соответствии с передовой практикой хранят свои данные, журналы и т. Д. В разных файловых системах. Это означает, что вы можете запускать моментальный снимок одного тома в другое время, чем моментальный снимок другого тома (который может потребоваться в качестве набора для успешного восстановления приложения и его данных).
Главное - понять разницу между моментальными снимками, согласованными с ошибками и согласованными с приложениями.
Вот статья о снимках состояния EBS, в которой объясняются различия.
Снимки состояния EBS: соответствие сбоям и приложениям
[Обновление после комментариев Майкла]
В моментальных снимках реализовано копирование при записи (COW). После запуска моментального снимка файловую систему можно изменить. Если файловая система выполняет запись в дисковый блок, подсистема COW копирует исходный блок в свой внутренний кеш, чтобы файловая система могла быть изменена во время моментального снимка.
Нет необходимости держать файловую систему в замороженном состоянии во время создания снимка. Во время создания моментального снимка создаются / копируются необходимые структуры данных тома, поэтому удерживать замораживание не требуется. В зависимости от системы и объема данных, которые кэшируются в памяти, размера журналов ОС, приложений и т. Д., Цикл замораживания / снэпшота / размораживания может длиться всего несколько секунд.
Вот статья о различных технологиях создания снимков, в которой объясняется функция копирования при записи:
Использование различных типов технологий моментальных снимков хранилища для защиты данных
Короткий ответ: это действительно зависит от типа приложения, которое вы запускаете на своем экземпляре.
Длинный ответ: По сути, создание неустановленного снимка работающей машины похоже на «вытащить вилку из розетки» - то есть: внезапный, немедленный, неожиданный сбой.
При работе с включенным барьером ввода-вывода современная журналируемая файловая система должна быть согласованной, несмотря на любой сбой. Это делает не означает, что данные в памяти не будут потеряны; скорее, эти зафиксированные данные гарантированный для хранения в постоянном хранилище (например, на диске).
Это действительно применимо к любому правильно журналируемому приложению, особенно к ACID-совместимым базам данных (неполный список: MSSQL, InnoDB, PostgreSQL, Oracle, IBM DB2 и т. Д.). Опять же, это не означает, что внезапное отключение питания (или восстановленный, не приостановленный снимок) не приведет к потере данных; скорее, это означает, что при возврате (возможно, неявного) COMMIT все соответствующие данные находятся в стабильном хранилище.
С таким журналируемым приложением вам не обязательно останавливать файловую систему. При первой загрузке после восстановленного моментального снимка система ответит на свои журналы (файловая система и базы данных), и будет достигнуто согласованное состояние.
Однако есть много приложений, которые не правильно записывать их обновления, и которые требовать эквивалент fsck вернуться в стабильное состояние. Основным примером является MySQL + MyISAM: этот (очень распространенный) механизм базы данных не Совместимость с ACID, поскольку его большая скорость записи достигается за счет пакетной обработки несвязанных операций ввода-вывода с небольшим учетом обычных барьеров ввода-вывода. Неправильное завершение работы (например, потеря питания, сбой системы или mysql, несогласованный моментальный снимок) База данных MyISAM может быть неработоспособной до тех пор, пока mysqlcheck/mysqlrepair выполняется.
Различные руководства рекомендуют приостановить файловую систему перед созданием моментального снимка именно по этой причине: некоторые «неподготовленные» приложения (читай: MyISAM) могут быть несколько повреждены внезапным завершением работы и последующим восстановлением, требующим проверки согласованности.
Нижняя граница: если вы используете журналируемую файловую систему с включенными барьерами ввода-вывода (по умолчанию в ext4 и XFS) и база данных, совместимая с ACID, вы должны быть в безопасности, делая неустановленные моментальные снимки. В худшем случае вы можете увидеть некоторую нефатальную ошибку / предупреждение при монтировании снимка, но ответ журнала приведет систему в согласованное состояние. Однако при использовании MyISAM лучше заморозить / приостановить работу вашей файловой системы, прежде чем делать снимок.