Сегодня мы рассмотрим одну из интереснейших функций – снэпшоты.
Эта тема немного мистическая и при первом знакомстве снапшоты могут ошеломить.
И это понятно, ведь у них есть 2 удивительных свойства: они мгновенно работают и почти не занимают места.
Возникает вопрос - как это возможно?
И могут ли они заменить нормальный бэкап?
Ответ на последний вопрос прост - нет, не могут. Снапшот не заменяет бэкап полностью - у него другие цели, задачи и средства их решения. И, прежде всего, снапшоты находятся на том же диске, что и исходные данные. Иными словами, они не защищают от отказа/поломки диска, на котором находятся данные (hardware problems). Зато от всего остального они защищают отлично: это и человеческие ошибки, и проблемы с программами и файловой системой и т.д. Они могут служить машиной времени, которая почти мгновенно и без усилий может перемещать вас во времени в любых направлениях...
Современные программы бэкапа вовсю используют снапшоты для своих задач.
Вспомним главные недостатки classical backup - он медленный и занимает много места. Поскольку он медленный он может не быть консистентным. Файлы могут измениться за время бэкапа, а некоторые (о ужас) могут вообще не войти в бэкап. Представьте себе, что в процессе вы забэкапили одну папку, а через час другую. Но в промежутке между этими моментами вы переписали файл из 2-й папки в 1-ю. Вначале это файл еще не был в первой папке, а в конце он уже не находился во второй – такой файл на попадет в бэкап. Надеюсь, понятно, почему?
Снэпшот, за счет своей скорости, спасает бэкап от всех этих проблем. Т.е., бэкап и снэпшот сегодня работают рука об руку.
И, все же, вернемся к первому вопросу - как снэпшот работает и почему он такой быстрый и маленький. То есть, в чем его отличие от нормального бэкапа?
Попробуем сравнить снэпшот с книгой.
В книгах есть 2 вещи - основной текст и оглавление/содержание, которое нужно для быстрого нахождения нужного текста.
Представим себе, что писатель решил зафиксировать текущее состояние книги, которую он пишет. Для этого он должен создать дополнительное оглавление. Также, применить правило – вырывание страниц (указанных в дополнительном оглавлении) строго запрещено. Теперь, каждый раз, когда писатель будет добавлять новые страницы, он будет динамически обновлять оглавление, но не сохранять. При этом оглавление-снэпшот будет сохраняться все время. Будут сохраняться и страницы, на которые оглавление указывает.
В результате станут существовать 3 типа страниц:
- неизмененные страницы останутся на своих местах (на них будут указывать как текущее, так и дополнительное оглавление-снэпшот),
- новая информация будет записана на чистых страницах,
- измененные страницы будут записаны на чистых страницах.
Кроме того, останутся чистые/незаполненные страницы.
Теперь, чтобы вернуться на старый вариант книги, достаточно заменить оглавление на старое и оно укажет на старые страницы.
Аналогично и с реальным снэпшотом.
В момент создания снэпшот построится дополнительная таблица файлов (MFT для NTFS). Также создастся правило – удаление файлов/блоков, указанных в MFT, запрещено.
После этого момента на диске будут существовать 3 типа данных:
- неизмененные блоки останутся на своих местах (на них указывает текущий MFT и MFT снэпшота),
- новая информация будет записываться на новое место,
- измененные данные будут записываться на новое место.
Кроме того, останется пустое пространство на диске.
Теперь, чтобы вернуться обратно во времени, надо всего лишь заменить таблицу файлов (file table) на старую и она укажет на старое содержимое диска. И это очень быстрая операция.
Повторим еще раз.
Снэпшот не копирует сами данные в другое место, как бэкап. Вместо этого он создаёт дополнительное оглавление (например, MFT для NTFS). Оглавление указывает на расположение файлов. Эти файлы никогда не затираются новыми, а все новые файлы записываются в другие места.
У нас был один подвопрос - почему снэпшот не занимает много места? Ответ - все по той же причине – место занимает лишь новая файловая таблица.
Остался еще один интересный вопрос, который мы проскочили вскользь - что происходит с файлами, которые мы изменяем, куда попадают измененные блоки? На самом деле мы пока поговорили только об одном из существующих вариантов.
Оказывается, некоторые системы пишут изменённые блоки в новые места (NetApp),
некоторые в старые, предварительно скопировав старые блоки в новые места (copy on write - EMC), а некоторые (VMware) создают новые файлы, в которые записываются все изменения.
Эти способы различаются скоростью записи данных, а также скоростью удаления снэпшотов. Например, создание нового файла, как VMware, не представляет проблемы и происходит быстро. Но удаление такого файла не так эффективно и занимает ощутимое время. И в таких системах, как VMware, не рекомендуется создавать много снэпшотов, а также хранить их длительное время.
Но наше время уже подходит к концу и на этом мы пока закончим.
Эта тема немного мистическая и при первом знакомстве снапшоты могут ошеломить.
И это понятно, ведь у них есть 2 удивительных свойства: они мгновенно работают и почти не занимают места.
Возникает вопрос - как это возможно?
И могут ли они заменить нормальный бэкап?
Ответ на последний вопрос прост - нет, не могут. Снапшот не заменяет бэкап полностью - у него другие цели, задачи и средства их решения. И, прежде всего, снапшоты находятся на том же диске, что и исходные данные. Иными словами, они не защищают от отказа/поломки диска, на котором находятся данные (hardware problems). Зато от всего остального они защищают отлично: это и человеческие ошибки, и проблемы с программами и файловой системой и т.д. Они могут служить машиной времени, которая почти мгновенно и без усилий может перемещать вас во времени в любых направлениях...
Современные программы бэкапа вовсю используют снапшоты для своих задач.
Вспомним главные недостатки classical backup - он медленный и занимает много места. Поскольку он медленный он может не быть консистентным. Файлы могут измениться за время бэкапа, а некоторые (о ужас) могут вообще не войти в бэкап. Представьте себе, что в процессе вы забэкапили одну папку, а через час другую. Но в промежутке между этими моментами вы переписали файл из 2-й папки в 1-ю. Вначале это файл еще не был в первой папке, а в конце он уже не находился во второй – такой файл на попадет в бэкап. Надеюсь, понятно, почему?
Снэпшот, за счет своей скорости, спасает бэкап от всех этих проблем. Т.е., бэкап и снэпшот сегодня работают рука об руку.
И, все же, вернемся к первому вопросу - как снэпшот работает и почему он такой быстрый и маленький. То есть, в чем его отличие от нормального бэкапа?
Попробуем сравнить снэпшот с книгой.
В книгах есть 2 вещи - основной текст и оглавление/содержание, которое нужно для быстрого нахождения нужного текста.
Представим себе, что писатель решил зафиксировать текущее состояние книги, которую он пишет. Для этого он должен создать дополнительное оглавление. Также, применить правило – вырывание страниц (указанных в дополнительном оглавлении) строго запрещено. Теперь, каждый раз, когда писатель будет добавлять новые страницы, он будет динамически обновлять оглавление, но не сохранять. При этом оглавление-снэпшот будет сохраняться все время. Будут сохраняться и страницы, на которые оглавление указывает.
В результате станут существовать 3 типа страниц:
- неизмененные страницы останутся на своих местах (на них будут указывать как текущее, так и дополнительное оглавление-снэпшот),
- новая информация будет записана на чистых страницах,
- измененные страницы будут записаны на чистых страницах.
Кроме того, останутся чистые/незаполненные страницы.
Теперь, чтобы вернуться на старый вариант книги, достаточно заменить оглавление на старое и оно укажет на старые страницы.
Аналогично и с реальным снэпшотом.
В момент создания снэпшот построится дополнительная таблица файлов (MFT для NTFS). Также создастся правило – удаление файлов/блоков, указанных в MFT, запрещено.
После этого момента на диске будут существовать 3 типа данных:
- неизмененные блоки останутся на своих местах (на них указывает текущий MFT и MFT снэпшота),
- новая информация будет записываться на новое место,
- измененные данные будут записываться на новое место.
Кроме того, останется пустое пространство на диске.
Теперь, чтобы вернуться обратно во времени, надо всего лишь заменить таблицу файлов (file table) на старую и она укажет на старое содержимое диска. И это очень быстрая операция.
Повторим еще раз.
Снэпшот не копирует сами данные в другое место, как бэкап. Вместо этого он создаёт дополнительное оглавление (например, MFT для NTFS). Оглавление указывает на расположение файлов. Эти файлы никогда не затираются новыми, а все новые файлы записываются в другие места.
У нас был один подвопрос - почему снэпшот не занимает много места? Ответ - все по той же причине – место занимает лишь новая файловая таблица.
Остался еще один интересный вопрос, который мы проскочили вскользь - что происходит с файлами, которые мы изменяем, куда попадают измененные блоки? На самом деле мы пока поговорили только об одном из существующих вариантов.
Оказывается, некоторые системы пишут изменённые блоки в новые места (NetApp),
некоторые в старые, предварительно скопировав старые блоки в новые места (copy on write - EMC), а некоторые (VMware) создают новые файлы, в которые записываются все изменения.
Эти способы различаются скоростью записи данных, а также скоростью удаления снэпшотов. Например, создание нового файла, как VMware, не представляет проблемы и происходит быстро. Но удаление такого файла не так эффективно и занимает ощутимое время. И в таких системах, как VMware, не рекомендуется создавать много снэпшотов, а также хранить их длительное время.
Но наше время уже подходит к концу и на этом мы пока закончим.
Комментариев нет:
Отправить комментарий