Функция CDP (она же Continuous Data Protection) для многих сейчас видится манной небесной. Ведь она позволяет свести риски потери данных к около-нулевым значениям (RTO и RPO - единицы секунд), при этом не используя тормозящие всё вокруг себя снапшоты, и не зависеть от ограничений классических вариантов репликации.
Вот об этом мы сегодня и поговорим: что это за магия такая, как она работает и как мы её реализовали в Veeam Backup & Replication v11.
Технологии автономных автомобилей способны совершить настоящий переворот в транспортной отрасли и оказать существенное долгосрочное влияние на образ нашей жизни, работы и бизнеса: они могут снизить количество жертв дорожно-транспортных происшествий, разгрузить дорожную сеть и высвободить время. Кроме того, в этом случае появятся новые транспортные парадигмы, включая автономные такси и модели «перевозка как услуга» с автомобилями совместного владения.
Вчерашний пожар — очередной повод вспомнить о бэкапах. Вспомнить, настроить и проверить. Держите 7 простых правил для собственников и руководителей бизнеса, которые помогут стойко перенести подобные катаклизмы.
VTL (они же Virtual Tape Library, если по паспорту) можно назвать одним из самых странных порождений IT индустрии. Родившись в эпоху расцвета ленточных накопителей как классический софтовый эмулятор настоящего железа, многими они были восприняты как ответ на главный вопрос жизни (Вселенной и всего такого), и теперь одни умудряются продавать их за деньги, а другие использовать в проде и считать, что всё нормально.
Я не буду кричать что первые плохие, а вторых надо гнать из профессии. Нет. Я только лишь предлагаю трезво взглянуть на суть VTL.
Администраторы кластеров kubernetes сталкиваются с задачей сохранить конфигурацию ресурсов из пространства имен и перенести в другой кластер, или же сделать резервную копию нестабильной тестовой площадки. С этой задачей без проблем справляется бегло написанный в терминале односторчный скрипт с утилитой kubectl, но что если надоело каждый раз тратить пару минут времени на очередное написание скрипта. Так и появилась утилита kube-dump, по сути это утилита которая умеет только одно - дампить ресурсы кластера.
Сегодня я решил поразмышлять на тему – зачем нам это надо (на примере Notion)? Пост – чистая философия.
Вообще, я к Notion не имею никаких претензий. Никто же не предъявляет претензии молотку… Просто это первый сервис, который мне попался, который обладает огромным функционалом.
Когда я в первый раз его установил и узнал о его возможностях, то радости не было предела. Я понял, вот оно, вот то место куда я могу перенести свою жизнь.
И вот он - Я. По классике жанра сразу создал 2 пространства – личное и рабочее. Сами понимаете - жизнь именно так и делится. Вот тут мои книги, вот тут фильмы, тут заметки, тут лайфхаки, тут идеи, тут полезное что-то, рецепты, тренировки, уроки, курсы, друзья, семья, машина, животные, хобби… И самое вкусное – планы!
Начнем с простого. Книги, фильмы, музыка. Создал каталоги: что смотрел, что читал, что слушал, что планирую читать, смотреть, слушать. Даже какие-то рейтинги придумал, что понравилось, а что не очень, оценки от 0 до 5, нет до 10, так объективнее, теги по жанрам. Даже где-то писал комментарии.
Потом. Списки уроков, курсов, полезных материалов, гайдов, мануалов. Всё разложил по полочкам, теги опять же.
Друзей оцифровал. Фото там, дни рождения, дни рождения детей, ссылки на соцсети, контакты… Теги…
Хобби, животные, машина, всё оцифровал, навешал тегов, добавил ссылок на ресурсы…
Работа! Тоже все оцифровал по аналогии. Прям всё! В общем, всё по феншую.
Планы – наше спасение и наша погибель. Notion помогает раздуть их до вселенских масштабов. Пришла в голову идея – в планы ее, задачи к ней, подзадачи к ним, сроки каждой задаче/подзадаче, ответственных лиц и всё такое. Это все на волне эйфории от гениальности идеи. Чем она гениальнее мне казалась, тем больше места она занимала в Notion.
Что получил в итоге.
Сначала был вопрос – а на хера мне всё вот это вот? Кому интересно, да и в принципе кто это увидит, что я читал, смотрел, слушал и как у меня всё это отсортировано? Все эти рейтинги для самого себя? Если мне понравился фильм, то на кинопоиске я поставил оценку и забыл про него. С книгами еще проще: прочитал – удалил. Всё. Нет книги. Музыка. Вся она в яндексмузыке в подборке понравилось (и то, что-то удаляю, что-то добавляю). Всё. На хрена она в Notion?
Помните, как во второй половине 90-х один известный тогда профессор хрипло пел “Бегут года, и грусть, печаль в твоих глазах, а я не знаю что тебе сказать”. Так вот, года действительно бегут, а грусть-печаль в глазах из-за того, что гонка технологий уже достигла таких скоростей, что успеть за ними не может даже самый ловкий мангуст. Правда, некоторые вещи категорически отказываются меняться, и раз уж эта статья из блога компании, занимающейся бекапами, видимо, что-то не меняется в бекапах. А проблема, о которой хочется поговорить сегодня - это выбор сервера, который эти бекапы и будет делать. Все как-то привыкли думать только о размере стораджа, куда их предстоит складывать, а то, что процесс бекапа - это типичная задача обработки большого массива данных, которая жрёт RAM и CPU как не в себя, многие то ли забывают учесть, то ли по неопытности упускают этот момент. Так что сегодня учимся подбирать сервера для бекапов не только по размеру дисков. Или, как говорят зарубежные коллеги: backup server sizing best practices.
И да, в посте будет математика. Целых две формулы. Я предупредил.
Restic — хорошо известная программа для резервного копирования. Она достаточно проста, чтобы переноситься на любую ОС, и, вероятно, поэтому с ней не прилагается полноценный пример настройки на среднестатистической Linux-системе. Исправим это данным постом.
Поставим задачу следующим образом:
psql -f.Пишем два юнита / таймера для systemd, запускаем restic под выделенным пользователем с CAP_DAC_READ_SEARCH, для PostgreSQL архивируем результат pg_dumpall.
Уже, наверное, только ленивый не повторил десять раз, что ковид послужил катализатором взрывного роста как самих облаков, так и разного рода облачных сервисов. Словом, всё, что как-то относится к облачной теме, стало резко расти и увеличиваться в объёмах. Причина банальная: всех разогнали по домам, и для многих возросшие нагрузки на их сервисы послужили тем самым громом, после которого надо перекреститься и начинать уже что-то делать. Вот все и начали срочно мигрировать. У кого-то процесс перехода прошёл гладко, у кого-то не очень, однако все мы как-то научились жить в новой реальности и теперь, когда вау-эффект прошёл, многие компании стали переключаться с чисто инфраструктурных вопросов на вопрос сохранности данных. Когда твои сервера у тебя под боком, ты сам себе хозяин и молодец. А что делать, когда твои продукты крутятся не пойми где? Довериться надежности облака? Бекапить облачные сервисы другими сервисами этого же облака? Бекапить из облака на землю? Бекапить одного облако в другое? Вопрос важный, ответ не ясен, давайте разбираться.
За время пандемии хакеры стали находить больше эксплойтов во всех видах программного обеспечения? Сегодня мы снова хотим поделиться интересными фактами и данными из нашего исследования Acronis Cyber Threats Report 2020 и рассказать о тех направлениях активности, в которых киберпреступники особенно преуспели. Речь пойдет об уязвимостях в различных приложениях, которые были обнаружены на протяжении коронавирусного локдауна. Также мы расскажем популярности разных типов вредоносного ПО, тенденциях в области кражи данных и затратах на содержание инфраструктуры для обеспечения работы сотрудников в удаленном режиме.
Всеобщая самоизоляция и удаленная работа повлияли на активность киберпреступников. Но хотя частота и методы атак изменились, сегодня угрозой №1 для бизнеса по-прежнему остается Ransomware. Этот тезис подтвердил отчет, подготовленный на базе информации из сети операционных центров киберзащиты Acronis (CPOC). Под катом — прогнозы на 2021, данные исследований, а также статистика и выводы.
Скажите честно, в своей практике вам чаще приходилось сталкиваться с логами, напоминающими чей-то поток сознания, или всё же это были красивые структурированные файлы, на которые любо-дорого смотреть? Надеюсь, что второе. В наших продуктах, само собой, мы тоже стремимся идти по второму пути, однако необходимость зафиксировать большое количество процессов накладывает свой отпечаток. Так что сегодня мы научимся не “читать книгу и видеть фигу”, а бесстрашно открывать любой лог Veeam Backup & Replication и видеть его внутреннюю красоту.
Перед прочтением этой статьи настоятельно рекомендую предварительно ознакомиться со статьёй-глоссарием, дабы понимать используемую терминологию. Затем прочитать эту и вот эту статью про источники данных для логов, а затем ещё и эту, дабы понимать, в какой лог ради чего следует залезать.
Наверняка я вам не открою Америки рассказом о том, что логи назвали логами из-за судовых журналов, куда записывали всякое интересное (и не очень), что происходило на корабле во время плавания. (Возможно, некоторые из вас не знают, но по воде ходят именно корабли, а судно — это в больнице. Хотя тут показания расходятся)))
Но не об этом мы сегодня. Сегодня мы поговорим о структуре логов в Veeam Backup & Replication, об их названиях и ожидаемом содержимом. Список будет большим, но не исчерпывающим, ибо всё описать — задача практически невозможная.