Я ищу способ сбросить все ожидающие записи на диск в Windows, а затем буферизовать все будущие записи, пока команда не даст добро.
Я хотел бы очистить записи SQL Server и записи системы Windows, а затем буферизовать оба.
Чтобы четко понимать, что я делаю:
Я использую Windows 2008 R2 и SQL Server 2008 R2 на EC2. Я делаю ежечасный снимок диска, на котором они находятся. Когда ничего критического не меняется, эти снимки получаются нормально, но время от времени я получаю плохие снимки. В худшем случае, в случае отказа диска (технически сбой EBS), если у меня есть 3 плохих почасовых снимка, я потеряю 4 часа данных.
Моментальные снимки уже обеспечивают быстрое дифференциальное резервное копирование и быстрое и простое восстановление, поэтому все, что я ищу, - это способ очистить все данные, чтобы они находились на диске в согласованном состоянии, а затем приостановить все записи до тех пор, пока снимок не будет завершен. Я счастлив написать код для службы, в которую я обращаюсь, чтобы это произошло, но мне нужно знать, для каких API / команд мне нужно писать, чтобы выполнить задачу.
Я знаю, что могу создать отдельный том, для которого я постоянно запускаю резервное копирование Windows, а затем создаю его снимок, но это значительно удлиняет процесс резервного копирования и похоже на взлом. Я знаю, что и Windows, и SQL Server очень хорошо справляются с буферизацией записи, поэтому мне кажется, что это можно сделать на месте.
Идеи?
Один из вариантов - использовать теневое копирование в Windows. Сам процесс теневого копирования истощает все буферы записи перед фиксацией собственного моментального снимка. Запланируйте создание снимка за минуту или две до снимка EC2. Таким образом, при срабатывании моментального снимка EC2 у вас будет последняя согласованная копия уже в системе.
Я не могу ответить, как заблокировать диск, чтобы Windows не записывала и не принудительно выполняла сброс, поэтому это будет половинный ответ, но есть одна важная информация, которую ваш вопрос не замечает:
Создание моментального снимка ec2 происходит мгновенно. Вам не нужно ждать его завершения! После того, как вы запустите его, вы можете снова начать использовать свой диск, и снимок будет по-прежнему получать данные в точке снимка, а не в текущем состоянии. Это происходит потому, что после того, как вы пометите его для моментального снимка, все НОВЫЕ данные, записанные на диск, помещаются в очередь на своего рода оверлейный диск, и данные на момент запроса моментального снимка сохраняются.
Это должно облегчить вашу другую проблему. Все, что вам нужно сделать, это выполнить сброс на диск, чтобы все было согласовано, затем сделать паузу на пару секунд, пока вы убедитесь, что API моментальных снимков вернул код успеха, чтобы вы знали, что процесс запущен, а затем вы можете вернуться к написанию.
Я собираюсь добавить отдельный ответ, чтобы ответить на некоторые из ваших комментариев. VSS - хороший способ, если вы пытаетесь стабилизировать данные. На самом деле, насколько я понимаю, MSFT DPM очень эффективно использует эту подсистему с SQL. Конечно, у них были специальные команды, которые решали проблемы.
VSS не испортит SQL, но он может (и имел) вмешиваться в собственные методы резервного копирования SQL (см. Мой ответ на вопрос Вот для получения дополнительной информации). Вы должны быть очень осведомлены о том, что вы пытаетесь достичь, что делает VSS и совпадают ли эти два аспекта.
Вы можете написать что-нибудь для вызова API VSS изначально (не спрашивайте меня, как, я не разработчик), или вы можете использовать что-то вроде vshadow.exe для создания и управления теневыми копиями для вас. Vshadow.exe доступен в MSFT SDK; убедитесь, что вы выбрали правильную версию для своей ОС.
В зависимости от вашей модели восстановления SQL SQL будет по-разному реагировать на вызов VSS. Прошло некоторое время с тех пор, как я имел дело с мельчайшими деталями SQL и VSS, но из того, что я помню, если у вас установлена простая модель восстановления, журналы будут обрезаться при вызове VSS. В случае с полным и массовым протоколированием этого не будет, и вам нужно будет что-то сделать для управления размером журналов.
И вы, наверное, это знаете, но проверяйте, проверяйте, проверяйте. Ваши снимки хороши только в том случае, если вы действительно можете их восстановить.
Я ни в коем случае не эксперт по EC2, но за пределами EC2, если вы хотите создавать согласованные резервные копии с использованием моментальных снимков хранилища, вы должны приостановить файловую систему до того, как будет выполнено резервное копирование.
Должна быть запущена служба SQL Writer (см. http://msdn.microsoft.com/en-us/library/ms175536.aspx для получения дополнительной информации о службе SQL Writer), а затем резервное копирование будет использовать VSS COM API, чтобы заморозить ввод-вывод, сделать снимок и снова разморозить его (здесь много подробностей: http://msdn.microsoft.com/en-us/library/aa384589%28v=vs.85%29.aspx).
Поставщики SAN обычно интегрируют вызовы VSS API в свою процедуру создания моментальных снимков, и это может быть сделано через агент, работающий на сервере.
Я не могу ответить, действительно ли EC2 выполняет этот вызов для вас, или это то, что вам нужно будет написать самостоятельно (используйте API VSS, чтобы заморозить ввод-вывод, затем вызовите API EC2, чтобы сделать снимок), но, надеюсь, мой ответ дает Вам несколько указателей.
AutomatiCloud делает именно то, что вы ищете. Он имеет дополнительный агент VSS, который использует поставщик моментальных снимков VSS, предоставляемый MS-SQL, MS-Exchange или другими.
Во время резервного копирования он замораживает / перенаправляет ввод-вывод на диск (-ах), запускает моментальный снимок EC2 и затем снова разрешает ввод-вывод.
Весь процесс контролируется с помощью простого в использовании графического интерфейса Windows без каких-либо сценариев.