Восстановление данных *

Обновленный Кибер Бэкап Облачный

30.01.2025 расскажем о новых возможностях сервиса резервного копирования

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

Среди новинок в Кибер Бэкапе Облачном:

• Резервное копирование и восстановление данных российских СУБД на базе PostgreSQL – Tantor, Jatoba, Arenadata DB и Pangolin

• Защита корпоративных решений Почта VK WorkSpace и Диск VK WorkSpace

• Поддержка операционных систем Linux с версией ядра до 6.8

• Передача событий ИБ в журнал аудита

Мероприятие будет полезно руководителям и ИТ-специалистам компаний, которым важно обеспечить сохранность данных.

Прямой эфир начнется 30 января в 11:00 по московскому времени.

Регистрация на мероприятие - по ссылке.

Подключайтесь к вебинару «Как эффективно и просто делать бэкапы в облаке».

📅 Когда: 22 октября в 11:00 мск

📍 Где: онлайн

Бэкапы помогают минимизировать последствия нештатных ситуаций и снизить вероятность потери данных из-за сбоев, вирусов и кибератак. Как с помощью бэкапов приблизить уровень защиты данных к 100% и в разы уменьшить тревогу IT-специалистов и руководителей за сохранность информации?

На вебинаре эксперты Cloud.ru и оператор IT-решений «ОБИТ» расскажут, как делать резервное копирование быстро и эффективно. А еще покажут демо сервиса, который поможет настроить автоматические бэкапы за несколько кликов.

Вы узнаете:

• почему бизнесу важно делать резервное копирование и как делать его в облаке Cloud.ru;

• реальный опыт создания бэкапов под разные бизнес-задачи от оператора IT-решений «ОБИТ»;

• как обеспечить максимальную сохранность данных в облаке;

• как работает сервис для создания бэкапов и репликации.

В конце вебинара можно будет задать вопросы экспертам Cloud.ru и «ОБИТ».

Вебинар будет интересен IT-директорам, директорам по информационной безопасности и другим специалистам в сфере ИБ, системным архитекторам, инженерам и администраторам, а также всем, кого волнует безопасность данных в облаке.

👉 Зарегистрироваться

Оставляйте вопросы по теме в комментариях под этим постом 👇 — спикеры ответят на них в процессе встречи. 

Всем 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
И видно что ведут они себя немного по разному.

Я позволю себе разделить их по симптомам на четыре класса:

1. Чтение всего объема ok / Запись проходит как бы успешно, но при пере-монтировании видно что никакие файлы не записались.

2. Чтение всего объема ok / Отваливается при попытке записи в любой сектор.

3. Чтение в основном ok, но некоторые сектора UNC.

4. Чтение в основном 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 для доступа.