Резервное копирование *

Администраторы кластеров kubernetes сталкиваются с задачей сохранить конфигурацию ресурсов из пространства имен и перенести в другой кластер, или же сделать резервную копию нестабильной тестовой площадки. С этой задачей без проблем справляется бегло написанный в терминале односторчный скрипт с утилитой kubectl, но что если надоело каждый раз тратить пару минут времени на очередное написание скрипта. Так и появилась утилита kube-dump, по сути это утилита которая умеет только одно - дампить ресурсы кластера.

Сегодня я решил поразмышлять на тему – зачем нам это надо (на примере Notion)? Пост – чистая философия.

Вообще, я к Notion не имею никаких претензий. Никто же не предъявляет претензии молотку… Просто это первый сервис, который мне попался, который обладает огромным функционалом.

Когда я в первый раз его установил и узнал о его возможностях, то радости не было предела. Я понял, вот оно, вот то место куда я могу перенести свою жизнь.

И вот он - Я. По классике жанра сразу создал 2 пространства – личное и рабочее. Сами понимаете - жизнь именно так и делится. Вот тут мои книги, вот тут фильмы, тут заметки, тут лайфхаки, тут идеи, тут полезное что-то, рецепты, тренировки, уроки, курсы, друзья, семья, машина, животные, хобби… И самое вкусное – планы!

Начнем с простого. Книги, фильмы, музыка. Создал каталоги: что смотрел, что читал, что слушал, что планирую читать, смотреть, слушать. Даже какие-то рейтинги придумал, что понравилось, а что не очень, оценки от 0 до 5, нет до 10, так объективнее, теги по жанрам. Даже где-то писал комментарии.

Потом. Списки уроков, курсов, полезных материалов, гайдов, мануалов. Всё разложил по полочкам, теги опять же.

Друзей оцифровал. Фото там, дни рождения, дни рождения детей, ссылки на соцсети, контакты… Теги…

Хобби, животные, машина, всё оцифровал, навешал тегов, добавил ссылок на ресурсы…

Работа! Тоже все оцифровал по аналогии. Прям всё! В общем, всё по феншую.

 Планы – наше спасение и наша погибель. Notion помогает раздуть их до вселенских масштабов. Пришла в голову идея – в планы ее, задачи к ней, подзадачи к ним, сроки каждой задаче/подзадаче, ответственных лиц и всё такое. Это все на волне эйфории от гениальности идеи. Чем она гениальнее мне казалась, тем больше места она занимала в Notion.

Что получил в итоге.

Сначала был вопрос – а на хера мне всё вот это вот? Кому интересно, да и в принципе кто это увидит, что я читал, смотрел, слушал и как у меня всё это отсортировано? Все эти рейтинги для самого себя? Если мне понравился фильм, то на кинопоиске я поставил оценку и забыл про него. С книгами еще проще: прочитал – удалил. Всё. Нет книги. Музыка. Вся она в яндексмузыке в подборке понравилось (и то, что-то удаляю, что-то добавляю). Всё. На хрена она в Notion?

Помните, как во второй половине 90-х один известный тогда профессор хрипло пел “Бегут года, и грусть, печаль в твоих глазах, а я не знаю что тебе сказать”. Так вот, года действительно бегут, а грусть-печаль в глазах из-за того, что гонка технологий уже достигла таких скоростей, что успеть за ними не может даже самый ловкий мангуст. Правда, некоторые вещи категорически отказываются меняться, и раз уж эта статья из блога компании, занимающейся бекапами, видимо, что-то не меняется в бекапах. А проблема, о которой хочется поговорить сегодня - это выбор сервера, который эти бекапы и будет делать. Все как-то привыкли думать только о размере стораджа, куда их предстоит складывать, а то, что процесс бекапа - это типичная задача обработки большого массива данных, которая жрёт RAM и CPU как не в себя, многие то ли забывают учесть, то ли по неопытности упускают этот момент. Так что сегодня учимся подбирать сервера для бекапов не только по размеру дисков. Или, как говорят зарубежные коллеги: backup server sizing best practices.

И да, в посте будет математика. Целых две формулы. Я предупредил.

Restic — хорошо известная программа для резервного копирования. Она достаточно проста, чтобы переноситься на любую ОС, и, вероятно, поэтому с ней не прилагается полноценный пример настройки на среднестатистической Linux-системе. Исправим это данным постом.

Поставим задачу следующим образом:

1. Автоматический бэкап запускается ежедневно.
2. Бэкап хранит только важные файлы и данные.
3. Бэкап также включает в себя содержимое баз PostgreSQL, которое можно восстановить psql -f.

Уже, наверное, только ленивый не повторил десять раз, что ковид послужил катализатором взрывного роста как самих облаков, так и разного рода облачных сервисов. Словом, всё, что как-то относится к облачной теме, стало резко расти и увеличиваться в объёмах. Причина банальная: всех разогнали по домам, и для многих возросшие нагрузки на их сервисы послужили тем самым громом, после которого надо перекреститься и начинать уже что-то делать. Вот все и начали срочно мигрировать. У кого-то процесс перехода прошёл гладко, у кого-то не очень, однако все мы как-то научились жить в новой реальности и теперь, когда вау-эффект прошёл, многие компании стали переключаться с чисто инфраструктурных вопросов на вопрос сохранности данных. Когда твои сервера у тебя под боком, ты сам себе хозяин и молодец. А что делать, когда твои продукты крутятся не пойми где? Довериться надежности облака? Бекапить облачные сервисы другими сервисами этого же облака? Бекапить из облака на землю? Бекапить одного облако в другое? Вопрос важный, ответ не ясен, давайте разбираться.

1. От чего защищаемся?

1. Физические сбои: мертвый жесткий диск или SSD-носитель.
2. Логические сбои: случайное удаление или неверная правка, повреждение приложением, сбой файловой системы.
3. Вирусы, уничтожающие данные (как классические вандалы, так и современные шифраторы).
4. Полная утрата компьютера (пожар, затопление, кража, изъятие полицией и т.п.).

2. Что потребуется?

• Дополнительный жесткий диск в ПК (очень желательно, чтобы их было минимум два).
• Две или более флэшки достаточного объема (32/64/128 Гб и более). Рекомендуется USB3 (и удостоверьтесь, что это истинная скорость, а не цифирки на интерфейсе к улиточно-медленной памяти, как у самых дешевых моделей).
• привод DVD-RW.
• Подключение к облачному хранилищу типа Google Drive, Microsoft OneDrive или аналогичным.

 За время пандемии хакеры стали находить больше эксплойтов во всех видах программного обеспечения? Сегодня мы снова хотим поделиться интересными фактами и данными из нашего исследования Acronis Cyber Threats Report 2020 и рассказать о тех направлениях активности, в которых киберпреступники особенно преуспели. Речь пойдет об уязвимостях в различных приложениях, которые были обнаружены на протяжении коронавирусного локдауна. Также мы расскажем популярности разных типов вредоносного ПО, тенденциях в области кражи данных и затратах на содержание инфраструктуры для обеспечения работы сотрудников в удаленном режиме.

Всеобщая самоизоляция и удаленная работа повлияли на активность киберпреступников. Но хотя частота и методы атак изменились, сегодня угрозой №1 для бизнеса по-прежнему остается Ransomware. Этот тезис подтвердил отчет, подготовленный на базе информации из сети операционных центров киберзащиты Acronis (CPOC). Под катом — прогнозы на 2021, данные исследований, а также статистика и выводы.

Скажите честно, в своей практике вам чаще приходилось сталкиваться с логами, напоминающими чей-то поток сознания, или всё же это были красивые структурированные файлы, на которые любо-дорого смотреть? Надеюсь, что второе. В наших продуктах, само собой, мы тоже стремимся идти по второму пути, однако необходимость зафиксировать большое количество процессов накладывает свой отпечаток. Так что сегодня мы научимся не “читать книгу и видеть фигу”, а бесстрашно открывать любой лог Veeam Backup & Replication и видеть его внутреннюю красоту.

Перед прочтением этой статьи настоятельно рекомендую предварительно ознакомиться со статьёй-глоссарием, дабы понимать используемую терминологию. Затем прочитать эту и вот эту статью про источники данных для логов, а затем ещё и эту, дабы понимать, в какой лог ради чего следует залезать.

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

Но не об этом мы сегодня. Сегодня мы поговорим о структуре логов в Veeam Backup & Replication, об их названиях и ожидаемом содержимом. Список будет большим, но не исчерпывающим, ибо всё описать — задача практически невозможная.

Как и у каждой уважающей себя техподдержки, у инженеров Veeam есть свой список самых популярных поводов позвонить им в любое время дня и ночи. Это и вечно молодое “У вас неправильно работает ретенш”, и никогда не стареющее “У меня место на дисках кончилось, что делать?”, и прорва других. 

Однако среди них есть простой, казалось бы, вопрос. Он объясняется за 5 минут, но вот парадокс: его объяснение вылетает из головы в течение следующих тридцати секунд. Звучит этот чудо-вопрос примерно так: “После бекапа Veeam нарисовал мне непонятный график и написал, что у меня загрузка сорса 63%, прокси 48%, сети 99%, а таргета 0! А потом ещё и обозвал этот сорс ботлнеком, а у меня там ого-го какая железяка! И что вообще означают эти проценты?”

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

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

И тут откровение номер раз: чтобы говорить о перфомансе на серьёзных щщах, надо напрямую измерять интересующие нас метрики и проводить их аналитику. Это статистика загруженности дисков, процессоров, памяти и так далее. Словом, построить внутри одного продукта ещё один продукт, только мониторинговый. Поэтому Veeam ничего напрямую не измеряет, однако в логах можно найти шесть метрик, сделанных путём опосредованных измерений. 

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

Acronis Global Cyber Summit 2020 официально закончился! Это была наша первая гибридная виртуальная конференция, в которой приняло участие более 9500 человек. Мы обсудили отраслевой опыт и оценки аналитиков, говорили о защите и построении ИТ-бизнеса. Часть мероприятия была посвящена таким вопросам как построение женской карьеры в технических компаниях и работа с ИТ-журналистами. Кроме этого для участников были подготовлен интересный развлекательный контент, спортивные и детские виртуальные зоны.  Сегодня мы подводим итоги, рассказываем о самых интересных моментах и выступлениях. Под катом — дайджест ивента, мнения ведущих спикеров и ссылки на интересные видео.

Продолжаем наше погружение в увлекательный мир гадан... траблшутинга по логам. В предыдущей статье мы договорились о значении базовых терминов и одним глазком рассмотрели общую структуру Veeam, как приложения. Задача на эту - разобраться как формируются лог файлы, что за информация в них отображена и почему они выглядят как выглядят.

А что вообще такое эти ваши логи? По мнению большинства логам любого приложения должна быть отведена роль этакой всемогущей сущности, которая большую часть времени прозябает где-то на задворках, но в нужный момент появляется из ниоткуда в сияющих доспехах и всех спасает. То есть в них должно быть всё, от малейших ошибок в каждом компоненте, до отдельных транзакций базы. И умещаться это всё должно в два мегабайта. Это же просто текст! Не могут текстовые файлы занимать десятки гигабайт, я где-то это слышал!