Comments 25
Насколько я помню, у Lotus Domino есть свои собственные средства резервного копирования, которые делают резервное копирование «правильным» образом, т.е. так чтобы обеспечить целостность данных. Вообще большинство производителей ПО снабжают свои продукты такими средствами резервного копирования чтобы учесть особенности этих продуктов. Например, бэкап MS SQL Server лучше делать собственными средствами и останавливать службы при этом нет никакой необходимости.
Lotus у нас администрирует другой человек (удалённо, из Германии), я в нём не разбираюсь. Я спросил у него как бекапить, он сказал, что можно просто копировать. Но с «просто копированием» бывали проблемы типа «файл пропал в то время как должен был быть скопирован», поэтому я сделал снапшоты.
Ну а в целом я конечно же с вами согласен, если есть надёжные встроенные средства, то почему бы их не использовать. Но иногда этого недостаточно, а иногда это сложнее.
При очень больших базах, исчисляемых терабайтами, штатные средства бэкапа не успевают скопировать базу в необходимое время. Как раз в этих случаях применяется эта технология.
И не обязательно останавливать базу. Например, Oracle можно перевести в backup mode и после снимка перевести в штатный режим.
И не обязательно останавливать базу. Например, Oracle можно перевести в backup mode и после снимка перевести в штатный режим.
Я не люблю MS, но хочу сказать, что у shadow copy есть куда больший потенциал, чем у обычных снапшотов файловой системы.
В частности, VSS предусматривает понятие «провайдера VSS», предоставляемого службой. В момент выполнения бэкапа провайдер гарантирует логическую целостность данных для снапшота (в пределах своей зоны ответственности). То есть, например, база данных сделает синк и не отдаст незавершённые транзацкии, а система виртуализации скинет буферы записи. Как результат, бэкап будет более консистентным, чем просто в случае снапшотов.
Насколько я знаю, в юниксе подобной общепринятой технологии нет.
В частности, VSS предусматривает понятие «провайдера VSS», предоставляемого службой. В момент выполнения бэкапа провайдер гарантирует логическую целостность данных для снапшота (в пределах своей зоны ответственности). То есть, например, база данных сделает синк и не отдаст незавершённые транзацкии, а система виртуализации скинет буферы записи. Как результат, бэкап будет более консистентным, чем просто в случае снапшотов.
Насколько я знаю, в юниксе подобной общепринятой технологии нет.
Но база данных должна уметь с этим работать, верно? Да, штука полезная, если база её поддерживает.
В Unix системах единого интерфейса, вроде как, действительно нет, но обычно можно найти какой-нибудь work around вроде read lock.
В Unix системах единого интерфейса, вроде как, действительно нет, но обычно можно найти какой-нибудь work around вроде read lock.
Если говорить о MySQL и MyISAM и, возможно о всех БД, не поддерживающих транзакции, то там flush tables with read lock может остановить работу всей системы, при условиях, что каждое действие системы сопровождается логироавнием в какую-нибудь таблицу. Пример: модуль статистики битрикс.
С InnoDB все отлично.
С InnoDB все отлично.
Конечно я имел ввиду flush, а потом read lock.
В линуксе либо уже есть, либо активно развивается подобная фича: lwn.net/Articles/287435/. Правда, не знаю, в каком оно сейчас состоянии.
Смею предположить, что если даже будет достигнута целостность на уровне файловой системы (fsync), то на логическом уровне вряд ли будет всё так радужно. Чтобы в любой момент времени данные программы на диске были в согласованном состоянии, нужно очень тщательно продумать _все_ возможные ситуации сбоев и восстановлений после них. Вряд ли много кто кроме девелоперов БД хотя бы ставил себе такую цель (про строгое док-во я вообще молчу).
Смею предположить, что если даже будет достигнута целостность на уровне файловой системы (fsync), то на логическом уровне вряд ли будет всё так радужно. Чтобы в любой момент времени данные программы на диске были в согласованном состоянии, нужно очень тщательно продумать _все_ возможные ситуации сбоев и восстановлений после них. Вряд ли много кто кроме девелоперов БД хотя бы ставил себе такую цель (про строгое док-во я вообще молчу).
В моём понимании идея в том, чтобы база данных сама привела всё в порядок в файловой системе сразу после того как поступил запрос на создание снапшота, но перед тем, как снапшот будет сделан.
Вполне возможно. Но тогда должна быть поддержка со стороны софта, а софт — он такой, бывает разного качества :)
Я так понял, что amarao об этом и говорил.
Я про то, что это очень ограниченная фича — в уже написанный софт, первоначально не предназначенный на подобного рода синхронизацию, просто так её поддержку не добавишь.
Это верно :)
Практически весь софт от Microsoft поддерживает VSSWriter
msdn.microsoft.com/en-us/library/aa384649(v=vs.85).aspx
Так же довольно просто добавить в самописное ПО компонент VSS.
msdn.microsoft.com/en-us/library/aa384649(v=vs.85).aspx
Так же довольно просто добавить в самописное ПО компонент VSS.
А про заморозку в xfs мне кажется это не совсем то, хотя я с xfs не работал.
Вы забыли опубликовать содержимое snapshot_vars.cmd, который у вас используется в «set snapshot_var_script=snapshot_vars.cmd»
2011-2003=8.
Пользуюсь аналогичным решением для работы с базами данных почтового сервера hmailserver и резервного копирования с файловых серверов. vshadow.exe прекрасно работает и с Windows XP, только нужно использовать другой исполняемый файл, не для Winodws 2003.
Справедливости ради стоит отметить, что о теневом копировании знает и собственный, встроенный в Windows Backup. Единственная тонкость — запускаться он должен на том же сервере, с томов которого выполняется резервное копирование, и путь к источнику данных на сервере в задании ntbackup должен быть указан как, например, C:\data, а не \\server\data, иначе теневое копирование при резервировании не включится, и открытые на тот момент файлы окажутся пропущенными.
Еще одно интересное готовое решение — Hobocopy
Справедливости ради стоит отметить, что о теневом копировании знает и собственный, встроенный в Windows Backup. Единственная тонкость — запускаться он должен на том же сервере, с томов которого выполняется резервное копирование, и путь к источнику данных на сервере в задании ntbackup должен быть указан как, например, C:\data, а не \\server\data, иначе теневое копирование при резервировании не включится, и открытые на тот момент файлы окажутся пропущенными.
Еще одно интересное готовое решение — Hobocopy
А оно с открытым кодом! github.com/candera/hobocopy
Спасибо за наводку.
Спасибо за наводку.
1. Сделали с помощью вышеописанных программ образ диска C (система+пара программ с базами) ~80 Гиг.
2. Все работает N-дней
3. Сгорает мать (совсем, новых нет, снята с производства)
4. Покупается новая мать
5. ????
p.s. Нет, переустановить систему не вариант.
2. Все работает N-дней
3. Сгорает мать (совсем, новых нет, снята с производства)
4. Покупается новая мать
5. ????
p.s. Нет, переустановить систему не вариант.
Sign up to leave a comment.
Windows: удалённое резервное копирование с использованием снапшотов (VShadow)