Всем DevOps! Однажды один из наших клиентов обнаружил, что резервные копии ClickHouse, которые он хранит в S3 провайдера CROC, не очень-то и шифруются. Была поставлена задача: настроить шифрование бэкапов.
В своей новой статье Николай, наш DevOps-инженер, показал, как мы это сделали. Он разобрал основные методы шифрования данных на стороне сервера в Amazon S3 — SSE-C, SSE-KMS и SSE-S3, расписал плюсы и минусы работы с clickhouse-backup и продемонстрировал, как легко восстановить данные из шифрованных бэкапов.
💻 Если ещё не читали, то нажмите сюда, чтобы начать.
Как обеспечить бесперебойную работу систем и сервисов, чтобы сохранить данные даже во время аварий и катастроф? Для этих целей существует решение Disaster recovery, позволяющее сделать инфраструктуру устойчивой к катастрофам разного рода.
О том, что может привести к катастрофе и как от неё защититься, рассказывает технический директор OXYGEN Михаил Нестеров. В видео — подробный разбор угроз, логика организации Disaster recovery, обсуждение технических нюансов и ответы на каверзные вопросы. Приятного и полезного просмотра!
Этот ролик — запись доклада Михаила на митапе OXYGEN в Санкт‑Петербурге. Подробно про мероприятие можно почитать вот здесь.
А у вас есть опыт организации Disaster recovery? Как вы вообще делаете бэкапы? И какие самые необычные причины аварий встречались в вашей практике? Расскажите об этом в комментариях!
И обязательно подписывайтесь на наш канал в Telegram, там мы не только постим новости про IT, но и рассказываем про облака, дата‑центры и кибербез.
Компания «Рубэкап» (входит в «Группу Астра») заявила о выпуске нового релиза системы резервного копирования (СРК) RuBackup 2.0. Разработчики в RuBackup 2.0 Update 3 (2.0U3) реализовали ряд новых функций, например, в многопользовательской ролевой модели СРК появилась отдельная роль для специалистов по информационной безопасности «Аудитор ИБ». Пользователи с этой ролью имеют доступ к журналу, фиксирующему все события, происходящие в системе резервного копирования, рассказали информационной службе Хабра в пресс‑службе «Рубэкап».
Кроме новой роли, в релизе RuBackup 2.0 Update 3 есть следующие нововведения:
появилось ограничение использования оперативной памяти клиентом СРК при полном бэкапе, что не мешает функционировать другим приложениям даже при большом объёме бэкапируемых ресурсов;
добавлена поддержка резервного копирования и восстановления виртуальных машин, созданных на платформе zVirt;
созданы новые сценарии резервного копирования с помощью RuBackup;
обновлён компонент RuBackup Key, позволяющий выполнять функции Bare‑metal recovery;
появилась возможность несколько папок или файлов в качестве ресурса для резервного копирования файловых систем;
добавлен запуск RuBackup Manager в экспериментальном режиме, на операционной системе Microsoft Windows;
доработан механизм определения сетевого интерфейса для коммуникации с медиасервером.
Хочу поделится опытом / наблюдениями. Не редко SSD как SATA так и NVMe выходят из строя.
Во всех таких случаях Windows либо не загружается (висит на лого или заходит в UEFI Setup), либо глючит, зависает, не может установить обновления или корректно завершить работу.
Те из них что хоть как то определяются - препарирую в Linux И видно что ведут они себя немного по разному.
Я позволю себе разделить их по симптомам на четыре класса:
Чтение всего объема ok / Запись проходит как бы успешно, но при пере-монтировании видно что никакие файлы не записались.
Чтение всего объема ok / Отваливается при попытке записи в любой сектор.
Чтение в основном ok, но некоторые сектора UNC.
Чтение в основном ok, но после некоторых или каждого UNC требуется пере-подключить.
Применяю к ним GNU ddrescue в окружении Debian на рабочем десктопе. SATA подключаю напрямую / NVMe через USB докстанцию.
Успех!
Статей про ПО ddrescue написано много. Хотелось бы отметить ключи запуска которые (по моим наблюдениям) позволяют прервать процесс копирования в случае если SSD совсем перестал возвращать данные после очередной ошибки.
-O, --reopen-on-error reopen input file after every read error -J, --verify-on-error reread latest good sector after every error
-d, --idirect
Первый -O указывает после каждой ошибки заново открывать файл устройства. Второй -J проверяет что SSD еще может выдавать данные, перечитывая последний не сбойный сектор. Опционален, иногда приводит к проблемам.
И обязательный -d использовать DirectIO для доступа.