Объявлены планы EOL для моделей G6

Итак, с появлением нового поколения G7, пришла пора прощаться с моделями G6.
Официально объявлены планы постепенного ухода шестого поколения.
Как вы знаете, «уход» это многостадийная процедура.

Датой EOS — End-of-Sale назначено 31 января 2020 года. В этот день будут проданы последние модели G6, и дальше возможно, только если повезет, перехватить отдельные модели, в определенных конфигурациях, задержавшиеся на складе. Если вам нужно именно G6, например для установки ноды в имеющийся chassis G6 — спрашивайте сейла о доступности. Но в целом следует понимать, что EOS — это все.
Дата последней отгрузки — 28 февраля 2020 года.
Следует также помнить, что узлы Nutanix разных поколений прекрасно смешиваются в одном кластере, ограничения, описанные выше, только на chassis, они иногда у SuperMicro меняются между поколениями.

Далее, как я уже не раз говорил, начинается пять лет срока поддержки после EOS, которые состоят и 4 лет полной поддержки, и последнего года, в который выпускается только security updates.
Дата End-of-Maintenance является 31 июля 2023 года, в этот день прекращается выпуск Maintenance releases и Patch releases для платформы G6.
Последним днем, когда моно обновить сервисный контракт является 31 января 2024 года.
И, наконец, через год, 31 января 2025 года заканчивается поддержка этих моделей вовсе.

Nutanix AOS 5.11 — что нового?

А теперь, раз нас в компании много, тут будут появляться не только мои посты, но и моих коллег.
И для начала — о новинках в вышедшей в конце июля версии AOS 5.11 от Владимира Денеко.

Представлены обновления для следующих продуктов:

— AOS версии 5.11

— Prism Central версии 5.11

— AHV версии 20170830.301 (давно ожидаемое обновление самого ядра гипервизора)

— Calm версии 2.7.1

— Objects версии 1.0 (Бывший Buckets, перешедший в GA статус)

Основной список изменений и улучшений:

Добавлен Storage QoS на уровне виртуальной машины.

То, что просили многие, и что часто мешало нам соответствовать некоторым тендерным требованиям, вот оно доступно. Начиная с релиза 5.11 администратор системы (нужна лицензия уровня AOS Professional и Ultimate), может сам выставлять rate limit на уровне отдельных виртуальных машин.

Ограничения на данный момент:

— Storage QoS не поддерживается для in-place, out-of-place восстановления.

— При клонировании виртуальной машины с заданными параметрами Storage QoS, параметры не передаются и их нужно задавать на клоне отдельно.

— При использовании linked clone для родительского образа нельзя применить Storage QoS.

— Нельзя его применить и к виртуальной машине с подключенной volume group.

— Storage QoS не поддерживается для Metro, синхронной репликации и файловых сервисов AFS.

Увеличен лимит дисковой емкости узла до 120Тб

Начиная с версии 5.11 появилась поддержка емкости узлов в 120TB.

Как известно, все диски узлов физически презентованы CVM. Чтобы обеспечить поддержку увеличенной емкости, необходимо закладывать увеличенные требования по RAM для CVM.

В зависимости от планируемого или используемого функционала, CVM необходимо выделение такого количества ресурсов:

Указанные параметры покрывают использование сразу всего функционала Nutanix (capacity tier deduplication, performance tier deduplication, redundancy factor 3).

Добавлена поддержка сетевой сегментации для траффика iSCSI Volumes

Для уже работающих сервисов необходимо руками перенастроить сети:

nutanix@cvm$ acli vg.detach_external vg_name initiator_network_id=old_vm_IP
nutanix@cvm$ acli vg.attach_external vg_name initiator_network_id=new_vm_IP

Добавлена поддержка DR Runbook для ESXi

DR Runbook появились в версии AOS 5.10 как инструмент автоматизации планов восстановления. Совместная связка категорий и protection policy позволяет просто и удобно защищать связки виртуальных машин по тому или иному типу. Версия 5.10 поддерживала только AHV, в версии 5.11 добавлена поддержка ESXi. Теперь у нас есть свой полноценный Site Recovery Manager с планами восстановлениями, тестированиями, failover и failback.

Про это также напишем отдельную статью.

Добавлена поддержка VMware Site Recovery Manager для NearSync Replication

Теперь можно создавать задания NearSync для репликации SRA. Задания могут сосуществовать с задания на асинхронную репликацию. Поддерживается только SRA 2.5.

Добавлена возможность настройки политик замещения и репликации установочных образов для распределенных систем

Как известно Prism Central позволяет пользователям загружать образы виртуальных машин со своей рабочей станции или удаленного сервера. В случае распределенной инфраструктуры кластеров часто возникает ситуация, что пользователю отдельного филиала нужен установочный образ именного определенного дистрибутива и здорово, чтобы он был “поближе” для использования. Используя категории, которые мы можем повесить на уровень установочных образов, или отмечая, что образ нужен именно в конкретном филиале, мы можем распространить образ на все необходимые кластеры для дальнейшей работы.

Добавлена поддержка UEFI для виртуальных машин на базе AHV

Пользователи давно просили поддержку UEFI в VM.
В данный момент полностью поддерживаются виртуальные машины на базе AHV, частичная поддержка виртуальных машин, которые мигрировали с кластеров Hyper-V.

Добавлен новый функционал X-Play для автоматизации реакций на события

Функционал требует лицензии Prism Pro. X-Play представляет собой простой инструмент автоматизации решения рутинных задач. Для этого пользователь создает Playbook, в котором описывает происходящие события в системе и что делать на выходе. Событием могут быть как alert, так и действия отдельных пользователей. Реакцией на событие могут быть как простые уведомления на почту или в Slack, так и действия над виртуальной машиной, например добавить ей ресурсов, если вдруг перестало хватать.

Так это выглядит в действии

Добавлено множество настроек Flow по экспорту/импорту конфигурации и интеграции со сторонними системами

Теперь можно экспортировать и импортировать security policies, что можно использовать как простой инструмент восстановления рабочей конфигурации в случае критического сбоя или событий информационной безопасности. Так же это способ распространения политик безопасности на типовые конфигурации филиалов в случае использование нескольких независимых инсталляций Prism Central.

Состоялся GA-релиз S3-совместимого хранилища Nutanix Objects

Более подробно о решении мы расскажем позже.

Что интересного уже есть сейчас:

— возможность использования хранилище емкость до 2Тб бесплатно, чего может оказаться достаточно для резервного копирования небольших виртуальных машин или поиграться DevOps.

— поддержка интеграции с решениями производителей резервного копирования таких как Commvault, Veritas NetBackup, Veeam, HYCU и других.

— упрощенная процедура развертывания через Prism.

— поддержка path-style и virtual hosted-style для доступа к корзинам и объектам.

— поддержка доменной аутентификации для пользователей.

— поддержка Object Versioning, Lifecycle Policies, WORM (Write Once Read Many) разделов.

Ограничения на данный момент:

— максимальная емкость узла 120Тб (что и понятно, см выше о максимальной емкости дисков узла).

— функционал не поддерживается для узлов с NVMe дисками.

— перерегистрация Prism Central/Element не поддерживается.

— смена IP адресов CVM, MSP, PC не поддерживается.

Новые релизы AOS и «новая метла»

Раз-два-три-четыре-пять, начинаем возрождать!
С весны ничего не писал в блоге, сперва по объективным причинам, потом просто было лень («угасание блога» — страшная болезнь. Стоит перестать писать регулярно, и — все, «восстановить режим» получается очень тяжело и не у всех). Пришла пора восстановить регулярность.
Сперва краткий отчет «как я провел лето». «Я» — в смысле российский Nutanix, где я работаю. У нас теперь много новых людей (кто следил за вакансиями в linkedin видел кого и сколько мы набрали), и куча новых планов. За лето у нас появилось несколько крупных и ключевых для российского рынка заказчиков (на миллионы в долларах, BTW), а в компании глобально и в продукте произошло много важного.
Начну же я сегодня с того, что проясню вопрос с софтверными релизами.
В прошлом году я рассказывал, что мы решили, вслед за рынком софта, перейти на Time-based Releases, это, по-простому, «как в Ubuntu», ну или в Windows 10+, то есть в определенный момент года входит релиз, привязанный к календарю, а не, как было раньше, к готовности фич. И мы решили, что у нас будет линейка «LTS», выпускаемая раз в год, и линейка STS, выпускаемая раз в квартал. В LTS пойдет весь «stable» и GA, а в STS будет выходит все с пылу с жару, новые фичи и bleeding edge с Tech Preview. А потом они в конце года вольются в очередной LTS. И все выглядело красиво.

Но тот, кто следит за выходом релизов в этом году уже знает, что схема эта у нас в этом году работала как-то странно. Да, в декабре вышел 5.10, LTS, но с STS-ами была беда, и вовремя они не вышли. Хуже того, LTS получился, ну-у.. в общем патчлевел апгрейды на него выходят уже полгода.
Поэтому первый STS в этом году получил номер 5.11, и вышел он только в самом конце июля. Одновременно с этим, было принято решение подготовленный 5.12 не выпускать в паблик, и пропустить 5.13 вовсе, дав возможность разработчикам тщательнее вылизать код. А следующий, 5.14 будет в конце года. А соответствующий LTS 5.15 вероятно смещается на первый квартал 2020 года. Так что «Пьянству (и багам) — бой!» Но все ради качества кода.

Следующим постом я опубликую краткий обзор новинок в 5.11. А пока вот какие изменения в полиси релизов приняты, начиная с этого года.

  • LTS — это не Long-time Stable, это Long-time Support.
  • Термин LTS относится к периоду, в который оказывается поддержка и maintenance (software update), это 15 месяцев Maintenance с момента выхода релиза, и плюс 6 месяцев Support. После чего пользователь должен обновиться на следующий LTS release.
  • LTS будет выпускаться каждый год.
  • STS будет выпускаться 2-4 раза в год.
  • И LTS и STS могут иметь так называемые Maintenance releases, в случае необходимость устранения ошибок, например.
  • LTS Maintenance Release может выпускаться вплоть до момента выхода следующего LTS плюс 3 месяца (см. выше почему так)
  • STS Maintenance Release может выпускаться вплоть до выхода следующего STS release.

Таким образом, мы планируем чуть меньше релизов в этом году, но со значительно улучшенным качеством. Ибо «Лучше меньше — да лучше»!

The Nutanix Design Guide

the-nutanix-design-guide-first-edition

Полезное руководство по множеству аспектов реализации архитектуры IT системы с использованием HCI Nutanix.

Nutanix + HPE: пост с деталями

Тут был пост, который мой провайдер блога стер в процессе восстановления из снэпшота. Восстановлю позже. Если у кого-то из подписчиков он сохранился в почте — напишите мне на romx@mail.ru, я переопубликую его, или ждите, когда я его напишу заново.

Саппорт Nutanix

Сегодня саппорт в Nutanix это:

  • более 500 сотрудников по всему миру,
  • в 10 центрах поддержки (с востока на запад: Токио, Сидней, Пекин, Пуна, Бангалор, Белград, Амстердам, Дархэм, Мехико и Сан Хосе).
  • 150 сервисных складов по всему миру (плюс склады партнеров и ASP).
  • 20 языков поддержки глобально, включая русский.
  • служба поддержки сегодня решает более 150 тысяч кейсов разных уровней ежегодно.

Сейчас в Nutanix существуют два плана техподдержки: Production и Mission Critical.

Основные предоставляемые услуги у них идентичны, преимущества Mission Critical support level это:

  • Время реакции, для кейса уровня P1 (Critical) — 30 минут, вместо 1 часа (для более низких приоритетов — 1 час и 2 часа соответственно).
  • Кейс сразу отправляется на уровень Senior systems Support.
  • По результатам кейса высоких уровней приоритета проводится Root Case Analysis, позволяющий установить причины возникновения ситуации.

Для обоих уровней поддержки обеспечивается Hardware Replacement уровня Next Business Day (NBD).

Подробнее вопросы саппорта разбираются тут:
https://www.nutanix.com/support-services/product-support/faqs/

Официальный Nutanix Support Guide тут: http://go.nutanix.com/rs/nutanix/images/nutanix-support-guide.pdf

Мы в Nutanix очень серьезно относимся не только к «количественным» параметрам саппорта, но и к его качеству. Анализ показывает, что:

  • Один негативный отзыв «весит» для пользователя в среднем как 12 позитивных.
  • Пользователь обращает внимание (и руководствуется в принятии решения) на негативный отзыв более чем в два раза чаще, чем на позитивный.
  • Плохое качество поддержки и сервиса в 89% случаев приводит к тому, что пользователь перестает покупать продукт и в 59% случаев меняет бренд.

Критерий качества поддержки — интегральный индекс NPS, Net Promoter Score, имеющий значение от +100 до -100. Он составляется по опросу пользователей в отношении их удовлетворения работой поддержки соответствующего бренда. Ответы от 7 до 10 баллов по 10-балльной шкале трактуются как +1 балл, ниже 7 в -1 балл. В течение 5 лет Nutanix удерживает индекс NPS в районе 90, при этом средняя по индустрии его величина в 2017 году, например, была 22.

 

Nutanix — теперь и на Huawei!

Вчерашняя новость хотя и была известна по внутренней информации, но все равно случилась неожиданной. Huawei объявил, что начинает выпускать OEM-Nutanix на базе своего сервера FusionServer 2288H V5. Не только на нем, но вчера объявили пока доступной только эту модель.

Хорошая новость для «импортозаместителей», и не очень приятная для наших коллег из Lenovo. Ну, что делать, бизнес есть бизнес, а у Lenovo было два года форы. Впрочем, конкуренция для конечного покупателя — это всегда очень хорошо.

Итого, по состоянию на середину марта Nutanix можно купить следующими способами:
* От самого Nutanix, в виде «программно-аппаратного комплекса» (самый простой, прямой и, как правило, самый недорогой вариант), на базе платформы Supermicro, поставляемой SM прямо в Nutanix, и продаваемой им пользователю как готовое решение, с полной поддержкой из «одной точки», как железа, так и софта.

* От DellEMC, как OEM-продукт Dell XC.

* От Lenovo, как OEM-продукт Lenovo ThinkAgile HX.

* От Fujitsu, как OEM-продукт PRIMEFLEX.

* У IBM как IBM CS на платформе Power8.

Это все будут также «программно-аппаратные комплексы»

Далее, можно купить «платформу» и «софт» отдельно. Вот эти варианты:

* У DellEMC как продукт Dell XC core, то есть, фактически, просто сервер Dell Poweredge определенной конфигурации (а затем у партнера Nutanix — лиценизию на эту систему).

* У Lenovo, аналогичный core-продукт.

* Недавно к ним также добавился Intel, на сертифицированные серверные платформы (Intel Data Center Blocks) которого также можно купить и поставить Nutanix, приобретя лицензию у партнера Nutanix.

* Наконец, можно приобрести лицензию Nutanix, и поставить его на некоторые конфигурации HPE ProLiant и Cisco UCS, в соответствии с нашим HFCL (Hardware and Firmware Compatibility List). Это, по факту, самый сложный и, парадоксально, обычно самый дорогой для обычного пользователя вариант.

И вот теперь к этому добавился Huawei. Официальный пресс-релиз об этом тут:
https://www.huawei.com/en/press-events/news/2019/3/huawei-nutanix-hyper-converged-infrastructure

Пример «живой» системы

Пример «живой» системы, результатами на тестовом «прогреве» которой перед сдачей клиенту поделились коллеги.

Nutanix VDI test results

1300+ VDI десктопов на 24 хостах Lenovo HX3720. Рандомная по чтению-записи нагрузка, 600K+ cluster IOPS, 4.4 GBs трафика, 1 ms latency при 80% загрузке CPU.

Являются ли снэпшоты бэкапами?

Когда-то я довольно часто переводил статьи тогда сотрудника NetApp Димитриса Крекоукиаса, он умный блоггер, с широким кругозором, и, что важно, одновременно с этим (а это встречается нечасто), умеет развернуто и интересно выражать свои мысли.

С тех пор прошло много времени, Димитрис перешел из NetApp в Nimble, а теперь с ним, кажется, и в HPE, и, как и я, подзабросил блог. Но всякий раз, когда у него в нем появляются посты, они интересные и заставляют задуматься.

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

July 24, 2018 by Dimitris

Снэпшоты — это бэкапы? И что вам нужно предпринять для защиты ваших данных?

Идея этого поста родилась из дискуссии в Твиттере. Я уж думал, что подобные темы давно в прошлом, но скоро стало ясно, что это не так. Поэтому я решил пролить некоторый свет на вопросы защиты данных, в прежней моей жизни мне приходилось заниматься резервным копированием в по настоящему безумных масштабах.

Итак, моя позиция: Неважно, как фича называется — вы можете, используя ее, восстановить ваши данные? И, если ответ «да», то как быстро и по какому сценарию? И какие возможные минусы решения?

Начните с составления списка возможных ситуаций!

Перед тем, как засесть за разработку вашего решения для бэкапа/DR/BR, начните с того, что обдумайте ВСЕ от чего вы хотите предусмотреть защиту ваших данных. Например вот две очевидных ситуации:

      • Случайное удаление данных
      • Потеря сайта целиком

Но подумайте также и о ситуациях не совсем обычных, но которые тоже приведут к потерям данных.

      • Акт корпоративного саботажа, или злонамеренный админ, который удаляет ВСЕ ваши данные на сторадже, и ВСЕ ваши бэкапы, на ВСЕХ сайтах (это займет время, но это потенциально возможно, поэтому может случиться).
      • Хакер завладевает админской учеткой и удаляет ВСЕ ваше облако, когда вы только закончили миграцию в облако. (Такое уже тоже было).
      • Вирус-шифровальщик закончил шифрование всех ваших данных, и теперь просит денег.

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

Почему «стратегия 3-2-1» — недостаточна.

Главное правило, которое рекомендуют при разработке стратегии бэкапа принято называть «стратегией», или «правилом 3-2-1». Это означает:

      • 3 полных копии данных
      • На 2 разных носителях
      • И одна из этих копий — на удаленном сайте

Звучит здорово, и легко запомнить, но подумайте о том, что ваш админ имеет доступ ко всем этим копиям, и потенциально может удалить их ВСЕ.

Снэпшоты — это бэкапы. Но просто этот вариант не покрывает ВСЕ возможные случаи защиты данных.

Вопрос не столько в том, являются ли снэпшоты резервными копиями. Они ими являются. Но более важно то, от чего именно они защищают ваши данные.

Например, довольно просто сделать систему, соответствующую «правилу 3-2-1» просто с помощью снэпшотов:

      • Множественные (виртуальные) копии, хранящиеся локально и удаленно, не просто «три копии»… (обычный профиль использования снэпшотов)
      • Репликация некоторых снэпшотов на другую систему (и убедитесь, что используемая вами технология создания снапшотов позволяет вам иметь полностью раздельные политики retention для источника и получателя репликации)
      • И одна из используемых систем расположена на удаленном сайте (идеально — в сотне километров от основного).

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

Главная проблема со снапшотами состоит в том, что админ системы хранения может просто, легко и быстро уничтожить все снэпшоты, как на источнике репликации, так и на удаленной системе-получателе репликации.

Поэтому основная тема спора состоит не в том, что «бэкапом является», а что — «нет». Основная тема обсуждения тут — кто и как контролирует процесс создания резервных копий, неважно, как именно эти копии созданы и где хранятся.

Что вы можете сделать против злонамеренного вмешательства

Здесь вы уже должны согласиться со мной, что именно пресловутый «человеческий фактор» является наиболее опасным фактором проблемы резервного копирования, а не какая-либо технология как таковая.

Большинство людей вообще не задумываются о данной проблеме.

Осознайте факт того, что роль backup admin — это САМАЯ опасная роль в IT!

Задумайтесь над этим фактом. ПО бэкапа, по своему определению:

      1. Управляет созданием резервных копий (включая создание снэпшотов и репликации, в некоторых решениях)
      2. Имеет агентов на хостах, которые, обычно, имеют полный неограниченный доступ ко всем пользовательским данным, включая права на перезапись всех данных. Или, как вы думаете, работает процесс восстановления?

То есть backup admin может легко сделать следующее:

      1. Удалить все снэпшоты на массиве хранения (если бэкапный софт управляет процессом создания этих снэпшотов) – даже если он не является админом хранилища!
      2. Сделать так, чтобы все ленты (если вы используете ленты) за прошедшие месяцы были отозваны из хранилища и стерты (а вы думали, что достаточно записать бэкапы на другой носитель, чтобы их обезопасить).
      3. Воспользоваться агентами бэкапа, чтобы полностью стереть все серверы.
      4. Стереть базу бэкап-сервера и все копии данных.
      5. [Бонус] Сделать копию данных для себя, чтобы оставить возможность шантажа – вы же не забыли, эта роль имеет доступ ко ВСЕМ серверам. Ему не нужны пароли глобального админа (доменные админы, вы правда считаете, что права вашей учетки абсолютно необходимы для запуска агента резервного копирования?)

И вот результат – все данные, и все бэкапы на лентах за последний месяц, и все снэпшоты — все уничтожено.

А теперь представьте, что это случилось с вами, и ВАМ надо восстановить данные в получившейся ситуации. И что такая потеря данных будет означать для вашей компании? 

Определенные ключевые сотрудники должны проходить особую углубленную проверку

Начините рассматривать администраторов систем хранения и резервного копирования как лиц, подлежащих самому строгому контролю. И, кстати, то же самое для обладающих доступом к логинам и реквизитам доступа к облачной инфраструктуре…

Держите по крайней мере одну копию данных полностью недоступной для админов

Мы живем во времена программ-вымогателей, а то и еще чего похуже. Обдумайте некоторые из перечисленных идей:

      • Если вы используете ленты для оффсайт-хранения, используйте ДВЕ разных компании, предоставляющие вам услуги хранения лент, причем админы должны иметь доступ к хранилищу только ОДНОЙ. Только глава компании (например CEO, или исполнительный директор), должен иметь права доступа к хранилищу другой.
      • Используйте 3 локации хранения, а не обычных 2. Одна из трех должна располагаться очень далеко от других, идеально — другой континент (а в будущем может быть и геостационарная орбита?).
      • Если вы не используете ленты, у вас должна быть одна полностью независимая команда админов, отвечающая за третью копию ваших данных в отдельном датацентре. Массив хрнения в этом датацентре должен быть полностью недоступен для любого из админов остальных двух сайтов хранения. Сама копия должна создаваться полностью иным методом, то есть НЕ вашим обычным бэкапным софтом, ни штатным механизмом репликации дискового массива. Обычные админы НЕ должны иметь доступа к этому дополнительному механизму репликации и создания резервной копии, идеально — он должен быть от них полностью скрыт. Кстати, это не так просто сделать.
      • Подумайте о использовании лент как дополнение к всем прочим вариантам хранения, если вы их еще не используете. Да, все сегодня ненавидят ленты, но в данном случае это как раз задача для них.
      • Подумайте о возможности использовать настоящее WORM решение (такое, запись на которое никак нельзя изменить).

Я могу продолжать, но в целом вы уже поняли ход рассуждения.

Может быть пришла пора нового стандарта, «правила 4-3-3-3-1»?

      • 4 копии данных
      • В 3 локациях
      • Управляемых 3 разными системами создания копий
      • Администрируемых 3 разными командами, без пересечений в правах между ними.
      • И 1 копия, остающаяся полностью недоступной для почти любого в компании.

 

А для фанатов «облаков», это означает использование AWS, Azure и Google cloud вместе, одновременно (вот вам, например, ваши необходимые «три локации»).

И в заключение: остерегайтесь стать «слишком параноиком»

Чтобы уберечься от этого, задайте себе несколько вопросов:

      • Вы правда готовы заплатить за придуманное решение?
      • Во что паранойя обойдется вам и вашей компании, учтите и денежные затраты, и потерю оперативности бизнес-управления, а также темпов развития?
      • Рассматриваете ли вы ситуации отказов в порядке вероятности их появления, или сразу смотрите на самые экстремальные?
      • Доверяете ли вы людям, достойным вашего доверия?

Источник <http://recoverymonkey.org/2018/07/24/are-snapshots-backups-and-what-do-you-need-to-protect-against/>