☰

Как убедиться, что снимок, доступный только для чтения, не поврежден в BTRFS?

tag-icon • tag-icon btrfs checksum data-integrity
Как убедиться, что снимок, доступный только для чтения, не поврежден в BTRFS?

Как можно убедиться, что снимок, доступный только для чтения, не будет поврежден из-за сбоя диска?

Это единственный способ подсчитать контрольные суммы друг на друге и сохранить их для дальнейшего изучения, или BTRFS справляется с этим самостоятельно?

Обоснование

Я регулярно делаю резервные копии снимков в качестве профилактики возможного сбоя диска. Несколько дней назад я не смог сделать btrfs send | btrfs receiveопределенный снимок. Когда я его удалил, остальные операции прошли нормально. Более того, btrfs scrubговорит, что есть несколько неисправимых ошибок. Это заставило меня подумать, что мои снимки на основном диске могли быть повреждены до того, как я сделал их резервную копию на внешнем диске, и если я не знаю об этом, у меня будут уже поврежденные резервные копии на внешнем диске.

Вот чего я хочу избежать. Я хочу быть уверен, что если я (могу) сделать резервную копию снимка, то он не будет поврежден.

решение1

Существует два возможных ответа в зависимости от того, что вы подразумеваете под «повреждением из-за сбоя диска».

Если вы имеете в виду простое повреждение данных в состоянии покоя

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

  • Если том смонтирован с параметрами nodatasumили nodatacow, у вас не будет контрольной суммы блоков данных. В большинстве случаев вам не следует монтировать с этими параметрами, так что это не должно быть проблемой.
  • Любые файлы, для которых NOCOWустановлен атрибут ( Cв выводе команды lsattr), также не проверяются. У вас вряд ли есть действительно важные файлы с установленным атрибутом (файлы журнала systemd имеют его, но это все, если вы не установили его вручную).

Если вы имеете в виду нетривиальное уничтожение данных на томе из-за потери слишком большого количества устройств

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

Относительно вашего конкретного случая

Проблемы с отправкой/получением, о которых вы говорите, вероятно, являются побочным эффектом тех неисправимых ошибок, о которых сообщает Scrub. Когда BTRFS не может прозрачно исправить ошибку (обычно потому, что блок хранится с использованием профиля, который не может выполнить восстановление, например, single или raid0), он возвращает ошибку ввода-вывода, что приведет к сбою операции отправки. Таким образом, вы не получите уже поврежденные резервные копии, если используете отправку/получение (и на самом деле, вы не получите их и с большинством других инструментов, любое хорошее программное обеспечение для резервного копирования выдаст ошибку, если не сможет прочитать файл).

В этом случае, похоже, что неисправимые ошибки полностью находятся в данных, эксклюзивных для снимков или не создаваемых снимков. Вы можете довольно легко (хотя и не очень быстро) выяснить, какие файлы имеют проблемы, смонтировав исходный том где-нибудь отдельно и выполнив следующую команду из того места, где он смонтирован:

find . -exec cat '{}' \; > /dev/null

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

После того, как вы нашли и разобрались с этими файлами, у вас не должно быть никаких дальнейших проблем. Если вы видите, что эти проблемы повторяются в ближайшем будущем после их исправления, вам следует проверить свое оборудование, так какчто-нибудьмолча искажает данные.

Связанный контент