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

Друзья, давайте поможем наши коллегам?

Решил написать этот чек-лист для контроля мер защиты от шифровальщиков. Жесткая критика и конструктивные предложения приветствуются! :)

Что упущено? Что стоит добавить-убавить?

Не так давно на Хабре была небольшая волна постов и комментариев о том, как можно быстро и эффективно потерять данные своего проекта - неработающие или отсутствующие бэкапы, ошибки "железа" и прочие радости инженеров DevOps. Тогда я это всё прочитал с интересом - всегда же любопытно почитать про чужие факапы (про свои неинтересно). Через несколько дней я вдруг оказался среди таких же несчастных "уже делающих бэкапы".

Немного контекста - у меня есть свой домашний проект, которым я занимаюсь в свободное от работы время. Проект этот - UGC-сайт. Лента постов пользователей, если по-нашему. Вот он - https://vombat.su, вдруг кому-то интересно. Проект существует с сентября, есть своя аудитория, пара модераторов и довольно лояльные правила. На проекте нет рекламы, т.е. он некоммерческий (не считая донатов, которые иногда прилетают от благодарных пользователей). Даже антикоммерческий слегка, т.к. на него я только трачу - даже периодически мерч пользователям отправляю.

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

Меня зовут Михаил Старцев, я — пресейл-инженер по резервному копированию «Тринити». В этой статье я выскажу предположение о том, что привело к такой традиции, а затем расскажу о поэтапном развёртывании резервного копирования на предприятии с нуля, снабдив текст практическими рекомендациями, которые помогут в успешной реализации этого процесса. 

Привет, Хабр. В мае этого года увидела свет новая версия нашей системы резервного копирования – Кибер Бэкап 17.0. Ниже расскажем, что нового появилось в продукте, что улучшилось, и немного заглянем в будущее.

Меня зовут Александр, я руковожу направлением больших данных в Битрикс24. Клиенты нашего сервиса хранят миллиарды файлов: от документов до фотографий, — а моя команда предоставляет возможность строить бизнес-аналитику на основе этого множества данных. И нам важно позаботиться об их сохранности.

Более 10 лет назад мы продумали необходимую нам схему репликации объектного хранилища в облаке. Затем файлы клиентов потребовалось перенести в другое облако, и нам очень хотелось также перенести все наши наработки в режиме «Ctrl+C, Сtrl+V».

В статье расскажу, как мы организовали резервирование данных в парадигме слабого связывания и как перенесли эту схему в Yandex Cloud без потери важных нам деталей.

Недавно совместно с компанией РОСА мы провели мероприятие, на котором рассказали о том, как наш Кибер Бэкап и платформа виртуализации ROSA Virtualization помогают в задачах импортозамещения. В данной публикации хотим подсветить несколько важных моментов.

Ровно два года назад, 16 марта 2022 года, ваш покорный слуга рассказал про нехитрые телодвижения, которые с помощью rclone позволяют сохранить локально ваши корпоративные Google shared drives (не путать с личным Google Drive).

Ок, данные были сохранены и можно выдохнуть. Но что делать, если вам хочется продолжить использование этого продукта, аналогов которому по функциональности и экосистеме нет? И при этом хочется еще спокойно спать по ночам? В том числе и после новых санкций:

Привет, Хабр! Сегодня мы поговорим о нескольких сценариях использования нашей системы резервного копирования в реальной жизни.

Наш «Кибер Бэкап» является программой-инструментом, и, смею заметить, инструментом неплохим. И, как всякий хороший инструмент, он имеет множество сценариев применения.

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

Я тут пересмотрел современные бэкапилки. Выбор пал на duplicacy (не путать с duplicati и duplicity). Выбранный бесплатен для персонального использования. Платный для коммерческого, но копейки: $50 за тазик в год. Хотя cli версия опенсорсная и лицензция нигде не проверяется.

В основном современные бэкапилки с дедубликацией очень похожи между собой, делают одно и то же одинаковыми библиотеками. Самый фичастый с большим функционалом restic, но в нём нет сжатия. Со сжатием аналогичный borg, но из коробки не умеет лить в облака. Кстати, те вариант, которые льют в облака - не хранят локальную копию.

Ещё особняком стоит duplicati. Он фичастый, крутой, обоссаться прям. Есть реально всё, что можно придумать. Но на дотнете ?‍♂️ Вроде есть пакеты под всё кроме фряхи, но фиг знает, недоверительно. Хотя мне разок попалась компания, у которой прод на дотнете под линуксом на моно.

Привет, Хабр. Сегодня расскажем о том, как обеспечить высокую доступность сервера управления Кибер Бэкапа путем настройки отказоустойчивого кластера. 

Привет, Хабр. В середине декабря мы выпустили обновленную версию нашей системы резервного копирования - Кибер Бэкап 16.5. Ниже мы, Валентин Баев и Алексей Федоров, расскажем, что у нас нового в продукте, что улучшилось, и немного заглянем в будущее.

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

Постановка задачи — есть виртуальная машина в облаке — мы хотим решить две задачи:

1. Резервировать ее по расписанию на наш сервер(а), находящиеся под нашим полным контролем.

2. Иметь возможность в любой момент сконвертировать нужную версию из резервной копии в виртуальную машину (в любом формате) и запустить ее на нашем оборудовании (т. е. приземлить виртуальную машину из облака на грешную...).

И так, поехали!

В предыдущей части мы привели рекомендации по установке и использованию нашего продукта в компаниях малого и среднего бизнеса. Сегодня мы, Дмитрий Ермолаев и Алексей Федоров, затронем вопросы установки и использования Кибер Бэкапа в крупных компаниях.

Примечание: если вы читаете не с начала, рекомендуем познакомиться с описанием компонентов Кибер Бэкапа в первой части цикла.

Привет, Хабр!  Сегодня поговорим об одном из наших инструментов, входящих в систему резервного копирования Кибер Бэкап (и в наш продукт для индивидуальных пользователей Кибер Бэкап Персональный). Его задача - обеспечить возможность восстановления образов машин на «неродное» железо.

Инструмент, называемый Universal Restore, появился в нашем арсенале довольно давно, еще до того, как линейка ОС Windows научилась сама искать новые драйвера при переносе на новое железо, и был весьма востребован. Он позволял модернизировать или чинить рабочую машину без привязки к конкретным моделям железных составляющих, а также переносить виртуальные машины на физические шасси или наоборот. То есть, адаптировать образ машины под различные аппаратные и программные варианты окружения.