Пытаться защититься от вирусов и других хакерских атак только средствами антивирусов и межсетевых экранов, это все равно что навесить замков на двери, поставить сигнализацию и видеонаблюдение и расчитывать на то, что не найдется кто-то, кто это сможет обойти. Как показывает история, даже самые сложные замки, самые умные сигнализации и видеонаблюдение можно обойти. И нужно иметь «План Б» и быть готовым к наихудшему. Единственный выход это иметь возможность быстро и качественно восстановить данные.
Системы хранения NetApp FAS/ONTAP
Имеют не только множество интеграций с множеством софта для резервного копирования, антивирусными системами и другими инфраструктурными системами, но также обеспечивает высокую доступность для NAS (NFS, CIFS/SMB) и SAN (iSCSI, FC, FCoE). Унифицированное хранилище позволяет обеспечивать прозрачную миграцию данных между нодами кластера, который может состоять из 24 узлов, а также позволяет задействовать одновременно все ноды кластера для обслуживания NAS и SAN для повышения производительности. Таким образом можно полностью отказаться от подверженных уязвимостям Windows Server и не покупать лицензии и не строить кластеров для высокой доступности, ведь весь функционал уже есть в NetApp ONTAP.
Резервное копирование
Как в самых больших, так и в маленьких организациях рабочие файлы располагают на общедоступном файловом хранилище, чтобы все могли ими пользоваться. Централизация хранения даёт удобство для совместной работы нескольким людям над одними и теми же файлами, но это накладывает и ответственность по защите такой информации. Естественно для борьбы с вирусами-шифровальщиками необходимо регулярно выполнять резервное копирование по схеме 3-2-1. Резервные копии важно хранить отдельно от основной системы.
Системы хранения NetApp FAS/ONTAP имеет в своём арсенале снэпшоты не влияющие на производительность и репликацию на базе этих снэпшотов, которые позволяют интегрироваться с широким списком систем резервного копирования использующие технологии системы хранения данных NetApp:
- Veeam Backup & Replication
- CommVault Simpana
- NetApp SnapManager/SnapCenter.
- NetApp SnapCreator (бесплатный фреймворк)
- Veritas NetBackup
- Veritas BackupExec
- SyncSort
- Acronis
- IBM Tivoli
- EMC Networker
- HP Data Protector
- И другие
Давайте рассмотрим одну из таких систем резервного копирования, Veeam Backup & Replication, которая завоевала доверие и уважение благодаря лёгкости и простоте интерфейса управления. Но это далеко не все преимущества этого продукта, который не только умеет управлять снэпшотами и репликами между системами NetApp FAS, ONTAP Select, ONTAP Cloud и AltaVault, но также позволяет ещё средствами СХД клонировать данные на одной из площадок для тестирования работоспособности и восстанавливаемости из таких бэкапов. Клонирование как и снэпшоты на система NetApp FAS/ONTAP, это очень удобная технология, которая также не влияет на производительность и в начальный момент снятия снэпшота практически не занимает пространство на хранилище создаваясь меньше чем за секунду, в не зависимости от величины клонируемых данных.
Снэпшоты для спасения
Но полное восстановление, во-первых, может быть достаточно длительным, а во-вторых резервное копирование может выполняться не каждые 15 минут, таким образом увеличивая RPO. И вот здесь становится понятно, насколько важной частью резервного копирования являются снэпшоты, которые можно выполнять на много чаще нежели резервные копии с NAS хранилища и соответственно восстанавливать такие данные намного быстрее из снэпшотов, таким образом существенно уменьшив значение RPO. И вот здесь становится понятно насколько важно, чтобы такие снэпшоты функционировали как часы, не тормозили работу всего хранилища, не имели архитектурных проблем по удалению и консолидации снэпшотов. При этом снэпшоты это не замена резервному копированию, а отличное дополнение для полноценной стратегии резервного копирования. Так снэпшоты можно выполнять достаточно часто, чтобы захватывать самые последние изменения вашей информации.
Снэпшоты это не полная копия данных, только разница новых данных на блочном уровне, своего рода обратный инкрементальный бэкап, который более рационально использует пространство хранилища, нежели полный бэкап. Но всё равно это пространство используется, чем больше изменений, тем больше попадает информации в снэпшот. Настроенное расписание авто-удаления старых снэпшотов позволит более рационально использовать ресурсы хранилища и не съесть всё доступное пространство на дорогостоящем NAS хранилище. А резервное, будет хранить намного дольше по времени копии более старых версий информации.
Снэпшоты и технология NetApp FabricPool
Отдельно стоит отметить технологию FabricPool, позволяющую прозрачно смещать снэпшоты и холодные данные с SSD накопителей на медленные диски в объектное хранилище, что позволит активно и часто использовать на столько важную технологию для резервного копирования и восстановления на дорогостоящих носителях информации.
Есть отдельный документ как бороться с вирусами-шифровальшиками используя системы NetApp.
Как снэпшоты не должны работать
Многие уже сталкивались с различными реализациями снэпшотов и уже на практике знают, как снэпшоты не должны работать:
- они не должны увеличивать нагрузку на дисковую подсистему просто от наличия снэпшота
- они не должны увеличивать нагрузку просто от большего числа снэпшотов
- они должны быстро создаваться и удалиться и этот процесс не должен влиять на производительность дисковой подсистемы
- они должны удаляться так чтобы не повредить основные данные
- им не должно быть разницы сколько данных, всё должно работать быстро, моментально и без малейшей возможности повредить информацию из-за удаления или консолидации снэпшота.
Снэпшоты в операционной системе ONTAP для хранилищ NetApp так не работают. Они были впервые реализованы в операционной системе ONTAP, как часть файловой системы WAFL в 1993 году, эти технологии апробированы временим и сотнями тысяч компаний по всему миру. Кстати само слово «снэпшот» (Snapshot ™) является зарегистрированной торговой маркой компании NetApp, а эта технология снэпшотирования запатентована. Чтобы удостовериться в том, как работают снэпшоты WAFL можно бесплатно скачать на тестовый период виртуальную машину с образом хранилища ONTAP.
mysupport.netapp.com/NOW/cgi-bin/software/?product=ONTAP+Select&platform=Deploy+Install
Автоматизация восстановления
Интеграция снэпшотов хранилища с операционными системами позволит снять рутину с администратора хранилища по восстановлению отдельных файлов. Чтобы пользователи сами могли восстанавливать свои файлы из снэпшотов прямо из своего компьютера стандартными срадствами ОС.
Репликация снэпшотов
Просто удаление старых снэпшотов, которые уже есть на хранилище и настроены в хорошо налаженной стратегии резервного копирования — это ужасная трата ресурсов. Ведь снэпшоты можно использовать для их репликации на вторую систему хранения. Во-первых снэпшоты уже есть, почему-бы их не использовать, во-вторых намного выгоднее передавать дельту нежели весь набор данных каждый раз, в третьих снэпшоты работают на подобии обратных инкрементальных бэкапов, то есть не требуют времени на «склеивание в полный бэкап», в четвертых снэпшоты ONTAP подобны обратным инкрементальным бэкапам, но они не требуют склеивания или консолидации ни во время репликации ни во время восстановления, как это происходит с традиционными инкрементальным бэкапом или обратным инкрементальным бэкапом. Но магии не бывает, снэпшоты при репликации данных всё равно вычитываются из целевой системы, чтобы быть отправленными на удалённую систему, это порождает дополнительные операции чтения во время реплики, но это намного лучше в сравнении с фулл-бэкапом, который каждый раз вычитывает заново все данные целиком.
WORM
Технология Write Once Read Manу или WORM, таже известна и под другими коммерческими названиями, к примеру NetApp SnapLock построенная на базе снэпшотирования, позволяет залочить данные на длительный срок от изменений, в том числе и пользователей системы хранения с повышенными привилегиями. Так можно хранить прошивки, конфиги от разнообразных устройств, к примеру свичей, роутеров и прочее. Подобного рода файлы редко если вообще меняются в течении жизни устройства, а харнилища с поддержкой WORM надежное место для расположения важных файлов-настроек для инфраструктуры, которые нельзя менять, но можно читать. Это свойство можно использовать для того, чтобы загружать конфигурации и прошивки для ключевых компонент вашей инфраструктуры.
Антивирусная защита NAS
Ну и конечно же возможность проверки файлов на стороне хранилища тоже будет не лишней. Системы NetApp FAS/ONTAP интегрируются с широким списком антивирусных систем которые будут выполнять проверку корпоративных данных на NAS хранилище. Поддерживаются самые известные системы резервного копирования:
- Symantec
- Trend Micro
- Computer Associates
- McAfee
- Sophos
- Kaspersky
Снэпшоты как индикатор заражения RansomWare
Как было сказано ранее снэпшоты хранят в себе блочную дельту, — разницу между предыдущим своим состоянием и между текущим, то есть актуальным. И чем больше изменений внесено в актуальные данные, тем больше занимает снэпшот. Кроме снэпшотов стоит ещё упомянуть про технологии компрессии и дедупликации данных, которые позволяют сжимать оригинальные данные, экономя пространство на хранилище. Так вот некоторые данные не компрессируются и не жмутся. К примеру фото, видео или аудио данные, а какие данные ещё не жмутся? Правильно зашифрованные данные. И вот представьте вы настроили расписание снэпшотов, у вас работает дедупликация и компрессия. Снэпшоты снимаются, а более старые удаляются, данные жмутся, потребление пространства достаточно размеренное и стабильное. И вдруг снэпшоты начинают занимать намного, намного больше нежели раньше, а дедуп и компрессия перестали показывать свою эффективность. Это и есть индикаторы молчаливой и вредоносной работы вируса-шифровальщика: ваши данные, во-первых, сильно изменяются (растут снэпшоты в объёме, по сравнениию с тем, как это было раньше), во-вторых дедуп и компрессия перестали давать результат (значит записывается несжимаемая информация, к примеру оригиналы файлов подменяются на зашифрованные версии). Эти два косвенных показателя приводят к более не рациональному потреблению пространства на хранилище, и вы можете заметить это на графике потребления пространства, который внезапно начал геометрически расти вверх.
Файл-Скрининг Fpolicy
Fpolicy и ONTAP directory-security API это механизмы которые позволяют анализировать файл, и в зависимости от натсроенных политик разрешать или не разрешать, записывать его или работать с ним. Анализ файла можно проводить на основе расширения файла (встроенный функционал Fpolicy в ONTAP) или по содержимому, тогда нужно специализированное ПО.
Free Cleondis SnapGuard Light Edition
Бесплатный продукт Cleondis SnapGuard Light Edition (SGLE) не только для детекции, но и для восстановления после вирусов-шифровальщиков при помощи снэпшотов на платформе NetApp ONTAP. SGLE способен распознавать паттерны вредоносной работы вирусов шифровальщиков, которые начинают шифровать ваши файлы и остановить клиенты которые зарежены от дальшейшего нанесения вреда и полностью совместим с существующими антивирусными системами.
Free Prolion DataAnalyzer-light
Бесплатный продукт Prolion DataAnalyzer-light предоставляет возможности детекции вирусов-шифровальщиков на платформе NetApp ONTAP.
SMB1 и WannaCry / Petya
Вирусы WannaCry / Petya используют уязвимость в протоколе SMB1 на Windows машинах, этой уязвимости нет в системах NetApp ONTAP. Но попав на Windows он может зашифровать файлы расположенные на NAS хранилище. Компания NetApp рекомендует отключить SMB1 и перейти на более новые версии протоколов SMB v2 или v3 на клиентских Windows Workstation, чтобы избежать заражения.
Более новые версии вируса способны выключать теневое копирование VSS на Windows хостах, но так как расписание снэпшотов на NAS хранилище NetApp настраиваются, включаются и выключаются на самом СХД, то выключенный VSS никак не повлияет на работу снэпшотов.
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB1 -Type DWORD -Value 0 -Force
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB2 -Type DWORD -Value 0 -Force
netsh advfirewall firewall add rule dir=in action=block protocol=TCP localport=445 name="Block_TCP-445"
netsh advfirewall firewall add rule dir=in action=block protocol=TCP localport=135 name="Block_TCP-135"
netsh advfirewall firewall add rule dir=in action=block protocol=TCP localport=139 name="Block_TCP-139"PS
Также обратите внимание на документ описывающий настройки безопасности ONTAP для усиления защиты (Security Hardening Guide for NetApp ONTAP 9).
В связи с массовыми заражениями данных вирусами типа RansomWare, NetApp Украина запускает акцию для своих существующих и будущих клиентов по:
- настройке снэпшотов для NAS
- установке бесплатного ПО мониторинга заражения RansomWare
- настройке интеграции с антивирусными системами для CIFS/SMB
- обучению по использованию снэпшотов с SAN доступом
Вывод
Снэпшоты это не замена, а важная часть стратегии резервного копирования, которая позволяют более быстро, более часто резервировать данные и быстрее их восстанавливать. Снэпшоты WAFL являются базисом для репликации данных на резервную СХД, не тормозят систему, не требуют консолидации и склеивания, являются эффективным средством резервного копирования данных.
Сообщения по ошибкам в тексте прошу направлять в ЛС. Замечания, дополнения и вопросы по статье напротив, прошу в комментарии.
Комментарии (44)
gaf
28.06.2017 16:16Снэпшоты — это хорошо, даже очень, в свое время они помогли мне в решении нескольких аварий. Но как по мне, в данном случае несколько притянуто за уши. Общий размер снэпшотов, как правило, ограничен и он значительно меньше размеров оригинального тома. И поэтому, чем быстрее шифровальщик «ест» том, тем меньше толк от снапшотов. Опять же, восстановление тома целиком — отменяет все изменения, а не только те, что были вызваны шифровальщиком.
bbk
28.06.2017 16:21Во-первых не понял как это «чем больше он ест, тем меньше пользы от снэпа»? Вообще не вижу связи.
Во-вторых, снэпы можно реплицировать на удаленное хранилище.
В третьих резервные копии и снэпы нужно проверять на восстанавливаемость.
В четвёртых есть специализированный софт который заранее оповестит о подозрительных активностях на NAS
В пятых на NAS восстанавливать можно отдельные файлы из снэпа
В шестых не забываем про схему 3-2-1
Вы вообще статью прочитали?gaf
28.06.2017 16:48-1Отвечу по порядку.
1. Ладно, приведу пример того, что имею в виду. К примеру у нас есть том и выделенное место для снэпшотов к нему в размере 10% от его размера. Том заполнен на половину. После того, как шифровальщик зашифрует 20% данных и начнет шифровать данные дальше, всех данных уже не восстановить.
2 и 3. На удаленном хранилище тоже должно быть достаточно места, как миниму столько, насколько заполнен том.В зависимости от расписания, резервные копии и репликации могут просто не успеть.
4. Ну есть много специального софта, причем здесь снэпшоты?
5. Тут наверное моя ошибка, в данном случае, я имел в виду «снэпшоты» как технологию в целом. VSS — это хорошо, но есть много разных методов (взависимости от применяемых средств). Да и опять же, существуют разные файловые системы, неужели из любой можно будет файлы достать?
6. см. пункты 2 и 3
Мой изначальный комментарий был лишь к тому, что снэпшот — это не резервная копия и относиться к нему так очень опасно.bbk
28.06.2017 18:18+2У вас логическая ошибка в самом первом утверждении, от которого все остальные полностью не правильные.
Если у вас есть том, который создан с размером 10TB, и в нём занято 10% (1TB), предположим также что там 10 файлов, каждый 100ГБ. В активной файловой системе занято 10%, в снэпах 0%. Если снять снэпшот, то ситуация не измениться: в активной файловой системе 10%, в снэпах 0%. А когда после этого вирус шифровальшик начнёт шифровать эти данные, то на нашем вольюме действительно будет занято 20%, то есть 10% в активной файловой системе, 10% в снэпах. Но дальше ваши выводы совершенно не правильные.
Во-первых, что значит «если вирус начнёт шифровать дальше» :). Всё он уже зашифровал все ваши данные, а именно актуальные версии файлов, именно из-за этого 10% занятого пространства после полного окончания шифрования ВСЕХ ваших данных, занимают 20%, дальше шифровать некуда :)
Потому эти дополнительные 10% которые до снэпа были в активной файловой системе станут 10% в виде снэпшотов, а другие 10% остануться в активной фаловой системе с зашифрованными данными.
Во-вторых если данные уже есть в снэпшоте, всё они уже защищены, раз и навсегда все ваши 10 файлов, 1TB данных (их более старые версии), и не важно, что когда-то снэп занимал совсем мало или 0%, в том то и свойство снэпа, он растёт по мере изменений вносимых в файл, в данном случае шифрование файла, то есть снэп не позволяет изменить оригинальные данные. Вирус не может залезь внутрь снэпа, потому что у него свойство «только для чтения».
Соответственно все, что вы написали по пунктам 1,2,3,4,6 не имеет смысла.
По пункту 5. Какой ещё VSS, какие ещё «Другие файловые системы»? Я здесь рассказываю непосредственно про одно решение NetApp FAS/ONTAP, как полная замена Windows Server который используется для NAS — корпоративный NAS на базе системы хранения данных NetApp FAS/ONTAP, про одну файловую систему WAFL и только про один вид Snapshot ™ компании NetApp. А также про интеграции других софтов с этим продуктом NetApp FAS/ONTAP: антивирусы, софт для бэкапов и софт мониторинга NAS хранилища NetApp FAS/ONTAP на предмет работы вирусов-шифровальщиков.
Как этого можно было не заметить?gaf
28.06.2017 18:42Ой, как же вы искаверкали мой пример. Давай-те тогда приведу мой же пример с числами. Есть том 10TB, есть ограницение на размер снэпшотов в размере 1TB. Том заполнен на половину — 5TB. Шифровальщик зашифровал 1TB — есть шансы восстановить данные, все что он сожрет после 1TB — пропало.
Даже если рассматривать такой узкий случай как «NetApp FAS/ONTAP, как полная замена Windows Server», то снапшоты — это плохо. Они ничего не знают о кэшах, да о тех самых кэшах, которые находяться на клиентских машинах в оперативной памяти. Если на хранилище лежит что-нибудь посложнее вордовых документов, то запросто можно получить нарушение целостности данных без всяких шифровальщиков и в обычный погожий день.
NetApp FAS/ONTAP может быть использован не только как полная замена Windows, это еще и хорошее хранилище, у которого снэпшоты работают и на презентуемых томах. А тут все пункты с 1 по 6 имеют смысл.
Dorlas
28.06.2017 20:46Коллеги, позвольте вклинюсь в Ваше обсуждение:
- Есть файловые системы типа CoW, есть классические файловые системы (например, NTFS)
- CoW идеален для NAS-систем (т.е. получение и хранение резервный копий), так как изначально хорошо «дружит» со снапшотами — на CoW (например, ZFS), Вы можете делать снимок каждую минуту — и иметь на одной FS их сотни. И при этом не ощущать какого то деградирования скорости работы CoW
- На классических файловых системах либо снапшотов нет (например, ext2,ext3,ext4), либо они есть, но с оговорками и ограничениями (NTFS + VSS, UFSv2 и т.д.).
- Конкретно с VSS есть особенности — и для них справедливо все то, что описал gaf. Например, уже после 10-ка VSS снимков ощущается просадка скорости работы FS. 64 — это вообще потолок (по крайней мере находил это в официальных документах). И будет жутко тормозить. А все почему? Да потому, что алгоритм работы VSS такой — отдельный storage в System Volume Information, отдельные I/O при перемещении файлов в storage VSS, ограничения на объем и т.д.
Надеюсь, мысль понятна.
В CoW снапшоты действительно «наше все», позволяющее спасти 100% данных. В ситуации с переполнением — проблемы будут у «шифровальщика» — так как в случае исчерпания места — под изменяемые файлы не будет выдано место, а снимки как были — так и останутся в системе.gaf
28.06.2017 20:58Хотелось отметить вот какую мысль, что я целиком за снапшоты — они мне работу как-то сохранили. Но с ними надо быть очень внимательным.
Если я правильно понимаю, то LVM снапшоты они тоже CoW. Так у них считается, что если раздел для snapshot заполнен полностью, то snapshot непригоден?!
Да и 100% нельзя дать для любой файловой системы. Если на этой файловой системе лежит, к примеру, файл базы данных, то этот файл должен быть правильно закрыт этой самой СУБД, ну или сброшены буферы, а иначе есть шанс поймать в снэпшоте нецелостные данные.
Или другой пример — Вы перезаписываете большой файл, и во время копирования был сделан снэпшот, с какой вероятностью в файле будет каша?Dorlas
28.06.2017 21:07+1Не думаю, что LVM снапшоты можно назвать Copy-on-Write.
Скорее снапшоты в LVM по своей работе напоминают VSS в NTFS )))
В CoW если файлы были записаны и транзакция полностью завершена (как единая неделимая сущность), а также после этого был сделан «снимок» FS, файл никто не трогает. Ровно до тех пор, пока все снимки, в которых этот файл фигурирует, не будут удалены администратором NAS (или автоматизированным скриптом).
100% должны сохраняться файлы, которые уже были как транзакции записаны и сидят в снимках.
Касательно Ваших примеров — мы обсуждаем именно NAS/Backup системы. На них никто не крутит БД. А даже если и крутит — изменения в FS транзакционны. Либо изменение проходит до конца, либо FS откатывает его назад на предыдущую завершенную транзакцию.
Собственно СУБД делают ровно также.
Если Вы копируете файл на NAS в первый раз — то в процессе копирования в снапшотах файла нет. вообще. ни каши, ни файла. нет еще еще — транзакция не завершилась до конца.
Если файл полностью скопировался и транзакция закрылась полностью — в следующем снапшоте файл будет. И если его будет изменять шифровальщик — он будет править уже новый файл. А старый в снапшоте. В Read-Only.
gaf
28.06.2017 21:22А здесь https://wiki.archlinux.org/index.php/LVM#Snapshots LVM снэпшоты так и называют. Если я правильно понимаю, то CoW в рамках NAS или FS — это механизм работы с блоками, собственно как и на журналируемых ФС, журналы работают с блоками. Поэтому часть блоков может быть уже записана, а другая еще нет. Это работает на уровне блоков из-за следующего примера, допустим у нас есть большой файл с почтовыми ящиками пользователей. Если не фиксировать изменения пока файл открыт (а службы, да демоны могут закрывать свои файлы только при остановке), то в случае сбоя никакие изменения не сохраняться
Хороший пример указан здесь https://dev.mysql.com/doc/refman/5.7/en/backup-methods.html в разделе «Making Backups Using a File System Snapshot» — там прямо сказано, фиксируем изменения (через перевод ВСЕХ таблиц в режим для чтения), затем снэпшот и затем востановление режима работы. Понятно, что после запуска процедуры создания снимка, БД можно разблокировать, недожидаясь завершения его создания.
bbk
28.06.2017 22:01Dorlas gaf Давайте я внесу немного ясности. На LVM, VMware ESXi, MS Hyper-V используют CoW (Copy on Write). Это очень не совершенная технология, которая очень тупит только от факта самого снэпшота и тупит когда вносится много изменений. И для NAS она тоже тупит.
NetApp WAFL и ZFS это файловый системы построены по технологии RoW (Redirect on Write). Эти технологии вовсе не тупят ни первая ни вторая. ZFS не тупут потому что на самом деле это стыбренная у нетапа технология WAFL когда-то давно.pansa
29.06.2017 00:52Воу. А можете дать немного зацепок про то, что ZFS стыбрила технологию у NetAPP?
Еще впервые вижу «RoW». Быстрое гугление мало что находит. Даже в официальных статьях используется «copy on write». Откуда это?Dorlas
29.06.2017 15:42+1Нашел кое-что:
https://news.ycombinator.com/item?id=9129784Dorlas
29.06.2017 15:45+1Основной пруф тут:
http://www.theregister.co.uk/2008/10/07/sun_gets_netapp_patent_invalidated/
Dorlas
29.06.2017 10:12Давайте я внесу немного ясности. На LVM, VMware ESXi, MS Hyper-V используют CoW (Copy on Write).
Помоему еще больше нас запутали )))
CoW в моем понимании — когда любая записываемая информация при работе файловой системы, обязательно пишется на пустые блоки (либо блоки, помеченные FS как удаленные). При этом запись идет транзакционно (в три этапа — запись — о том, что хотим записать, сама запись, запись о том, что уже записали, контрольные суммы сверили и все хорошо). И только после того, как транзакция прошла — старые данные (предыдущая версия файла), помечается как не нужная. И CoW эти блоки может перезаписать при необходимости.
Т.е. — CoW — это работа самой файловой системы. Без снапшотов. Сейчас так работают ZFS, BTRFS, ReFS (Windows Server 2012/2016).
Теперь о снапшотах — раз файловая система каждый раз анонсирует для записи новые блоки — при наличие снапшота — старые блоки (и файлы) не трогаются вообще. Просто где-то во внутренних структурах-таблицах FS они помечаются, как относящиеся к тому или иному снапшоту (при его наличие). И получается, что наличие снапшотов на CoW FS не вносит никаких OverHead-ов. Так как что без снапшота, что с ним — FS не делает ничего дополнительно.
Про LVM думаю и так все знаете (как она со снапшотами работает).
А вот VMware ESXi и Hyper-V тут вообще с какого перепугу возникли?
Да, они умеют делать снимки виртуальных машин — но блин, они создают отдельные файла на используемой FS. И в них пишут изменения. С какого перепугу это CoW FS ???
Hyper-V может быть на NTFS. VMware VMFS тоже вроде бы ни разу не CoW…
И кстати да — мне тоже интересно — есть ли в сети источники, подтверждающие воровство разработчиков SUN? Буду благодарен за ссылки.bbk
29.06.2017 10:15dorlas важно не то как оно в вашем понимании, а как оно на самом деле ;)
Ещё раз, ZFS это не CoW.
Про Vmware почитайте в официальной документации, как они сами называют свои снепшоты. Могу сэкономить ваше время, они называют их CoW.Dorlas
29.06.2017 10:20Ещё раз, ZFS это не CoW.
Вот прям на 100% ??? :)))
http://docs.oracle.com/cd/E19253-01/819-5461/zfsover-2/
With a transactional file system, data is managed using copy on write semantics. Data is never overwritten, and any sequence of operations is either entirely committed or entirely ignored. Thus, the file system can never be corrupted through accidental loss of power or a system crash.
bbk
29.06.2017 10:58Почитайте вот эту статью и не путайтесь ;)
https://habrahabr.ru/post/244923/Dorlas
29.06.2017 15:53https://storagegaga.wordpress.com/2011/10/01/ontap-vs-zfs/
И все таки я с Вами не соглашусь )))
PS: Сколько людей — столько и мнений )))bbk
30.06.2017 14:18https://storageswiss.com/2016/04/01/snapshot-101-copy-on-write-vs-redirect-on-write/amp/
bbk
30.06.2017 14:23Снепшотирование начало ассоциироваться с термином Copy on Wite, в связи с чем некоторые люди (ошибочно) начали его использовать как имя нарицательное.
Dorlas
30.06.2017 15:01Итого что мы имеем:
https://en.wikipedia.org/wiki/Copy-on-write
Две техники снапшотов:
When implementing snapshots, there are two techniques:
The original storage is never modified. When a write request is made, it is redirected away from the original data into a new storage area. (called «Redirect-on-write» or ROW)
When a write request is made, the data is copied into a new storage area, and then the original data is modified. (called «Copy-on-write» or COW)
И общее название принципов работы файловых систем — Copy-on-Write (CoW):
https://en.wikipedia.org/wiki/Comparison_of_file_systems
Итого какой я для себя сделал вывод:
- ZFS — файловая система с CoW семантикой
- В ZFS используются стапшоты по методу RoW
На данный момент в 99% источниках говоря про ZFS, BTRFS, ReFS пишут CoW — имея ввиду особенность работы файловой системы.
bbk
28.06.2017 21:49Чтобы вы знали, у нетаповских снэпшотов
во-первых если включить снэпшоты, то по-умолчанию ставится 5% для снэпов
во вторых, это не значит, что если установлено 5%, что снэпы перестают работать когда они переваливают заданный порог 5%, они продолжают себе преспокойно расти дальше, хоть до 100%. Заданное значение в 5% всего лишь порог после которого система начинает слать алерты администратору.gaf
28.06.2017 21:51Это конечно хорошо. Опять же если есть куда расти.
bbk
28.06.2017 22:05Это не просто хорошо, это нивелирует многое вами сказанное.
Ещё раз, я здесь не говорю про LVM, Базы данных и ещё какие-то там решения и ФС.
Я говорю об законченном промышленном, защищённом, комплексном, высокопроизводительном и не дешевом решении для корпоративного NAS хранилища по народному «файлопомойка», на базе NetApp FAS/ONTAP.
bbk
28.06.2017 22:37Так а что в этом случае должна включаться магия? Да, нужно место для хранения дельты.
Тут в помощь нетаповские технологии эффективности:
- Компакция
- Компрессия
- Дедубликация
Но даже с ними место для снэпов все-равно нужно.
Если мы говорим про SSD, то у нетапа есть отличная технология FabricPool позволяющая холодные снэпшоты смещать в дешевое S3 хранилище.
bbk
28.06.2017 21:50О каких кешах речь? Пример конкретно про корпоративный NAS для файловых помоек!
gaf
28.06.2017 21:55К примеру, на таком сервере может лежать файловый 1С, Гарант или большие схемы из автокада. А кэши тут будут пользовательские — открытый 1С файл, обновление баз Гаранта или любая другая запись большого файла
bbk
28.06.2017 22:06Какой 1C? Ну ёлы палы Сан Саныч!
Я говорю статья про файлопомойку!gaf
28.06.2017 22:12-1Ну если хронить вордовые файлы, да картинки из пэйнта, то да — снэпшоты хорошо. Правда, впрочем как и команда copy по планировщику или cp по крону =)
bbk
28.06.2017 22:19+1Команда copy
во-первых будет плодить вам данные, это вам не блочная дельта, как у снэпа: 2 копии — 2 набора данных; 3 копии — 3 набора и тд. В то время как снэп хранит только дельту, то есть изменения.
Во-вторых когда у вас повреждено пару файлов, восстановление будет достаточно простым в приведённом вами случае. Если же данных повреждено много — то снэп будет на много быстрее, ведь восстановление снэпа всегда секудна, даже если это 16 ТБ.
bbk
28.06.2017 22:10Ну коли вам так уж сильно охота, то вы можете прикрутить свой файловый 1С к нетаповскм снапшотам при помощи бесплатного фреймворка SnapCreator. Для этого как со стороны фреймворка, так и со стороны 1С нужно будет дописать интеграцию, чтобы сбрасывать кеши и захватывать их в нетаповскй снапшот. Написать такую интеграцию вполне реально, но большие компании не хотят браться за такие мелкие решения, так что это делается в индивидуальном порядке самим заказчиком, если он так хочет изобрести велосипед.
Но если вы хотите промышленное решение, то ваш выбор не «файловая 1С», а «1С на Базе данных», Oracle или MS SQL. А вот для этих двух решений у нетапа есть интеграция, которая позволяет скидывать кэши и захватывать их в нетаповские снапшоты. И практически все из перечисленных в статье софтов резервного копирования могут это делать.bbk
28.06.2017 22:16Кстати в случае MS SQL, база может жить даже на нетаповской SMB файловой шаре (с включённой функцией continuous availability). А софт SnapManager for MS SQL позаботится о консистентности, чтобы нетаповске снапшоты захватывали кеш.
SergeyUstinov
А нет такого же текста на английском?
bbk
Неа. Это не перевод, статью написал я.
SergeyUstinov
Жаль. У нас тоже Veeam используется, но сисадмин только английский и немецкий понимает…
bbk
Переводите ему значит :)