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

Данная статья написана только в образовательных целях и автор не несёт ответственности за ваши действия. Ни в коем случае не призываем читателей на совершение противозаконных действий. Материал размещен только с целью ознакомления и принятию мер по обеспечению безопасности. Использование материалов в противоправных и противозаконных запрещено законом РК. Все персоны или принадлежность к кому-либо только в голове у автора. Любые совпадения с реальностью абсолютно случайны.

Серьезные инциденты случаются со всеми, даже с глобальными игроками. Чего стоил один только прошлогодний сбой у Toyota! Тогда переполнение дискового пространства и сбой в СУБД стали причиной остановки всех заводов компании в Японии. А недавно произошла хакерская атака на СДЭК. В таких ситуациях остается надеяться только на бэкапы.

Не удивительно, что мы часто получаем запросы от клиентов о том, как организовать корпоративное резервное копирование. Их интересует, что именно бэкапить, как часто это делать, где хранить резервные копии, какие регламенты нужны и как лучше организовать резервное копирование на предприятии. Особенно много таких запросов стало поступать в последнее время. Поэтому я решил написать серию статей о том, как устроено резервное копирование, как его организовать и защитить. Моя цель — рассказать о best practice и структурировать эти знания. Бэкапы — обширная тема, которая включает множество нюансов, так что я начну с архитектуры и буду постепенно углубляться в детали. 

Теряли ли вы когда-нибудь данные в результате технической аварии? Была ли среди них критическая информация, которая восстанавливалась медленно или только частично? Именно в такие моменты в команде впервые начинают думать о резервировании. Предлагаем изменить подход и заранее корректно организовать резервные ресурсы.

Привет Хабр!

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

Сегодня мы поговорим о поддержке ОС семейства Linux — о том, как она обеспечивается на уровне компонентов нашего продукта и какие варианты защиты данных, находящихся на машинах, работающих под управлением этой ОС существуют в Кибер Бэкапе.

Следим за целостностью данных в PostgreSQL. Мысль о возможной катастрофе неприятна, поэтому люди часто не принимают серьезных предупредительных мер.

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

Ситуация - два Hyper-V сервера, десяток виртуалок, на каждый Hyper-V установлен VBR CE, бекапы хранятся на соседних дисках + раз в неделю каталоги с бекапами синхронизируются со стареньким NetGear NAS.

Казалось бы - что тут может пойти не так??!! Да все! Несмотря на то, что Hyper-V не в домене - сломать его по сети вполне реально, если злоумышленник попадет хотя бы на одну рабочую станцию (или подключится по WiFi). NetGear NAS уже устарел, прошивка содержит известные уязвимости. В общем бекапы не защищены и в случае атаки изнутри - шансы получить проблемы весьма велики.

Решение - делаем отдельный хакеро-защищенный NAS на базе Debian Linux 12 + iptables + скрипты от ChatGPT4.

Один из наших клиентов обнаружил, что резервные копии ClickHouse, которые он хранит в S3 провайдера CROC, не очень-то и шифруются. А ФСТЭК суров. Перед нами была поставлена задача: настроить шифрование бэкапов. В статье покажу, как мы это сделали.

Ещё расскажу вам про такой инструмент как clickhouse-backup, распишу его плюсы и минусы и продемонстрирую, как легко восстановить данные из шифрованных бэкапов.

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

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

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

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

Не так давно на Хабре была небольшая волна постов и комментариев о том, как можно быстро и эффективно потерять данные своего проекта - неработающие или отсутствующие бэкапы, ошибки "железа" и прочие радости инженеров 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 я много раз видел, как компании и рядовые пользователи теряют данные и несут серьезные убытки. Можно ли этого избежать? В большинстве случаев да. Сегодня расскажу, как компании расстаются с важной информацией и деньгами из-за хакеров, а также дам подробный чек-лист по организации резервного копирования.