Экземпляр AWS EC2 (Windows Server 2008): ежедневный снимок состояния EBS без простоев

TL; TR

Мне нужно сделать резервную копию тома AWS EBS без простоев.

Подробно

У меня есть экземпляр "Windows Server 2008"EC2"на Amazon AWS с двумя EBS-тома так как C: и D: системные драйверы.

На C: драйвер работает ОС, на D: драйвер работает с веб-сервисом, мне нужно только сделать резервную копию D:.

Веб-сервис - это приложение Delphi SOAP, используемое для загрузки некоторых файлов по запросу, например:

http://www.example.com/dir/service.dll?filename=foo.zip

(в этом случае веб-сервис отвечает foo.zip файл, расположенный в D:\dir\files\).

По каждому запросу это приложение записывает некоторые файлы (файлы сеанса и файлы журнала) в D:\dir\temp\. Это проблема, потому что сделать снимок используемого тома, это небезопасно, из Документы AWS:

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

Моя идея - реализовать в моем веб-сервисе режим только для чтения, основанный на существовании файла в каталоге.

procedure onRequest(Sender: TObject; Request: TWebRequest; Response: TWebResponse; var Handled: Boolean);
begin
    FReadOnlyMode := FileExists('D:\dir\flag\read_only_mode.txt');
    // ... other code

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

Стратегия резервного копирования основана на еженощной задаче cron в Windows, которая выполняет командный файл, например. backup.bat:

:: 1. stop all web service writes operation
echo.>D:\dir\flag\read_only_mode.txt

:: 2. Use sync.exe for flush all data to disk D
sync.exe d

:: 3. Use Amazon CLI for snapshot the volume:
aws ec2 create-snapshot --volume-id vol-XXXXXXXXXX --description "D snapshot."

:: 4. Remove `read_only_mode` flag:
del /F /Q D:\dir\flag\read_only_mode.txt

(подробнее на Синхронизация Windows и Amazon CLI)

Возникает вопрос: мои снимки EBS будут согласованными?

Я новичок в AWS, любые другие предложения приветствуются!

Извините за мой плохой английский

Теоретически, чтобы ваши снимки EBS были последовательный, вам не нужно будет запускать никаких приложений с отслеживанием состояния в момент начала создания моментального снимка. К сожалению, саму Windows можно считать с отслеживанием состояния, что может немного запутать, особенно если вы используете кэширование записи.

В этом есть несколько интересных, но запутанных моментов:

«Снимок» в процессе создания снимка выполняется немедленно, вам не нужно отключать запись на все время, пока снимок находится в режиме ожидания. Создание снимка большого тома может занять несколько часов, но это всего лишь резервное копирование или копировать часть снимка. До тех пор, пока Amazon не перестанет отключать электричество во время этого процесса, окончательный снимок будет данными на диске точно в то время, когда он был создан.
Снимки делаются асинхронно. Таким образом, инструмент командной строки не должен блокироваться во время создания снимка, и его возврат не имеет отношения к состоянию снимка.

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

Другая важная проблема, которая привлекает внимание людей, - это транзакции. Если, например, вы создаете веб-сайт, который позволяет загружать файлы, ваши проблемы будут связаны с моментальным снимком, который выполняется на этапе процесса. Типичным примером этого может быть существующая запись базы данных, в которой говорится, что файл '1234' был загружен в 'd: / files / 1234', но файл не существует, поскольку файл еще не был скопирован в это место, когда был создан моментальный снимок, но запись базы данных уже зафиксирована.

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

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

Если вы можете написать свое приложение, чтобы не беспокоиться о том, что файлы частично записываются на диск (вас волнует, если запись в журнале отсутствует?), Вам не нужно использовать режим только для чтения. Один из способов приблизиться к этому с загрузкой файлов - это сделать папку загрузки отличной от конечного местоположения (на том же диске). После завершения загрузки файла и успешной записи переместите файл в место хранения. Перемещение должно выполняться как «переименование» файла, а не побайтовое копирование, и происходить мгновенно. Если файл никогда не попадает в свое окончательное местоположение, вы знаете, что загрузка не удалась.