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

Как обеспечить бесперебойную работу систем и сервисов, чтобы сохранить данные даже во время аварий и катастроф? Для этих целей существует решение Disaster recovery, позволяющее сделать инфраструктуру устойчивой к катастрофам разного рода.

О том, что может привести к катастрофе и как от неё защититься, рассказывает IT-директор 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 для доступа.