Клонирование диска Proxmox Backup Server: ошибки Clonezilla, ddrescue и rsync

Я пытался перенести Proxmox Backup Server с неисправного SSD на рабочий диск. Система ещё загружалась, но затем начинала выдавать ошибки файловой системы. Хотелось забрать всё: загрузочные разделы, саму систему и её настройки.

Полный рабочий клон я так и не получил. Clonezilla остановилась с ошибкой, а последующий запуск ddrescue скопировал 0 байт. После нескольких перезагрузок исходный SSD перестал определяться. Ниже — мой опыт и порядок действий, который я выбрал бы в похожей ситуации.

Что я собирался спасти

Proxmox Backup Server, или PBS, — система для хранения резервных копий. Для работы у меня было три накопителя:

• Исходник — ADATA SU650, 240 ГБ. В той live-сессии он назывался /dev/sda. На нём находились загрузочные разделы и LVM — система управления логическими томами.
• Приёмник — второй ADATA SU650, 240 ГБ. Он назывался /dev/sdb. Сюда я направил копирование.
• Диск с образами — Crucial, 1 ТБ, NTFS. Его раздел /dev/sdc1 я использовал только для файла прогресса ddrescue.

Внутри LVM находились pbs-root — том с файловой системой Linux, и pbs-swap — область подкачки, которую система использует при работе с памятью. Для полного переноса я выбрал весь физический диск: так в копирование входят и эти тома, и разметка, и загрузочные области. Отдельно открывать каждый том для этого не требуется.

При этом системный диск PBS и хранилище самих резервных копий — не обязательно один носитель. Перед восстановлением я бы обязательно выяснил, где находится datastore: так в PBS называется хранилище бэкапов. От этого зависит, какие диски нужно спасать. Подробнее о хранилищах PBS.

С чего я начал и где остановилась Clonezilla

Сначала я попробовал обычное клонирование через Clonezilla. Первая попытка завершилась сообщением:


Диск назначения был занят. Такая ошибка требует сначала разобраться, какие разделы, тома или массивы его используют. Само наличие диска в списке ещё не означает, что он свободен для перезаписи. Точную причину занятости в тот момент я не установил.

Фото 01. Clonezilla не смогла подготовить занятый диск назначения.

При следующей попытке копирование раздела /dev/sda3 в /dev/sdb3 началось, но примерно на 42% Partclone — программа, которую использует Clonezilla, — сообщила об ошибках чтения и остановилась.

Эти 42% не означают, что я сохранил 42% всех файлов. Это был прогресс отдельного этапа. Работоспособность полученной копии я не проверял.

Фото 02. Ошибка чтения во время копирования раздела.

После этого я перешёл к GNU ddrescue. Она умеет обходить проблемные участки и сначала забирать доступные данные. Теперь при признаках отказа накопителя я бы начинал спасение с такой копии, до попыток ремонта файловой системы. Такой порядок рекомендует и руководство GNU ddrescue.

Как я подготовил диски

Я работал из live-системы Linux, загруженной с отдельного носителя. Сначала посмотрел устройства, их размеры, серийные номера и использование:


lsblk показывает диски и разделы; ключ -b выводит размеры в байтах. Следующие две команды помогают увидеть активные программные RAID-массивы и подкачку. У меня активных массивов и swap на этом этапе не было; версия ddrescue — 1.27.

Оба ADATA оказались одинакового размера: 240 057 409 536 байт. Различал я их по серийным номерам: исходник — 2M31291ESGYU, приёмник — 2M312L1CG1UH. Для копирования всего устройства приёмник должен быть не меньше исходника в байтах.

Имена /dev/sda и /dev/sdb ниже относятся только к моей сессии. После перезагрузки они могут поменяться. Перед повторением команды я заново сверил бы модель, серийный номер и размер каждого диска.

Фото 03. Список накопителей, pbs-root, pbs-swap и версия ddrescue.

Тома PBS были активны, но не смонтированы. Я деактивировал группу LVM и включил для исходника режим только для чтения:


Деактивация pbs не удаляет тома: она отключает их использование в текущей системе. Если разделы смонтированы или используется подкачка, сначала нужно освободить именно их. При непонятной занятости диска я бы остановился и выяснил причину.

Режим RO=1 запрещает запись, но разрешает чтение. После переподключения я проверил бы его снова. Это программная защита исходника, а не устранение его неисправности. Описание blockdev.

Зачем понадобился третий диск

Чтобы сохранять ход работы ddrescue и иметь возможность продолжить её позже, я использовал файл карты прогресса — mapfile. В нём записано, какие участки уже прочитаны, а какие ещё требуют работы. Самих файлов PBS в этой карте нет.

Я сохранил её на Crucial, где у меня уже лежали образы:


Последней командой я проверил, что в /mnt/rescue действительно подключён нужный NTFS-раздел. Эти команды не форматируют накопитель. Я добавлял обычный файл, а не выбирал Crucial приёмником клона. Но сохранность ранее записанных образов отдельно не проверял.

Для новой операции я выбрал бы отдельное имя карты, а для продолжения той же — сохранил прежнюю карту и тот же приёмник. Карту нельзя подменять картой от другого диска. Эти правила описаны в справке ddrescue 1.27.

Какую команду я запустил

Команда ниже перезаписывает диск назначения /dev/sdb. Всё нужное с него должно быть заранее сохранено. У меня исходником был первый ADATA, приёмником — второй, а Crucial хранил только карту. Ни исходник, ни приёмник не должны использоваться системой во время копирования.


Здесь mountpoint проверяет наличие монтирования, а && разрешает запуск следующей команды только при успешной проверке. Нужный ли это диск, я предварительно проверил через findmnt.

У самой ddrescue порядок аргументов такой: источник → приёмник → карта прогресса. Ключ -f разрешает запись на устройство назначения. Ключ -n пропускает scraping — этап тщательного вычитывания проблемных участков. Это способ начать спасение без этого этапа, а не обещание получить исправный клон. Описание параметров.

Фото 04. Подготовка дисков и начало работы ddrescue.

Что показала ddrescue

Ошибки росли, а счётчик успешно скопированных данных оставался нулевым. Итог запуска получился таким:


Фото 05. Ошибок становится больше, успешно скопированных данных — 0 байт.

Фото 06. Финальный результат ddrescue.

Надпись Finished означала, что программа закончила выбранные этапы. За этот запуск я не получил ни одного нового байта. На приёмнике могла остаться часть данных от Clonezilla; ddrescue её не превратила в полный клон.

При проверке одного сектора я тоже получил ошибку:


Первая команда пытается прочитать только 512 байт и отправляет их в /dev/null, ничего не записывая на диски. Она завершилась с Input/output error и 0 bytes copied. Вторая показала журнал ядра с ошибками чтения sda, в том числе DID_BAD_TARGET.

Фото 07. Не удалось прочитать даже первый сектор.

Фото 08. Ошибки доступа к исходному SSD в журнале ядра.

После нескольких перезагрузок SSD перестал определяться. Я счёл его неисправным, но точную причину не установил: отдельно не исключил питание, кабель, порт или переходник. Поэтому утверждать, что все данные безвозвратно уничтожены, я не могу.

Когда я использовал бы rsync

После этой попытки я рассмотрел ещё один вариант — перенос файлов через rsync. В описанных выше работах я его не запускал. Пока система ещё загружалась, он мог помочь сохранить доступные файлы. Но для этого файловая система должна монтироваться, а каталоги и данные — читаться. Когда SSD уже перестал определяться, rsync получить к нему доступ тоже не сможет.

Для переноса моего PBS задачи разделились бы так:

• pbs-root: скопировать файлы системы с их правами, владельцами, ссылками и атрибутами.
• pbs-swap: создать область подкачки заново. Её содержимое не нужно для переноса выключенной системы.
• Разметка, LVM и загрузка: подготовить отдельно. Обычный перенос файлов через rsync не создаёт разделы и логические тома, не устанавливает загрузчик. После копирования нужно проверить ссылки на UUID разделов в настройках системы и настроить загрузку.

Вот пример для случая, когда доступная корневая файловая система уже смонтирована в /mnt/src, а подготовленная файловая система нового диска — в /mnt/dst:


Это пример переноса файлов, а не команда, которую я выполнял на неисправном SSD. Перед запуском я проверил бы обе точки монтирования через findmnt. Для приёмника выбрал бы Linux-файловую систему, например ext4. Обычная папка на моём NTFS-диске не подходит для прямого переноса установленной Linux-системы с её метаданными.

Параметры -aHAX сохраняют основные метаданные, включая жёсткие ссылки, дополнительные права доступа и расширенные атрибуты. --numeric-ids сохраняет числовые идентификаторы владельцев и групп, а --info=progress2 показывает общий прогресс. Завершающий слеш у /mnt/src/ означает копирование содержимого каталога. Описание параметров rsync.

С ключом -x копируется только одна файловая система. Отдельные /boot, EFI-раздел и datastore, если они есть, нужно переносить отдельно. Запуск одной такой команды не означает, что перенесено всё содержимое всех дисков.

Для переноса всей системы я бы работал из live-среды при выключенной исходной ОС: так файлы не меняются из-за работы её служб. Успешное завершение rsync ещё не подтверждает, что новая система загрузится и все исходные файлы были исправны.

В моей ситуации я рассматривал бы rsync прежде всего для извлечения доступных файлов с частичной копии на втором ADATA, если её файловая система читается. При аппаратных ошибках исходника я сначала старался бы получить копию через ddrescue, а затем работать с ней. Рекомендации по спасению неисправного носителя.

Как я действовал бы теперь

1. Прекратил бы загрузку с проблемного SSD. Подготовил бы live-систему, исправный приёмник и отдельное место для карты прогресса. Если на диске единственная копия незаменимых данных, сначала рассмотрел бы восстановление в лаборатории.
2. Проверил бы подключение и назначение дисков. Кабель, питание и порт проверял бы при выключенном оборудовании. Затем записал бы серийные номера, размеры и направление копирования.
3. Освободил бы исходник и приёмник от использования системой. Проверил бы монтирование, swap, LVM и RAID. Защитил бы исходник от записи.
4. Начал бы копирование всего диска с картой прогресса. Следил бы за ростом rescued. Повторные попытки чтения проблемных областей рассматривал бы только после сохранения доступных данных и оценки состояния накопителя.
5. Остановился бы при потере доступа к устройству. Нулевой результат, мгновенные ошибки чтения по всему диапазону и исчезновение SSD — повод проверить доступ к нему. Для остановки я нажал бы Ctrl+C и дождался выхода программы, затем сохранил бы карту и корректно выключил live-систему перед отключением дисков.
6. Проверял бы результат на копии. Сохранил бы карту, отключил исходник перед пробной загрузкой клона и проверил нужные файлы. Если доступна только часть файловой системы, рассмотрел бы извлечение читаемых файлов через rsync. Перед ремонтом файловой системы по возможности сделал бы ещё одну копию полученного результата.

Чего я не советую делать

• Многократно загружать неисправную систему в надежде, что на этот раз она заработает.
• Запускать исправление файловой системы на исходном диске с ошибками чтения до спасения данных. Это может дополнительно изменить то, что ещё удаётся прочитать. Предупреждение в руководстве ddrescue.
• Копировать команды с чужими /dev/sdX без проверки: одинаковые модели дисков легко перепутать.
• Форматировать диск с образами ради небольшого mapfile или сохранять карту только во временной live-системе.
• Удалять карту при каждом перезапуске или использовать её с другим приёмником, на котором нет уже спасённых данных.
• Считать перенос корневого каталога через rsync готовым загрузочным клоном или забывать про отдельные файловые системы при использовании -x.
• Считать процент прогресса, сообщение Finished или успешную загрузку достаточной проверкой всех файлов. При неполном копировании на использованном приёмнике могут остаться старые данные в непрочитанных областях. Как ddrescue работает с приёмником.

В моём случае попытка закончилась без рабочего клона. Теперь я бы раньше прекращал обычную работу с таким SSD и переходил к сохранению читаемых данных. Ремонт системы имеет смысл обсуждать уже после того, как есть копия, с которой можно работать.