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

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

В качестве железа выбрал старенький HP Microserver Gen7. Продавать большого смысла не видел, куда-то в продакшн ставить тоже — он почти на любой чих под 100% загружается, если какие-то сервисы вешать или просто в несколько потоков файлы по гигабитной сети копировать. А вот с простым хранением файлов он ещё справится.

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

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

Но потом на ваш прекрасный отказоустойчивый сервер приходит обновление от CrowdStrike (инструмент защиты от кибератак), которая вроде как должна бороться со всем плохим, а не примыкать к нему. И ещё 8,500,000 серверов и ПК по всему миру присоединяются к вечеринке, после которой банки, аэропорты (да и авиация в целом), больницы, службы безопасности и другие блага цивилизации отсыпаются где-то в ванной.

Миллиардные убытки, колоссальный репутационный ущерб. И даже кибератак не было по официальным данным — сами себе в ногу стрельнули.

В этой статье я расскажу о полезных практиках, которые защитят ваши серверы и данные — от своих и чужих. А в конце уже по классике опрос. И помните, лучший способ стать просветлённым — указать на ошибки автора и вступить в спор с случайным комментатором на Хабре :)

Привет, Хабр.

Мы очень часто слышим от наших потенциальных пользователей вопрос: «Как с минимальными усилиями развернуть продукт и познакомиться с его возможностями?» Предлагаем вам пошаговую инструкцию, как быстро начать работу с Кибер Бэкапом – расскажем про самый простой и доступный способ развернуть наш продукт на операционной системе Linux и создание первого плана защиты вашей инфраструктуры.

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

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